User.config file path should have the name of the add-in's assembly

[augustoproiete]

As part of investigating #143 I've noticed that the ExcelDna's assembly is being used as evidence for the user.config file, and therefore any ExcelDna add-in user.config is written to a path that looks like %localappdata%\Microsoft_Corporation\FullTrustSandbox(Excel-DN_Path_jojpsvsna1vaszvd35jsryd0vnvv001i\16.0.8431.2079.

This means that different add-ins, running in different AppDomains, etc. will all share the same user.config file, instead of having their own.

We should consider implementing our own HostSecurityManager or our own SettingsProvider and customize this path, using the assembly evidence from the main add-in assembly, instead of using the ExcelDna's one.

[govert]

@augustoproiete The path to the add-in is in the AppDomain name. Does that make a difference?

[augustoproiete]

@govert Interesting. It doesn't seem to make a difference. From what I can see, the folder name being used to write the user.config matches what's being set when the sandboxed domain is created, which in turns uses the FriendlyName of the initial temporary AppDomain.

[govert]

@augustoproiete Ah - OK thatnks. I guess that kind of makes sense - it's the AppDomain that makes the AppDomain + config.

[markns]

Hi, I've just run into this problem - One add-in writes to C:\Users\mnuttall\AppData\Local\Microsoft_Corporation\FullTrustSandbox(Excel-DN_Path_k5suvpmhu2nsoh15qumihkf5mnzxwiy1\16.0.4795.1000\user.config and another completely unrelated add-in crashes because it tries to read the same file. @augustoproiete did you ever get any further with a solution for this?

(will also investigate more tomorrow Europe time.)

[augustoproiete]

@markns I haven't spent any time on this one yet. I believe the ideal fix would be to set the FriendlyName of the initial AppDomain to the name of the add-in defined in the .dna file (Name property), and everything would flow through.

An alternative approach would be to do the same, but from the C# side, when the FullTrustSandbox domain gets created.

In the meantime, I'd suggest using a custom user config file that you handle yourself using JSON, XML, HOCON, etc.

[PGsHub]

Hi, another side effect of this keeps popping up for me:

• The standard path for a C# application's user file looks like:

%USERPROFILE%\Local Settings\Application Data\<Company Name><appdomainname>_<eid>_<hash>\<verison>\user.config

• So in the standard case a new folder is created for each new assembly version, which leads to a default config file after an update (the old settings can be restored via the Upgrade method of ApplicationSettingsBase)

• Because of the issue above all active add-ins of our company share the same user file, which is generally not a problem, but since any update of any assembly triggers a new settings file and folder, these settings are quite often lost

I have not investigated this issue further yet (but plan to). My open questions are:

• Find out the exact rules, when a new folder is created (I just observed a lot of folders, but have not tested my assumption that a new one is created for each updated assembly)

• Test if the upgrade functionality restores the settings of all other add-ins as well, or just the one of the current add-in. If all settings are restored, then as a workaround I would just have to implement this restoration for each add-in so that the first "used" one restores all settings

Of course it would be great to have a settings behaviour more in line with the default case above, but the most important thing for me at the moment is understanding exactly how the settings path is determined and which condition(s) lead to the creation of a new one

Again - thanks for all your hard work

[govert]

After an attempt to understand this last year, I abandoned the user.config file approach for an file / registry combination that the add-in manages explicitly. The built-in .NET configuration stuff is problematic for a few reasons, one is that configurations are also lost across Excel updates. It really is not meant for shared hosting of components in a parent process.

One can build a custom SettingsProvider to integrate in the .NET Setttings world, but that provides little value for the effort. I suggest you just do your own thing.

I would, however, be willing to consider specific suggestions for what we do in Excel-DNA, e.g. regarding the AppDomain name.

[PGsHub]

Thanks for the update. Since Excel updates (which happen quite often) create new settings folders, I have now also moved to using my own settings file in JSON format. A lot more flexibility with this approach.

The only sensible solution to using the .NET config files seems to be creating a custom settings provider like in https://stackoverflow.com/a/11398536/7000882 in the ExcelDNA assembly using the name of the main add-in assembly from the .dna file. But I am also not sure if this is worth the effort.