JsonConfEditor attribute not being honored in the MFAdmin configuration editor | VAF 2.3

I created a new VaultApplication with the new 2.3 Visual Studio extension and I see the JsonConfEditor attribute not being honored in the MFAdmin configuration editor.

This is my configuration class:

[DataContract]
public class Configuration
{
  [DataMember]
  [Security(ChangeBy = SecurityAttribute.UserLevel.VaultAdmin)]
  [JsonConfEditor(
    TypeEditor = "options",
    IsRequired = true,
    Options = "{selectOptions:[\"OFF\", \"INFO\", \"WARNING\", \"ERROR\"]}",
    DefaultValue = "OFF",
    Label = "Log level"
  )]
public string LogLevel { get; set; } = "OFF";
}

The Configuration class is being used in the VaultApplication class:

public class VaultApplication : ConfigurableVaultApplicationBase<Configuration>

This is what I see in the MFAdmin configuration editor for the vault application:

Initially the option value is empty (not "OFF", as indicated in the Configuration class), the label should be "Log Level" and there should be an options dropdown with OFF, INFO, WARNING or ERROR.

What am I missing here?

Parents
  • Ok, here is the cause: a bug in the updated NuGet packages for Interop.MFilesAPIMFiles.Crypto and MFiles.VAF.Configuration.

    After creating the solution, I updated the new NuGET packages for to the latest versions, and the MFAdmin configuration editor started to fail.

     <PackageReference Include="Interop.MFilesAPI">
    <Version>21.10.7</Version>
    </PackageReference>
    <PackageReference Include="MFiles.Crypto">
    <Version>21.10.7</Version>
    </PackageReference>
    <PackageReference Include="MFiles.VAF">
    <Version>2.3.623.2</Version>
    </PackageReference>
    <PackageReference Include="MFiles.VAF.Configuration">
    <Version>21.10.7</Version>

    To cross reference, I downgraded the package references in the csproj file to the numbers below, and the configuration options editor started to work again in MFAdmin.

     <PackageReference Include="Interop.MFilesAPI">
    <Version>21.8.1</Version>
    </PackageReference>
    <PackageReference Include="MFiles.Crypto">
    <Version>21.8.1</Version>
    </PackageReference>
    <PackageReference Include="MFiles.VAF">
    <Version>2.3.623.2</Version>
    </PackageReference>
    <PackageReference Include="MFiles.VAF.Configuration">
    <Version>21.8.1</Version>
    </PackageReference>

    So, don't update the new NuGet packages for now, otherwise you'll lose configuration editors.

  • The package version dependencies should be enforced with the latest release of the VAF nuget package. 

  • I'm not sure what the issue is here, but we have had some odd issues when updating the package versions. It's not bugs in the package but, I believe, to do with the reflection not working with the types from the different assemblies.

    That's why the latest VAF nuget package has dependencies that forces versions to the one that it was compiled with (21.8.1).

    The reason I mention it is that nuget should now stop you from encountering these issues by stopping you updating. 

  • How did you update the package references? Manually in the package reference elements, or using nuget? 

  • Updated via Visual Studio NuGet package management.

  • Okay... 

    The nuget package states that those packages should stay at exact versions, so that's odd: https://www.nuget.org/packages/MFiles.VAF

    I will need to test this out later. Any additional information I should be aware of? 

  • I have done some brief testing.

    When using the latest VS templates (1.3.0.8, which target VAF 2.3.623.2 by default), the NuGet package manager should stop you from updating the packages.  You should get this error:

    If you are using an older VS template that targets VAF 2.3.623.1 then this does allow you to upgrade the packages, although it causes all sorts of issues (and that's why we created a patched version that restricts you doing so).  If you have this older VS template then please update using the VS Extensions dialog (you should be using 1.3.0.8).

    Also, the default VS template uses packages.config rather than package reference, so I assume that you've manually migrated.  If I do that then the other packages (Interop, Crypto, etc.) disappear from the NuGet GUI as they are no longer considered top-level packages.

    If I then try and install a later version using the NuGet GUI then I get this error:

    If you can replicate this from a new project then I'd appreciate seeing the steps you're taking.  In general you should now not be able to do this, so I don't know what's going on.

  • I'll send you an email with the steps I took (again) and project files.

  • OK. It boils down to it should not be possible to update the M-Files nuget packages in the Visual Studio NuGet package manager. Things will break when you do.

    VAF 2.3 currently only works with version 21.8.1 of Interop.MFilesAPI, MFiles.Crypto and MFiles.VAF.Configuration nuget packages

  • You're correct.  As the NuGet package mandates: the VAF requires specific versions of those packages (and Newtonsoft.JSON).  The issue here is that you should be stopped from updating those packages and, for some reason, are not being.

  • Do you perhaps have the "Ignore Dependencies" option selected in your NuGet configuration?  This effectively instructs NuGet to ignore any of the version constraints that the NuGet packages declare, and will then allow you to upgrade to any versions you wish.

    The VAF currently requires specific versions of the packages upon which it relies.  It has done since its release.  You can see the current version dependency requirements on the NuGet package page.  I have copied a screenshot of the dependencies for version 2.3.623.2 below:

    If, for some reason, you update these packages then you will end up with odd issues.  This is because of the way in which we use reflection within the VAF itself.  In your specific issue, I believe that the "JsonConfEditorAttribute" type is not the same one being checked against, so it literally ignores it.

    We hope to change this in the future so that updates are not directly tied against specific versions of packages.  Until that time the NuGet package will state which dependency versions are needed for specific releases; the NuGet package manager should by default enforce these dependencies.

  • I have found another possible culprit.

    If you have the default package format set to "PackageReference" then, when Visual Studio creates the project and converts it, it seems to lose the dependency version restriction information.  This seems to be a bug in Visual Studio or NuGet or something, as it doesn't lose the dependency restriction information if you use the "Migrate packages.config to PackageReference" context menu.

    If you want to use PackageReference then, for now, I suggest that you leave the default as "packages.config" and then right-click on your packages.config file in your new application and select "Migrate packages.config to PackageReference", as Visual Studio then correctly migrates everything.

    Either way: I don't currently believe that this is a bug in the NuGet packages themselves, but in how Visual Studio is converting the project template to PackageReference.

    I have been looking at converting the templates to PackageReference which, if we did, may then resolve this issue.  Perhaps that needs to be higher on my list.

Reply
  • I have found another possible culprit.

    If you have the default package format set to "PackageReference" then, when Visual Studio creates the project and converts it, it seems to lose the dependency version restriction information.  This seems to be a bug in Visual Studio or NuGet or something, as it doesn't lose the dependency restriction information if you use the "Migrate packages.config to PackageReference" context menu.

    If you want to use PackageReference then, for now, I suggest that you leave the default as "packages.config" and then right-click on your packages.config file in your new application and select "Migrate packages.config to PackageReference", as Visual Studio then correctly migrates everything.

    Either way: I don't currently believe that this is a bug in the NuGet packages themselves, but in how Visual Studio is converting the project template to PackageReference.

    I have been looking at converting the templates to PackageReference which, if we did, may then resolve this issue.  Perhaps that needs to be higher on my list.

Children
No Data