none
Several apps use the same path for user.config files. This causes config error when debugging RRS feed

  • Question

  • I have four projects in fairly continuous development. They are all VB.net and they all use My.Settings.

    When I change from working on one to another I get a configuration error the first time I try to access My.Settings.

    On investigation it turns out that all the projects are using the same path to their user.config file:

    C:\Users\Mike\AppData\Local\Microsoft_Corporation\C__VS_Projects_Outlook_Ad_Path_n1uz4of1wqm1raru2xbg1ix44vfujobn.

    (The projects are all Outlook add-ins but that does not seem to have anything to do with it).

    When changing to work on a different app I have to delete the user config folder every time.

    Where does the path name hash get constructed and how can I change it?


    Mike VE

    Friday, April 24, 2015 8:52 AM

Answers

  • I now realize that title I gave this thread is wrong. The user settings for both add-ins should be in the same file and this works fine on my test machine. As they are add-ins to Outlook rather than free-standing apps the file path to the user.config file is determined by Outlook. It is the Outlook name and version number that is being used to generate the path.

    I am now trying to work out is why the two sets of entries clash on my dev machine but not on my test machine.


    Mike VE

    Saturday, May 2, 2015 6:03 AM

All replies

  • What is the error that you are getting?

    These files are created by the .NET Framework for you automatically. See the below link for more information:

    https://msdn.microsoft.com/en-us/library/8eyb2ct1.aspx?f=255&MSPPError=-2147217396


    Paul ~~~~ Microsoft MVP (Visual Basic)

    Friday, April 24, 2015 10:40 AM
  • Deleting those folders will remove all user related saved settings, check the below article for more details on how this works:

    http://www.dondraper.com/2011/01/easily-save-and-retrieve-application-and-user-settings-in-vb-net-or-c-apps/


    Fouad Roumieh

    Friday, April 24, 2015 11:14 AM
  • The error message is 

    Configuration system failed to initialize

    The inner exception message is 

    Unrecognized configuration section userSettings/ACal4.My.MySettings. (C:\Users\Mike\AppData\Local\Microsoft_Corporation\C__VS_Projects_Outlook_Ad_Path_n1uz4of1wqm1raru2xbg1ix44vfujobn\15.0.4711.1000\user.config line 4)

    That is because it is trying to read the user.config file created by a different project so not surprisingly the details are all different.


    Mike VE

    Friday, April 24, 2015 2:21 PM
  • The error message is 

    Configuration system failed to initialize

    The inner exception message is 

    Unrecognized configuration section userSettings/ACal4.My.MySettings. (C:\Users\Mike\AppData\Local\Microsoft_Corporation\C__VS_Projects_Outlook_Ad_Path_n1uz4of1wqm1raru2xbg1ix44vfujobn\15.0.4711.1000\user.config line 4)

    That is because it is trying to read the user.config file created by a different project so not surprisingly the details are all different.


    Mike VE

    Hello,

    Paul and Fouad has shared how that user setting files are generated and used for, based on your reply, maybe you haven't finished reading these documents shared by them.

    Speciall the following part of the one shared by Fouad.

     the values are stored in a new XML file created below the C:\Users\{username}\AppData\ folder and named user.config. For example, my file was created at the following location: C:\Users\don\AppData\Local\Microsoft\EmailSenderNet.vshost.exe_Url_layp1zjs3efmh3nnxgs3wj0if0kd3vz0\1.0.0.0\user.config.  If different users login and use your application, each user can maintain their own separate and unique values making them perfect for user specific preferences.

    Another example of the path is this…

    C:\Documents and Settings\[username]\Local Settings\Application Data\[AssemblyCompanyName]\[NameOfProject].[SomeLongUniqueString]\[AssemblyVersion]\user.config.

    Note that the Assembly Version is the last folder in the path. This means that when you change the assembly version of your application, your User scoped values will be saved in a completely new user.config file. This is actually clever and ensures that each version of your application does not clash or overwrite values from a previous version.

    So what happens to the values in the previous app.config and {yourappname.exe}.config files in the output folders? They are really just default values that your application can access at runtime if needed. The app.config is used directly by VS 2008 and updated when you edit the values in the VS project properties settings pane. The {yourappname.exe}.config files in the output folders are copies that can be distributed with your EXE in the same folder.

    But remember that when you deploy the EXE, the only values that your application will read from the {yourappname.exe}.config file are Application scoped values. Any User scoped values will be read from the user.config mentioned above.

    It will be much helpful if you could share the assembly name and the project name of these add-ins, and each error meassge when loading them.

    Regards,

    Carl


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.


    Monday, April 27, 2015 6:15 AM
    Moderator
  • Thanks for the replies.

    In order to understand better what is going on I looked at a test machine which had two of my add-ins installed. As expected the user.config file was in the relevant sub folderthe AppData Local for Microsoft_Corportation because the applications are add-ins for Outlook. What I had not realised is that the settings for both add-ins were in the same user.config file.

    The puzzle is why this is not happening on my dev machine. I had an add-in called ACal registered for Outlook and its settings were there in the user.config as expected. When I treid to register an run a second add-in called PJ1 I got an exception the first time the code tried to reference the user settings. The error was:

    "Unrecognized configuration section userSettings/ACal4.My.MySettings. (C:\Users\Mike\AppData\Local\Microsoft_Corporation\C__VS_Projects_Outlook_Ad_Path_n1uz4of1wqm1raru2xbg1ix44vfujobn\15.0.4711.1000\user.config line 4)"

    And the first few lines of the user.config file are

    <?xml version="1.0" encoding="utf-8"?>
    <configuration>
        <userSettings>
            <ACal4.My.MySettings>
                <setting name="MyEmailAddress" serializeAs="String">
                    <value>mve@greenhillsoftware.co.uk</value>
                </setting>
                <setting name="VersionDetailsHaveBeenRecordedOnWeb" serializeAs="String">
                    <value>True</value>
                </setting>
                <setting name="TotalTermDatesCreated" serializeAs="String">
                    <value>36</value>
                </setting>

    I can't see anything wrong here. Any ideas?


    Mike VE

    Friday, May 1, 2015 7:44 AM
  • This is to add to what I wrote in the previous post.

    To start work on a different add-in I had to un-register the previous add-in, so it did not start when Outlook opened, delete the user config file, register the new add-in and then start Outlook. The user config file was then created. Below are the first few lines:

    <?xml version="1.0" encoding="utf-8"?>
    <configuration>
        <userSettings>
            <PrintJust1.My.MySettings>
                <setting name="IsNewVersion" serializeAs="String">
                    <value>False</value>
                </setting>
                <setting name="MyEmailAddress" serializeAs="String">
                    <value>mve@greenhillsoftware.co.uk</value>
                </setting>


    Mike VE

    Friday, May 1, 2015 8:35 AM
  • Are you saying that PrintJust1 & ACal4 are referencing same user.config? Isn't they are different projects?

    In general I'm not sure of the reliability of the solution you running into, because as you can see the path is saved along with the version number and that means on upgrade a new file will be created but with previous settings altered by the user not in (not sure also if Outlook is managing this by copying the old version into the new path...). Are you considering a different type of storage for these values (.ini file, DB, you own settings file...)

    Check also this discussion:

    http://blogs.msdn.com/b/rprabhu/archive/2005/06/29/433979.aspx


    Fouad Roumieh

    Friday, May 1, 2015 9:22 AM
  • I now realize that title I gave this thread is wrong. The user settings for both add-ins should be in the same file and this works fine on my test machine. As they are add-ins to Outlook rather than free-standing apps the file path to the user.config file is determined by Outlook. It is the Outlook name and version number that is being used to generate the path.

    I am now trying to work out is why the two sets of entries clash on my dev machine but not on my test machine.


    Mike VE

    Saturday, May 2, 2015 6:03 AM