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 Reply Children
  • 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.