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

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.

[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]

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.