How Can We Determine Which App.Config File Is Loading in VSTO Outlook Add-In? - vsto

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:
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.

Related

VSTO appSettings of Word AddIn cannot be changed after using MSI installer (generated through Wix)

I have a Word AddIn which uses one setting to retrieve information from a webservice. This setting is stored in de settings section of the project (see image)
To be able to change this setting after the application is compiled, the access modifier is set to public. When I compile the application and use it in Word, I only have to change the ConfigURL in de [applicaitonname].dll.config. This works perfectly, the new URL is applied when trying to retrieve information from another webserivce address (URL).
In this project, I also have a Wix project to create an MSI for this AddIn. Now when I use the MSI to install the AddIn on a computer and after the installation, I change the ConfigURL, the new value is not applied, it still uses the value which was set when creating the MSI.
does anyone know if it is possible to create an MSI for deployment, and still able to change settings values in the config file after installation?
I assume that your Wix project installs the AddIn in the Program Files folder. If that's the case then most likely your user doesn't have the write permissions to this folder. You can either adjust your Wix project to setup necessary permissions to the AddIn's folder or deploy your configuration file to a different location e.g. %APPDATA%\Roaming\[AppName].
From what I've found the VSTO customization DLLs are always loaded from a temporary folder location and not from the original location irrespective of whether ClickOnce cache is used or not. The location of the temporary folder is the Shadow copy folder of .NET framework which is mentioned under the registry key HKCU\Software\Microsoft\Fusion\DownloadCacheLocation.
Shadow Copy is a feature where DLLs can be updated while they are being used. To implement this feature, DLLs are copied to a temporary location when they are being used so that DLL at original location can be updated.
The Shadow copy feature has been used in VSTO from the initial version and there is no way to disable it. Shadow copy can be disabled for .NET AppDomain while creating an AppDomain but in the case of VSTO customization, the developer has no control over the way AppDomain is created and hence cannot configure the behavior.
In order to load a configuration file, it must be located in the same folder where the assembly is loaded from. Unfortunately, your config file does not get copied to the shadow cache so it seems it uses some hardcoded values.
In order to solve this issue, you can explicitly load a configuration file from the installation folder. Take a look at this answer for more information.

MSBUILD Dynamically Create Config XML Dotfuscator

I am trying to obfuscate bunch of files in a directory and every build there are more and more files being generated. I would like to know if there is a way I can dynamically create the Dotfuscator configuration xml file using a MSBUILD task that will generate the xml file every time there is a new file added to the directory?
This might be a good time to use the Directory input. Rather than representing a single assembly (.exe or .dll), this type of Dotfuscator input captures all the assemblies in a directory. When the contents of the directory change, Dotfuscator's build will automatically pick up any new assemblies.
To make a Dotfuscator config file with a Directory input, open the GUI and add an input as you normally would (directions for Community Edition's GUI and for Professional Edition's standalone GUI), but instead of selecting a file from the Browse... dialog, just navigate to the directory and click "Open" while the "File name" is still listed as "Folder Select". Then, save your configuration.
From now on, whenever you run Dotfuscator (whether from the standalone GUI, the command line, the Visual Studio integration, or the MSBuild task), all assemblies in the directory will be processed as input.
Note: If you look at the config file itself, you might be surprised that it will still list individual assemblies:
<input>
<loadpaths />
<asmlist>
<package refid="19e1b0c5-7221-476f-af4b-bafef68edc95">
<file dir="C:\code\BasicTestApp\BasicTestApp\bin" name="Debug" />
<asmlist>
<inputassembly refid="a6da5d8d-c181-4103-840d-d8cc7c85937a">
<option>honoroas</option>
<option>stripoa</option>
<option>transformxaml</option>
<file dir="" name="BasicTestApp.exe" />
</inputassembly>
<inputassembly refid="df84dad0-fbe8-49ab-b8c8-9fb59e706785">
<option>honoroas</option>
<option>stripoa</option>
<option>library</option>
<option>transformxaml</option>
<file dir="" name="ClassLibrary.dll" />
</inputassembly>
</asmlist>
</package>
</asmlist>
</input>
Despite this layout, Dotfuscator will process all assemblies in the C:\code\BasicTestApp\BasicTestApp\bin\Debug directory when it runs a build based off this config file, not just those two listed.
The assembly elements in the config are just there so that you can still make rules against individual assemblies in the GUI (e.g., to make one assembly be in Library Mode).
The list represents the state of the directory when the GUI last modified the config.
Disclaimer: I work for the Dotfuscator team, and am answering this question as part of my job.
Additional note due to clarification in the comments: the directory package has a feature where you can exclude certain assemblies from obfuscation. These assemblies will be treated as a Package Artifact and just copied from input-to-output without modification. Any obfuscated assemblies that refer to these excluded assemblies will still be processed correctly.
To do this in the GUI, right-click on the assembly within the package, and select "Exclude assembly from package". Or, if you'd prefer to edit the config file, add the following <option> tag as a child of each relevant <inputassembly> tag:
<option>artifact</option>
The latest Dotfuscator version 4.41.1 has the latest flag
true
This will generate the Dotfuscator config file if the file is missing. Also you can add this to the csproj as documented in the latest getting started guide https://www.preemptive.com/dotfuscator/pro/userguide/en/getting_started_protect.html

Dotfuscator : Error after obfuscation

I am using dotfuscator to obfuscate my vb.net application(myapp.exe). But i am getting error while running the obfuscated file.
Below is the error when i open the exe which is obfuscated.
"The settings property 'Import' was not found. ImportSetting"
My application uses .config(myapp.exe.config) file which has setting like below
<userSettings>
<myapp.My.MySettings>
<setting name="Import" serializeAs="String">
<value>True</value>
</setting>
</myapp.My.MySettings>
</userSettings>
If i don't obfuscate then application works fine. The error comes only if i obfuscate the my application.
Procedure i follow during obfuscation:
First i open create new project in dotfuscator.
In add input assembly i add myapp.exe and myapp.vshost.exe file from the bin folder of my project.
In build menu i select destination directory and click on build.
Now obfuscated file will be generated which i will use.
So please help me to solve this error.
You may have to manually exclude ImportSetting from renaming. If this doesn't solve your problem you should probably contact Dotfuscator Support
Note that running the obfuscator will rename everything to hide it's purpose. See here, http://msdn.microsoft.com/en-US/library/ms227212(v=vs.80).aspx.
My guess is that your <myapp.My.Settings> would have to be changed to the obfuscated name. I'm not sure how you would determine that however.
Edit: It looks like dotfuscator outputs a map.xml file that specifies all the stuff that was renamed. You should be able to lookup myapp and see what it got renamed to, then update the .config file.

NUnit not reading the configuration file

I have written a NUnit tests for a .NET application. When I run the NUnit, it does not read the connection string values from the configuration file. I tried many solutions with out success, like
Adding <assembly name>.dll.config file in the path where NUnit loads the DLL file.
Adding the configuration settings in NUnit.exe.config/NUnit.gui.config
I wasn't able to read the configuration setting even when run in VSNunit. Is there a solution?
I've assumed
Assembly being tested: SomeNameSpace.MyClassLib
NUnit assembly with unit tests: SomeNameSpace.MyClassLib.Test
Try this:
Make sure that you have also copied your app.config to your NUnit Test DLL class library (i.e. project SomeNameSpace.MyClassLib.Test) as well.
Build your NUnit Project (e.g. to SomeNameSpace.MyClassLib/bin/debug) and make sure that following are in the bin\debug (or release) directory
the assembly to be tested,
the NUnit test DLL and
the configuration (SomeNameSpace.MyClassLib.Test.config)
any other assemblies needed by your DLL file being tested.
Edit your NUnit Project in the XML view of the NUnit GUI Project editor (menu Project → Edit, or just edit it in Notepad), and make sure that the test assembly (MyClassLib.Test.dll) and the configuration file names are relative to your appbase
For example,
<NUnitProject>
<Settings activeconfig="Debug" processModel="Default"
domainUsage="Default"
appbase="C:\Temp\MyProject\MyClassLib.Test" />
<Config name="Debug" binpathtype="Auto"
configfile="bin\Debug\MyClassLib.Test.dll.config">
<assembly path="bin\Debug\MyClassLib.Test.dll" />
</Config>
<Config name="Release" binpathtype="Auto" />
</NUnitProject>
Add an app.config file to the test project and add your configurations in there.
You then have to tell NUnit what configuration to use as by default it will not pick up the app.config file.
More information on how to set this up with screenshot.
I was stuck on a similar issue for a while. We also need to look at how you are loading the assemblies, based on that the naming of configuration file changes (unless you are using an explicit configuration file from settings). As mentioned here:
http://www.nunit.org/index.php?p=configFiles&r=2.2.10
If a single assembly is being loaded, then the configuration file is given the name of the assembly file with the config extension. For example, the configuration file used to run nunit.tests.dll must be named nunit.tests.dll.config and located in the same directory as the DLL file.
If an NUnit project is being loaded, the configuration file uses the name of the project file with the extension changed to configuration. For example, the project AllTests.nunit would require a configuration file named AllTests.config, located in the same directory as AllTests.nunit. The same rule is followed when loading Visual Studio projects or solutions.

Getting rid of App.exe.config

I am working on a vb.net application that uses SQLite and since it was compiled against the version 2 of the .net framework, i added this line to my config file
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
</startup>
My final objective for the application is to make it a standalone, so not a single file except the exe (well the application will generate a file for the database, but my point is i want the user to only download 1 single file).
And i noticed that when i build it, the config file is always copied, and if i run the application without the config file, i would get the uncaught exception "legacy" error..
Is there any way to either include that config during runtime? or perhaps catch some type of exception to prevent that dialog from showing up and scaring the user (i know this probably not the best approach)
I have searched and found other similar problems on SO but none of the questions i found got to a solution that worked for me so i would appreciate your help.
While it is possible to set the legacy runtime policy at runtime, I would recommend deploying as an installer.
well the application will generate a file for the database, but my point is i want the user to only download 1 single file
They could download your installer, which could take care of setting up everything correctly. This is likely to be required in any case, as SQLite will need its own DLLs as well as your .exe to be there in the deployment.