Problems loading .NET config from EA AddIn

[g.makulik]

I'm just clutching on any straw I could get!
I have an EA plugin implementation based on a framework (Geert Bellekens EAAddInFramework) and like to extend the framework to manage a .NET managed configuration for handling MDG connected packages settings. There are some strange problems when trying to load the .config file(s).

Sorry that I'll not repeat all the details here, I've posted a (more generalized) question on stack overflow: .NET custom configuration section: Configuration.GetSection throws 'unable to locate assembly' exception

Does anyone have an idea what's going wrong with this? I'm afraid it could be some specific issue about how EA loads AddIn's  :-/.

Best regards,
Günther

[Geert Bellekens]

To be complete, here's a copy of my response on stackoverflow:

I tried that as well, but I never got it to work like that. I just figured loading a .config automatically doesn't work for .dll's only for .exe's. Then I gave up and decided it would be easier to just load the .config file manually. You can see the full code here: https://github.com/GeertBellekens/Enterprise-Architect-Toolpack/blob/master/EANavigator/NavigatorSettings.cs This is the most relevant part:

Code: [Select]

public NavigatorSettings()
        {
          Configuration roamingConfig = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.PerUserRoaming);

          //the roamingConfig now get a path such as C:\Users\<user>\AppData\Roaming\Sparx_Systems_Pty_Ltd\DefaultDomain_Path_2epjiwj3etsq5yyljkyqqi2yc4elkrkf\9,_2,_0,_921\user.config
          // which I don't like. So we move up three directories and then add a directory for the EA Navigator so that we get
          // C:\Users\<user>\AppData\Roaming\GeertBellekens\EANavigator\user.config
          string configFileName =  System.IO.Path.GetFileName(roamingConfig.FilePath);
          string configDirectory = System.IO.Directory.GetParent(roamingConfig.FilePath).Parent.Parent.Parent.FullName;

          string newConfigFilePath = configDirectory + @"\Geert Bellekens\EANavigator\" + configFileName;
          // Map the roaming configuration file. This
          // enables the application to access
          // the configuration file using the
          // System.Configuration.Configuration class
          ExeConfigurationFileMap configFileMap = new ExeConfigurationFileMap();
          configFileMap.ExeConfigFilename = newConfigFilePath;      
          // Get the mapped configuration file.
           currentConfig = ConfigurationManager.OpenMappedExeConfiguration(configFileMap, ConfigurationUserLevel.None);
          //merge the default settings
          this.mergeDefaultSettings();
        }

Geert

[g.makulik]

Thanks for your help so far Geert!
I have studied you code sample and understand that you're avoiding calling the Configuration.GetSection() method at all (that should do all the mapping and merging from the XML automatically).
I also understand that you're going to de-/serialize the properties directly from the loaded configuration directly, but these are all primitive types (i.e. XML attributes), right?
I need to have complex XML/Configuration types (collections/elements), and I'm not sure how this might work without type serializers for these. I'll have to experiment with this ...

The stupid thing about this problem is, that the assembly that's claimed to be missing by the standard configuration serializer is guaranteed to be loaded, because it calls the code itself. Is there maybe a method to register it with the ConfigurationManager explicitly?

Best regards,
Günther

P.S.: I've also updated the question on SO with some additional info.

[Geert Bellekens]

Yes indeed, my usage of the .config file is rather basic.
I have either booleans or a string, nothing more.

So I'm afraid I can't help you with the complex stuff.

Geert

[g.makulik]

I've started a bounty on SO about this topic, so if anyone feels attracted ...

What I'm mainly interested with this forum is, if someone of the 'Sparxians' could give some insight about the AddIn loading mechanism and if this might cause issues with what I want to do (sorry for referring details to another forum, see the links from above).

Best regards,
Günther

[g.makulik]

BUMP!

Maybe can s.o. of the Sparxians around here give more insight about this question? It seems to boil down to:

Will an AddIn (implemented as .NET assembly) be loaded into the Application Domain?

If not, the .NET [size=13]System.Configuration.ConfigurationManager[/size], resp. [size=13]System.Configuration.Configuration[/size] won't be able to resolve any type references to the AddIn's classes made in a .config file, without having the AddIn assembly registered with the GAC (as far I understand everything right now).

Is this correct  :-/?

Any help appreciated,
Günther

[RoyC]

Send this in to Sparx Support, where it will be assigned to the best person to respond. It doesn't look as if that Sparx person is one of the regular forum browsers!