none
Is using ConfigurationManager and connectionstrings in VS2010

    Question

  • Hi

    I created a Word 2007 VSTO Add-in some years ago using Visual Basic in VS 2008 and .NET Framework 3.5.

    Now I'm working with converting the project to Word 2010, and then had to shift to VS 2010.

    The project "auto-converts" as expected when I open it in the new development environment.

    All issues then has been solved exept one: The processing of the connectionstring in the app.config file.

    In the original project the connectionstring in the app.config file was a "dummy", and when the Add-in was loaded, the
    correct connectionstring was updated in the config file using the sub below.

        Friend Sub ChangeConnectionString(ByVal strConn As String)
    
            Dim DBconfig As System.Configuration.Configuration = System.Configuration.ConfigurationManager.OpenExeConfiguration(System.Configuration.ConfigurationUserLevel.None)
    
            DBconfig.ConnectionStrings.ConnectionStrings("SKBMall.MySettings.SKBOfficeDBConnectionString").ConnectionString() = strConn
            DBconfig.Save(System.Configuration.ConfigurationSaveMode.Modified)
            System.Configuration.ConfigurationManager.RefreshSection(DBconfig.ConnectionStrings.SectionInformation.Name)
            My.Settings.Reload()
    
        End Sub
    

    This code ran well both in debugging and later on when the slution was deployed to the clients.

    In the Office 2010 / VS 2010 scenario the sub above doesn't even find the config file.
    After some changes in the sub a got the config file to change, but it doen't help.

    When the form is loaded the databound lists are empty, as if the old connectionstring is loaded into memory before I had it changed using the sub.

    Only way I had it to work is when I write the correct connectionstring, (with password and all into the app.config) remove the call to the sub ChangeConnectionstring and deploy it this way.

    This can't be the way it is meant to be, is it?


    Best Regards Peter Karlström Midrange AB, Sweden

    Thursday, March 22, 2012 5:59 PM

Answers

All replies

  • Hi Peter,

    Thanks for posting in the MSDN Forum.

    It's based on my experience that you have lost your configuration file after you project migrated. I tried following snippet. It works fine on my side. And the code in Else will only work at the first time to create the configuration item. It will not work again after configuration item has been created.

        Friend Sub ChangeConnectionString(ByVal strConn As String)
            Dim DBconfig As System.Configuration.Configuration = System.Configuration.ConfigurationManager.OpenExeConfiguration(System.Configuration.ConfigurationUserLevel.None)
            Dim Con As Object
    
            Con = DBconfig.ConnectionStrings.ConnectionStrings("SKBMall.MySettings.SKBOfficeDBConnectionString")
            If Con IsNot Nothing Then
                DBconfig.ConnectionStrings.ConnectionStrings("SKBMall.MySettings.SKBOfficeDBConnectionString").ConnectionString = strConn
            Else
                DBconfig.ConnectionStrings.ConnectionStrings.Add(New System.Configuration.ConnectionStringSettings("SKBMall.MySettings.SKBOfficeDBConnectionString", "***", "****"))
            End If
            DBconfig.Save(System.Configuration.ConfigurationSaveMode.Modified)
            System.Configuration.ConfigurationManager.RefreshSection(DBconfig.ConnectionStrings.SectionInformation.Name)
            My.Settings.Reload()
        End Sub

    I hope it can help you.

    Have a good day,

    Tom


    Tom Xu [MSFT]
    MSDN Community Support | Feedback to us

    Friday, March 23, 2012 4:35 AM
  • Hi Tom

    Thanks for your reply.

    I have tested your solution, and it don't work in the deployed environment.

    The call to changeConnectionstring returns an error (translated from swedish):

    An error occurred reading the configuration file: Access to the path C:\Program Files x(86)\Microsoft Office\Office14\zwijruvl.tmp is denied. (C:\Program Files x(86)\Microsoft Office\Office14\WINWORD.config)

    It seems the correct config file, located in the same directory as the .dll, .vsto and .manifest files not is located.

    This config-file is packed together with the DLL when the MSI setup package is created. The source-fil from where the config-file is created
    is correct.
    Also the correct config-file which is located in the same directory as the DLL contains the connectionstrin. Se below.

    <?xml version="1.0" encoding="utf-8" ?>
    <configuration>
        <configSections>
        </configSections>
        <connectionStrings>
            <add name="SKBMall.MySettings.SKBOfficeDBConnectionString" connectionString="Provider=Microsoft.ACE.OLEDB.12.0;Data Source=C:\Program Files (x86)\SKB Office\SKBOfficeDB.accdb;Jet OLEDB:Security Persistent=True;"
                providerName="System.Data.OleDb" />
        </connectionStrings>
        <system.diagnostics>
    .....

    It feels as if (as you suggests) there has been some errors during the conversion of the project, but how can I recreate the relationship between the datasources in the forms and the settings in the project.


    Best Regards Peter Karlström Midrange AB, Sweden

    Friday, March 23, 2012 3:24 PM
  • Hi Peter,

    I think this snippet can solve your issue. It works fine on my side.

    Imports System.Xml
    Imports System.IO
    
    Public Class ThisAddIn
        Public DBconfig As System.Configuration.Configuration
        Public dd As String
    
        Private Sub ThisAddIn_Startup() Handles Me.Startup
            Dim Writer As XmlWriter
            Dim WriterSetting As XmlWriterSettings
            'You can omit it if you use app.config in your project. It just used to create a configuration file if it not exist.
            If File.Exists(AppDomain.CurrentDomain.SetupInformation.ConfigurationFile) Then
            Else
                WriterSetting = New XmlWriterSettings
                WriterSetting.Indent = True
                WriterSetting.IndentChars = "  "
                Writer = XmlWriter.Create(AppDomain.CurrentDomain.SetupInformation.ConfigurationFile, WriterSetting)
                Writer.WriteStartElement("configuration")
                Writer.WriteStartElement("connectionStrings")
                Writer.WriteEndElement()
                Writer.WriteEndElement()
                Writer.Close()
            End If
            ChangeConnectionString("Test")
            dd = DBconfig.ConnectionStrings.ConnectionStrings("SKBMall.MySettings.SKBOfficeDBConnectionString").ConnectionString
            Application.ActiveDocument.Range().Text = dd
        End Sub
    
        Private Sub ThisAddIn_Shutdown() Handles Me.Shutdown
    
        End Sub
    
        Friend Sub ChangeConnectionString(ByVal strConn As String)
            Dim Con As Object
            'Please pay attention to "AppDomain.CurrentDomain.SetupInformation.ConfigurationFile" it will show your correct filepath of your add-in project.
            DBconfig = System.Configuration.ConfigurationManager.OpenExeConfiguration(AppDomain.CurrentDomain.SetupInformation.ConfigurationFile.Replace(".config", ""))
            Con = DBconfig.ConnectionStrings.ConnectionStrings("SKBMall.MySettings.SKBOfficeDBConnectionString")
            If Con IsNot Nothing Then
                DBconfig.ConnectionStrings.ConnectionStrings("SKBMall.MySettings.SKBOfficeDBConnectionString").ConnectionString = strConn
            Else
                DBconfig.ConnectionStrings.ConnectionStrings.Add(New System.Configuration.ConnectionStringSettings("SKBMall.MySettings.SKBOfficeDBConnectionString", strConn, "dddd"))
            End If
            DBconfig.Save(System.Configuration.ConfigurationSaveMode.Modified)
            System.Configuration.ConfigurationManager.RefreshSection(DBconfig.ConnectionStrings.SectionInformation.Name)
            My.Settings.Reload()
        End Sub
    
    End Class

    Have a good day,

    Tom


    Tom Xu [MSFT]
    MSDN Community Support | Feedback to us


    Monday, March 26, 2012 5:40 AM
  • Hello, just a quick question:

    Why - if you replace all Settings by code,

    don't you create a Connectionstring from Scratch in your code?
    My personal experience is: using .Config files ist not the best.
    You may loose Settings when you upgrade to another Version of your AddIn.
    So I use my own SQL Compact or the Registry(easy) for Settings.
    Office itself still uses the Registry for some Settings.
    You can encrypt the username and password when stroing it into the Registry.
    (A Hacker can still use a IL Disassembler and see your password you set in .Net code in Plaintext)
    So -> the safetylevel is the same I think.

    Greets - Helmut


    Helmut Obertanner [http://www.obertanner.de] [http://www.outlooksharp.de]

    Monday, March 26, 2012 6:45 AM
  • Hi Tom

    Thanks for hanging in here with me.

    There must be som major differences between my configuration and yours.

    If I edit my database dataset in the form and change the connectionstring, the local app.config is affected.
    My Add-in is called SKB Mallapplikation .NET.dll, so the configuration file will be named SKB Mallapplikation .NET.dll.config, and placed in the same directory as the .DLL, the .manifest and the .vsto files when I create a standard msi-setup project in VS 2010 and adds the projects output (which is the .dll file and the app.config file)

    But your sample code picks the config file C:\Program Files (x86)\Microsoft Office\Office14\winword.config when I use it, and this file don't exist, and the users will not have write authority in that directory when the Add-in is deployed.

    What is wrong with my Add-In project or my setup project?


    Best Regards Peter Karlström Midrange AB, Sweden

    Monday, March 26, 2012 8:40 AM
  • Hi Helmut

    Thanks for replying

    The password for the database is already encrypted in the registry, and the connection-string is altered with this value when the Add-in is started, i.e. a new connectionstring is created/updated.

    The problem is that several forms in the project has databound controls which is configured with the connectionstring in the configSections in the local configuration file. These are dependent of the configuration file which is deployed with the Add-In.
    This has been working like a charm for 3 years with Office 2007 and VS2008.

    So why is it not working any longer?


    Best Regards Peter Karlström Midrange AB, Sweden

    Monday, March 26, 2012 8:45 AM
  • Hi Peter,

    Do you real try my snippet which I post in March 26? I consided the situation you mentioned. And my snippet will access the configuration file which save with your vsto and dll file. I recommend you try it. It will not access  C:\Program Files (x86)\Microsoft Office\Office14\winword.config.

    Have a good day,

    Tom


    Tom Xu [MSFT]
    MSDN Community Support | Feedback to us

    Tuesday, March 27, 2012 6:17 AM
  • Hi Tom

    Yes, I have tried your snippet in my project, and it works fine running in VS2010.
    But when deployed, it want's to create the file winword.config in the folder C:\Program Files (x86)\Microsoft Office\Office14. The user has no write access to this folder, but if I permit it, the file is created there.

    I also tested some other approaches, and this made me really confused;

    I edited the solution, so that the correct connectionstring with a password was saved in the app.config file.
    I removed the parts responsible for changing the connectionstring.
    I then compiled it and recreated the setup files in the separate setup solution.
    After deployment, I deleted the local config file in the target client, and everything works anyway.

    This means that the password is "hidden" somewhere in the code, and the changes made to configSettings is of no effect for the deployed Add-In. So why is it part of the setup solution?

    This makes me wonder:
    1. If this is correct, does this apply to other settings in the config file too, for example basicHttpBinding for WebService settings?

    2. Why is it that the config.file automaticcally adds to the Project Output in the Setup solution? I'd rather deploy without it, if it is of no use to the deployed Add-In.


    Best Regards Peter Karlström Midrange AB, Sweden

    Tuesday, March 27, 2012 7:04 AM
  • Hi Peter,

    I sent you a sample which I developed. I hope it can solved your issue. I don't know what's matter on your side. The snippet works fine on my side. Following screen shooting will explain it.

    <iframe frameBorder="0" height="120" marginHeight="0" marginWidth="0" scrolling="no" src="https://skydrive.live.com/embed?cid=BFDF05E934413519&resid=BFDF05E934413519%21369&authkey=ALOfw7wxzE9RLzM" style="padding:0px;background-color:#fcfcfc;" title="Preview" width="98"></iframe>

    https://skydrive.live.com/#cid=BFDF05E934413519&id=BFDF05E934413519%21121 WordAddInConfiguration.zip

    Please try to deploy my add-in for the publish folder in project. Let's see whether it can work on your side. If it still not work, please feel free to let me know. I will involve some senior engineers look into this issue.

    Have a good day,

    Tom


    Tom Xu [MSFT]
    MSDN Community Support | Feedback to us


    Wednesday, March 28, 2012 1:54 AM
  • Hi Peter,

    I was having the same problem as you. An older VSTO Excel Document Project (2005 -> 2008 -> 2010) was unable to deploy. Unable to read the configuration and connectionstrings. The only connectionstring that returned was the one in the machine.config. But the one in the config file in the installation folder wasn't read.

    For deployment, I used the guidelines in Deploying a Visual Studio 2010 Tools for Office Solution Using Windows Installer. After reading your exact same problem, I returnded to these guidelines because I never did the last step: Changing the Location of the Deployed Document. Because I didn't want it in the "My Documents" folder as we created a Start menu short cut. So it felt not necessary to do this step.

    But it seems that this step isn't optional. I changed my setup and added this last step, copying it to the "My Documents" folder and after doing that, the deployment solution was working! So, did you do this last step in your deployment process?

    I changed the code from the AddCustomizationCustomAction project a bit so it would only customize my local file in the installation folder without copying it to the "My Documents" folder (see small quick and dirty code changes in code below). And again, after deploying, it was working, reading the connectionstrings from the config file in the install folder.

    ...
    // File.Copy(documentLocation, targetLocation);
    ...
    
    string CreateTargetLocation(string documentLocation)
    {
    /*
       string fileName = Path.GetFileName(documentLocation);
       string myDocuments = Environment.GetFolderPath(
       Environment.SpecialFolder.MyDocuments);
    
       return Path.Combine(myDocuments, fileName);
    */
       return documentLocation;
    } 

    Wednesday, March 28, 2012 5:02 AM
  • Hi Tom

    Thanks for your support

    When I look into your project (which by the way works if I deploy it in my test environment) there are several differences to my solution;

    1. Your project is targeting .NET Framework 4.0, My project (and all included parts) is targeting .NET Framework 3.5.
    2. You deploy your solution using the Publish method in the Add-In project. My Setup solution consists of several separate parts;
      Add-ins for Word, Excel, Powerpoint together with a separate database update program, an Excel UDF-Addin dll and two Webservice components for connecting the Addins to a Web-based document handling system.
      The customer want's the deplyment on their clients do be done with one installation.

    Is the problem in my setup solution? Then maybe Wouter Steegmans reply below is what I have to check out.

    Can you please answer my question #1 regarding the non-existing config files as I asked about on march 27? Maybe my quick fix solution could be to remove the files after deploy.

     Thanks in advance


    Best Regards Peter Karlström Midrange AB, Sweden

    Wednesday, March 28, 2012 8:54 AM
  • Hi Wouter

    Thanks for replying

    This was new! Thanks a lot. Maybe this is what I really has been looking for.
    I had no idea the changed these parts from VS2008.

    Again, thanks


    Best Regards Peter Karlström Midrange AB, Sweden

    Wednesday, March 28, 2012 8:55 AM
  • Hi Peter,

    My solution also OK on Visual Studio 2008. In my solution I get the configuration via AppDomain due to every add-in will create a specific AppDomain for itself and the SetupInformation will not affect via host program. And the AppDomain.CurrentDomain.SetupInformation.ConfigurationFile will point to the correct configuration which in the Add-in setup folder instead of Winword.config. And the way to distribute the add-in will not affect it at all.

    Wouter's work round is OK also, you might try it.

    @Wouter,

    Thanks for sharing your work round.

    Have a good day,

    Tom


    Tom Xu [MSFT]
    MSDN Community Support | Feedback to us

    Thursday, March 29, 2012 7:24 AM
  • Hi Tom

    In my former solution, I have created a Windows installer setup project, in which I have added the 4 separate Add-In projects.

    Database (Access), update program and office templates are put in a specific folder (C:\Program Files\SKB Office). The Add-ins VSTO and Manifest files together with project outputs (DLL and config files) are put in a subfolder (\bin). Registry values for the Add-ins are manually added.

    Are this not the proper way of deploying a complex Office Add-In solution to the clients?


    Best Regards Peter Karlström Midrange AB, Sweden

    Friday, March 30, 2012 7:03 AM
  • Hi Peter,

    What's value of the AppDomain.CurrentDomain.SetupInformation.ConfigurationFile after your deployed your add-in?

    Have a good day,

    Tom


    Tom Xu [MSFT]
    MSDN Community Support | Feedback to us

    Monday, April 02, 2012 7:35 AM
  • Hi Peter,

    Any update?

    Have a good day,

    Tom


    Tom Xu [MSFT]
    MSDN Community Support | Feedback to us

    Tuesday, April 03, 2012 5:52 AM
  • Hi

    Please Tom, have patience.

    I have not had the time to reinstall and test my deployment yet. I'm almost certain that the path is to Winword.exe, but I wanted to be sure, so I have planned to re-test it.

    In the meantime, I would be happy if you could answer my previously questions in this post.

    • 2012-03-28: Can you please answer my question #1 regarding the non-existing config files as I asked about on march 27? Maybe my quick fix solution could be to remove the files after deploy.
    • 2012-03-30: Are this not the proper way of deploying a complex Office Add-In solution to the clients?


    Best Regards Peter Karlström Midrange AB, Sweden

    Tuesday, April 03, 2012 6:03 AM
  • Hi Peter,

    "Can you please answer my question #1 regarding the non-existing config files as I asked about on march 27? Maybe my quick fix solution could be to remove the files after deploy."

    As Word add-in, I think we aren't able to said it is a independent application, it just a extension of Word. It will work after Word execute. So it will use winword.config in Word if you don't set addtional information in your add-in. I don't think app.config useless. If you can set correct information in add-in it will work. As you mentioned your add-in works with out app.config due to you write the logic in your add-in and your add-in will create configuration file automaticlly. The snippet I shown to you have such kind of logic in order to avoid expection in your project. If you haven't used such kind of logic you will meet exception. So I think remove configuration file after deployed is meaningless.

    "Are this not the proper way of deploying a complex Office Add-In solution to the clients?"

    I have no idea about it. If it can let your deploy action became easier it will make sense. I don't think it will effect your issue. Iwould recommend you try me snippet which I post in the March 26th if you have time. I will add some comment in that reply to give your more information for my add-in sample. I think it just a good idea to set connectionstring in configuration file of your add-in if you know correct way to address it.

    Have a good day,

    Tom


    Tom Xu [MSFT]
    MSDN Community Support | Feedback to us

    Wednesday, April 04, 2012 5:58 AM
  • Hi Tom

    Finally!

    The value of AppDomain.CurrentDomain.SetupInformation.ConfigurationFile after deployment is:

    C:\Program Files(x86)\Microsoft Office\Office14\WINWORD.config

    This also is what I have previously reported.


    Best Regards Peter Karlström Midrange AB, Sweden

    Wednesday, April 04, 2012 2:25 PM
  • Hi Tom

    Thanks for repying on my previous questions.

    As for question 1, in this deployment I had removed all code for changing configuration data. The correct database connectionstring was compiled into the program.

    In this scenario, I deleted the config-file in the deployment folder, and the forms with databound controls continued to work correctly.

    That is why I asked the question, because this means the local config-file is not used for setting connectionstrings for Windows forms with databound controls.


    Best Regards Peter Karlström Midrange AB, Sweden

    Wednesday, April 04, 2012 2:32 PM
  • Hi Peter,

    This is the sample written via Visual Studio 2008 traget .NET Framework 3.5. This is a Word add-in for 2007 and I think it also work under Word 2010. In this Sample which I don't change anything of my snippet. It works fine on my side. I have not 64-bit environment to reproduce your issue. However I think it will work.

    "That is why I asked the question, because this means the local config-file is not used for setting connectionstrings for Windows forms with databound controls. " I don't think so. I would recommend you create a simple Word add-in and add app.config file into that project, fill in connectiongStrings, use AppDomain.CurrentDomain.SetupInformation.ConfigurationFile to access them in ThisAddIn_Startup method and use msgbox to prompt a message box to show AppDomain.CurrentDomain.SetupInformation.ConfigurationFile. Then deploy it, to see which will be show. Please show me the screen shooting for this action. I will analysis your situation for further research.

    Have a good day,

    Tom

    Please goto https://skydrive.live.com/?cid=bfdf05e934413519#cid=BFDF05E934413519&id=BFDF05E934413519%21121 to download WordAddInConfigurationIssue.zip to see whether it works for you. please notic that the click once setup file might can't install the add-in correctly. Try to hook Word via edit registry hive manually.


    Tom Xu [MSFT]
    MSDN Community Support | Feedback to us




    Thursday, April 05, 2012 5:58 AM
  • Hi Tom

    Thanks for your support, but this doesn't lead to anything....

    This post is started with information about a fully functional VS2008/Office 2007 VSTO Add-In, which, lifted to VS2010/Office2010 in a Windows 7 64-bit environment behaves differently.

    Testing your sample for VS2008/Office2007 32-bit don't make sense to me at this time.

    I will reset this whole project in VS2010 and start all over again later this spring. The customer has postpone their release of the new platform to quarter 1 of 2013, so I have got the time to check this out more thoroughly.

    I will get back to this post if and when I got this mess figured out.


    Best Regards Peter Karlström Midrange AB, Sweden

    Thursday, April 05, 2012 7:02 AM
  • Hi Peter,
    From a support perspective this is really beyond what we can do here in the forums. If you cannot determine your answer here or on your own, consider opening a support case with us. Visit this link to see the various support options that are available to better meet your needs:  http://support.microsoft.com/default.aspx?id=fh;en-us;offerprophone

    Tom


    Tom Xu [MSFT]
    MSDN Community Support | Feedback to us


    Friday, April 06, 2012 6:30 AM
  • Hi

    Here is the correct answer to this issue:

    Since VS2010 SP1 there has been a change in the loading process for an Office 2010 Addin.

    In all previous guides, the value to be entered in the Manifest key of the Addin regitry-section when using an Setup project in VS2010 has been: [TARGETDIR]bin\AddinName.vsto|vstolocal.

    If the Addin is loaded this way, security locks access to the local config-file, and instead then parent executabels config file is targeted, in this case Winword.exe.config.

    In order to make this work, you have to add file:/// in front of the previous string, so that the Manifest now reads: file:///[TARGETDIR]bin\AddinName.vsto|vstolocal.

    More can be read on this blog page: http://blogs.msdn.com/b/vsod/archive/2011/06/14/vsto-4-0-sp1-will-cause-a-vsto-addin-to-not-find-its-config-file.aspx


    Best Regards Peter Karlström Midrange AB, Sweden


    Wednesday, June 20, 2012 8:39 AM