ExcelDna icon indicating copy to clipboard operation
ExcelDna copied to clipboard

User config file not properly written with v0.34 (crashes all other Add-Ins)

Open PGsHub opened this issue 8 years ago • 7 comments

Using a settings file in Visual Studio (Express 2015) for an ExcelDna based Add-In leads to the following error for me:

  • I am using settings with the scope "User" to save some GUI settings
  • After using the Settings.Default.Save() method the settings are written to the current user.config file. All settings are properly written to the "userSettings" node, but the "configSections" sections node is missing
    • If the "configSections" node is not present in the file yet, it is still missing after the save
    • If the node was already there it remains unchanged, so no new section for my Add-In is added.
  • The app.config and the .dll.config file look fine and have the correct configSections and the sectionGroup "userSettings"
  • After downgrading to version 0.33.9 everything works as expected
  • The Add-In itself works fine (even using the config file as expected) but all other Add-Ins that try to access the settings file crash, because of the wrong format

PGsHub avatar Aug 31 '17 11:08 PGsHub

What is the “Build Action” property of your app.config file in your project?

You need the app.config file to become a file called <MyAddIn>-AddIn.xll.config in the output directory for that to be the .config file used by the add-in. (It might also make one called <MyAddIn>.dll.config, but that copy would never be used.)

If the build process is not copying app.config to <MyAddIn>-AddIn.xll.config , then it might be that your app.config file is not marked as a “Build Action: None” or “Build Action: Content”, but something else.

I’m not sure how this affects user config files –the Excel-DNA build process that was changed for v 0.34 would only affect app.config files. Excel-DNA only has special handling of the config file called <MyAddIn>-AddIn.xll.config, next to <MyAddIn>-AddIn.xll.

If this doesn’t resolve your issue, you’d need to make a self-contained project that reproduces this.

-Govert

From: PGsHub [mailto:[email protected]] Sent: 31 August 2017 13:52 To: Excel-DNA/ExcelDna [email protected] Cc: Subscribed [email protected] Subject: [Excel-DNA/ExcelDna] User config file not properly written with v0.34 (crashes all other Add-Ins) (#143)

Using a settings file in Visual Studio (Express 2015) for an ExcelDna based Add-In leads to the following error for me:

  • I am using settings with the scope "User" to save some GUI settings
  • After using the Settings.Default.Save() method the settings are written to the current user.config file. All settings are properly written to the "userSettings" node, but the "configSections" sections node is missing * If the "configSections" node is not present in the file yet, it is still missing after the save * If the node was already there it remains unchanged, so no new section for my Add-In is added.
  • The app.config and the .dll.config file look fine and have the correct configSections and the sectionGroup "userSettings"
  • After downgrading to version 0.33.9 everything works as expected
  • The Add-In itself works fine (even using the config file as expected) but all other Add-Ins that try to access the settings file crash, because of the wrong format

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/Excel-DNA/ExcelDna/issues/143, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAZTw0dY1zBG-t4Il0dzGy5d7W2hsDzpks5sdp5mgaJpZM4PIt0M.

govert avatar Aug 31 '17 12:08 govert

Thanks for the fast reply.

The Build Action for App.Config is set to none, and I have a <MyAddIn>-AddIn.xll.config in the output. Saving and loading is also working for the Add-In so generally it works. The problem is that it saves in a different structure to user.config, which leads to problems with all other Add-Ins. I will try to create a self-contained sample. Today is quite busy but hopefully I'll manage till tomorrow.

PGsHub avatar Aug 31 '17 12:08 PGsHub

I don’t know anything about the user.config, and can’t think of anything that changed in this version to affect that behaviour. Only the build process has changed, and if the -AddIn.xll.config file is right and looks the same between your v0.33 and v0.34 versions, I can’t think of anything else.

-Govert

govert avatar Aug 31 '17 12:08 govert

@PGsHub Could you put together a reproducible example that we use to test this behavior?

augustoproiete avatar Sep 27 '17 13:09 augustoproiete

@augustoproiete I was on holiday the last two weeks, and had to finish some work before that, but today I found time to make a simple example. The example AddIn serves absolutely no purpose, but it recreates the problem I faced. What I did was

  • Create the same AddIn from scratch, once by installing v0.33.9 and once by using v0.34.6 of Excel-DNA
  • The AddIns are called AddInwUserSettingsv33 and AddInwUserSettingsv34 respecitvely
  • I did not modify any .dna files
  • I added a settings file with one integer "NrUsers"
  • I then created two functions, one that shows the current setting and one that increments it by one and saves the new number to the settings file
  • v33 of the Add-In works without issue
  • v34 of the Add-In also works without issue while using it in Debug, but after starting it once all other Add-Ins that use a settings file (with user scope) are broken. (Technically it's the user.config file thats broken and not the Add-Ins)
  • I also attached my user.config file after running both Add-Ins where it can be seen that the v34 Add-In did not create the node in the configSections part of the xml.

Just ask here if you have further questions. I hope we can find the issue, and it could very well still be something on my side.

The zip file contains the 2 Visual Studio Solutions and the user.config file.

DNAUserSettingsExample.zip

PGsHub avatar Oct 03 '17 14:10 PGsHub

Thanks a lot @PGsHub for the awesome bug report and sample projects!

I was able to reproduce the behavior you described, and will investigate it further to understand if it's a bug in Excel-DNA, and a possible fix.


However, my initial tests show that this is not something that was introduced in v0.34.6, but also happens in v0.33.9, and possibly previous versions as well...

What happens, is that v0.34.6 surfaced the behavior because the build process is more complete than v0.33.9 with regards to App.config output during build.

See, in your AddInwUserSettingsv33 add-in, the only .config file that you get in the output folder is AddInwUserSettingsv33.dll.config which is automatically generated by Visual Studio during the build, and is not used by the add-in at all.

In your AddInwUserSettingsv34 add-in, besides the VS-generated AddInwUserSettingsv34.dll.config, you also get a copy of the .config for each .xll, e.g. AddInwUserSettingsv34-AddIn.xll.config and AddInwUserSettingsv34-AddIn64.xll.config (with the same content / structure, i.e. well-formatted, etc.), which is what ExcelDna loads into the AppDomain, etc. and is effectively the App.config for the add-in.

As it seems, the presence of the AddInwUserSettingsv34-AddIn.xll.config with the config section is what causes the user.config file to be written without the section in it.

If you delete the file AddInwUserSettingsv34-AddIn.xll.config in the output folder of AddInwUserSettingsv34, the user.config is written properly.

Similarly, if you copy the file AddInwUserSettingsv33.dll.config in the output folder of AddInwUserSettingsv33 into AddInwUserSettingsv33-AddIn.xll.config, you also get the same bug, now in ExcelDna v0.33.9.

As I said, I'll investigate further and follow-up on this issue.

As a temporary workaround, you might want to consider removing the sectionGroup of the userSettings, as well as the userSettings node from any of your .xll.config files - as that makes the user.config be written correctly.

augustoproiete avatar Oct 04 '17 03:10 augustoproiete

Thanks for investigating, good to know a workaround. I hope you can find the real cause of the issue!

PGsHub avatar Oct 04 '17 12:10 PGsHub