MFIdentifier cannot be resolved in separate project

[SoftAdviceJR]

Seemingly, when using a configuration member class defined in a separate project, an MFIdentifier member cannot be resolved.

For example

Main Project

public class Configuration
{
    public ChildConfiguration ChildConfig { get; set; }
}

Separate project

public class ChildConfiguration
{
    [MFClass]
    public MFIdentifier DocumentClass { get; set; }
}

When validating this MFIdentifier it is not resolved, even when set to something like the built in document class.

[DCPDamon]

I was waiting for this topic to pop up and to see how it could be resolved. The VAF 2.2. version notes in Developer portal (https://developer.m-files.com/Frameworks/Vault-Application-Framework/Versions/#version-22) say MFIdentitifers are only automatically resolved if they are in the Configuration class. The keyword automatically makes me think there may be a way to force resolving them if they're in a different class. If not that I don't see Open/Close being truly possible here. Maybe Craig can help here?

[FredTheDane]

Hmmm, is there not a similar way we can achieve this by looking for properties that have the MFIdentifier attribute and then call the Resolve method on them?

[FredTheDane]

But yeah, perhaps Craig would be able to provide some pointers as to how to get around this.

Personally, however, I do not find this issue the biggest offender of the Open/Closed principle. Although, if your plan is to have separate projects for different parts of a VAF solution, and the only place to have configuration classes is in your main project, then You have to have circular dependencies. (Which is not great)

[FredTheDane]

Also, I may have completely butchered the upload to Nuget. But for now, here it is: https://www.nuget.org/packages/CtrlVAF.Core/

[DCPDamon]

Agreed, at this point, I'm planning on having a sub-namespace in my "common" class library which houses the main Configuration class, configuration classes for each "module" and MFIdentifiers (in the main Configuration class). Not truly Open/close, but as you indicate, adding elements to a list of Identifiers is not the worst offense.

[FredTheDane]

Would it work to have a "Configuration" project and then use that as the main configuration for the VAF?

[FredTheDane]

Agreed, at this point, I'm planning on having a sub-namespace in my "common" class library which houses the main Configuration class, configuration classes for each "module" and MFIdentifiers (in the main Configuration class). Not truly Open/close, but as you indicate, adding elements to a list of Identifiers is not the worst offense.

Or that I suppose. does it work?

[DCPDamon]

I thought about a Configuration project. but I think a configurations sub-namespace in an Common project does the same thing with vaguely less overhead. My development is not as far as yours, but yeah, so far it's worked.

[SoftAdviceJR]

By this 'in the main Configuration class' do you mean they're on the top level? Because they can be in child classes and they will be automatically resolved. It just failed when that child class was in a different project.

I've not tried manually resolving an MFIdentifier. It's worth trying out. I'm pretty busy this week though.

[FredTheDane]

By this 'in the main Configuration class' do you mean they're on the top level? Because they can be in child classes and they will be automatically resolved. It just failed when that child class was in a different project.

I've not tried manually resolving an MFIdentifier. It's worth trying out. I'm pretty busy this week though.

The manual resolving of MFIdentifiers is a bit weird. You have to provide it with a vault reference and an expected Type. I suppose it means that you also need to look for the type attribute (MFClass, MFPropertyDef and so on) before resolving.