0

We have a very strange problem with our VSTO Add-In.

In our Add-In there are label controls that read label text values from an app.config file and display text from the configuration file to the user:

<!-- app.config -->
<configuration>
   <configSections>
     ...
   </configSections>

   <!-- start applicationSettings -->
   <applicationSettings>
      <OurVSTOAddIn.MySettings>
        <setting name="ackMsg" serializeAs="String">
           <value>Some text here that we want to display and change</value>
         </setting>
            ...
       <OurVSTOAddIn.MySettings>
     </applicationSettings>
 </configuration>

'vb.net code
 objCheckDialog.lblAttachmentsMsg.Text = My.Settings("attachmentsAckMsg").ToString()
 objCheckDialog.lblAttachmentsMsg.Visible = True

We recently updated the app.config file to replace English display information with Kanjii for our end-users in Japan.

When we rebuilt the MSI and installed on our test machine, the add-in isn't displaying Kanjii (although it display correctly in development).

Now we're wondering if the configuration file in the installation directory is being read at all or if the information is cached or the add-in is reading from another file somewhere.

What's even more strange is that we've changed other values in our app.config file that are being used in code logic, and these seem to load properly.

We're currently using Procmon in an effort to find out how the config file is loaded, however, while filtering on the following:

  • Process Name contains Outlook
  • Path Contains "OurOutlookPlugInName"

This produces over 400 results but we don't see any file handling for our config file unless I debug the code in Visual Studio.

On our installation machine, we also removed the configuration file from the installation directory thinking this might be a clue as to whether the Add-In is reading the configuration file from the installation directory, but it had no effect, and the Add-In loaded normally displaying English instead of Kanjii again.

All of the configuration settins are at the Application Level.

Is there a way for us to tell where our Add-In is loading our configuration file from?

Have we done something incorrect in our MSI build that would prevent the updated configuration file from loading?

UPDATE:

I opened the dll file in the C:\Program Files (x86)\OurVSTOAddIn installation directory using Telerik JustDecompile to see if the configuration settings were written somewhere in the dll and I can see that under OurVSTOAddIn->My Settings there are definitely DefaultSettingValues there, as shown below:

enter image description here

This would make sense since these are Application Scoped Settings and this would prevent a user from changing config settings.

But I'm thinking if we use Application Scoped variables, each time we'll need to rebuild the msi for release, which doesn't make sense to me since the reason we want to use configuration settings for the project is to not need to rebuild for configuration changes.

Tikhon
  • 947
  • 2
  • 18
  • 32
  • 1
    This may be a really dumb question but what is ``? My app.config variables don't look like that, they look like this: `` – Chris Apr 05 '19 at 17:35
  • updated app.config for clarity. – Tikhon Apr 05 '19 at 18:53
  • 1
    If I'm reading this right, you intend to use app.config for its runtime configuration benefits? It didn't sound that way before, so I didn't think it was relevant, but that doesn't work well for VSTO. Add-ins get installed to the VSTA cache folder in an anonymized folder, and to make any changes to that file, you'd have to re-sign the deployment, and then un/reinstall the add-in. Not feasible for most use cases. – Chris Apr 05 '19 at 19:53
  • Yes, the reason we want to use configuration settings is so we don't need to rebuild each time for a simple config change, ie adding an email address. We changed the scope from User to Application scope in the Project Properties->Settings tab in Visual Studio, and *I think* the app picked up the change before we changed to Application Scope settings. – Tikhon Apr 05 '19 at 20:06
  • 1
    It's not an answer to your question, but it sounds like you need a different approach. `app.config` is not really my specialty, but maybe you can keep a copy of it separately in a public location and load it explicitly at runtime? Or just store it in a completely different file. TBH it doesn't sound to me like this file is the right place for localization; maybe a language ID but not the labels and such. – Chris Apr 08 '19 at 15:31

0 Answers0