none
Combining add-in config file with Outlook config RRS feed

  • Question

  • Hi all,

    I am creating an add-in for Outlook 2003. My problem is that I cannot access my dll.config appSettings values by using ConfigurationManager. Properties.Settings.Default will also give only the same values as when the add-in was built.

    I have searched online on many forums, but they all seem to discuss using VSTO. However, I am not using VSTO. I am using VS2010.

    Can anyone tell me how to combine the add-in config to the outlook config (or any other approach) so that I am able to get my appSetting values by calling ConfigurationMAnager.AppSettings["myKey"]?

    Thanks!

    Thimila

    Tuesday, January 29, 2013 7:44 AM

Answers

  • i must admit i do not remember anymore if vstor 2005 actually respected dll.config file. You can check it yourself by making simple add-in and printing that AppDomain.SetupInformation which i mentioned above. If it would turns out that it did not, you would have to create your own appdomain in code or use shim and modify its code to pass that info to appdomain (which is almost exactly the same).
    Thursday, February 7, 2013 5:23 AM

All replies

  • first things first - what technology you use to develop add-in? .net language? if so, do you implement IExtensibility interface directly? or something else?

    Tuesday, January 29, 2013 8:42 AM
  • Do you get any errors?
     
    Using Properties.Settings.Default.MyKey should work to retrieve the property setting value. If the setting is set to Application it cannot be changed. If it's set to User it can be changed. After you set the value make sure to save the settings.
     
    Using the settings is the same whether you're using VSTO or a shared addin or an EXE or whatever.

    --
    Ken Slovak
    [MVP-Outlook]
    http://www.slovaktech.com
    Author: Professional Programming Outlook 2007
    "Thimila Fernando" <=?utf-8?B?VGhpbWlsYSBGZXJuYW5kbw==?=> wrote in message news:582bf80d-9da8-4409-81ed-2b58e7f75e7f...

    Hi all,

    I am creating an add-in for Outlook 2003. My problem is that I cannot access my dll.config appSettings values by using ConfigurationManager. Properties.Settings.Default will also give only the same values as when the add-in was built.

    I have searched online on many forums, but they all seem to discuss using VSTO. However, I am not using VSTO. I am using VS2010.

    Can anyone tell me how to combine the add-in config to the outlook config (or any other approach) so that I am able to get my appSetting values by calling ConfigurationMAnager.AppSettings["myKey"]?

    Thanks!

    Thimila


    Ken Slovak MVP - Outlook
    Tuesday, January 29, 2013 3:15 PM
    Moderator
  • Hi Damian,

    I am using C# .NET Framework 4 on Visual Studio 2010. Yes, I am directly implementing the Extensibility.IDTExtensibility2 interface.

    Ken,

    I am not getting any errors, just that my keys are not available through the ConfigurationManager. Using Properties.Settings.Default.MyKey gives the value that is added to the settings designer as "[global::System.Configuration.DefaultSettingValueAttribute("my Key Value")]". What I need is to be able to change the .dll.config file at the client (installation) machine (using notepad) and for that value to be taken in at the next start of Outlook (and my add-in).

    Tuesday, January 29, 2013 10:27 PM
  • print to log or just use MessageBox.Show to determine during add0in startup (connect) following:

    AppDomain.CurrentDomain.SetupInformation.ConfigurationFile

    and share results with us

    Wednesday, January 30, 2013 5:14 AM
  • It prints the following:

    C:\Program Files\Microsoft Office\OFFICE11\OUTLOOK.EXE.config

    But when I check the location, there is no such file.

    Wednesday, January 30, 2013 6:11 AM
  • exactly, this is shared add-in loaded into common AppDomain, why would your add-in 'be the prettiest of them all' and have its config file set up for this domain? This domain is shared between all add-ins developed the way you are doing it. Here are your options:

    1. redevelop your add-in as VSTO - vstor will handle setting your config for you, problem solved

    2. resign from using ConfigurationManager. Properties.Settings and simply use xmlserializer or json to serialize/desierialize settings yourself from your custom config file (trust me, it is less work then is sounds)

    3. try out COM Shim Wizard that will generate c++ stub for your .net add-in and see if it sets up app domain with setupinfo properly, if not, add single line for settign your config there.

    Wednesday, January 30, 2013 7:45 AM
  • When a shared addin runs without shimming it runs in not only the same AppDomain as other unshimmed addins but in the same process and AppDomain set up for Outlook. That's why the configuration file points to a non-existent Outlook config file.
     
    Unshimmed shared addins are big potential problems. They run in the same AppDomain as other unshimmed addins and Outlook. So any crash or hang in one of those apps will cause problems for all of them. You need to shim, as Damian indicated in his #1 and #3 points. As his #2 would continue with an unshimmed addin I would not recommend that approach.

    --
    Ken Slovak
    [MVP-Outlook]
    http://www.slovaktech.com
    Author: Professional Programming Outlook 2007
    "DamianD" <=?utf-8?B?RGFtaWFuRA==?=> wrote in message news:71eaeeaa-0719-48fb-8488-0a13f9406dae...

    exactly, this is shared add-in loaded into common AppDomain, why would your add-in 'be the prettiest of them all' and have its config file set up for this domain? This domain is shared between all add-ins developed the way you are doing it. Here are your options:

    1. redevelop your add-in as VSTO - vstor will handle setting your config for you, problem solved

    2. resign from using ConfigurationManager. Properties.Settings and simply use xmlserializer or json to serialize/desierialize settings yourself from your custom config file (trust me, it is less work then is sounds)

    3. try out COM Shim Wizard that will generate c++ stub for your ..net add-in and see if it sets up app domain with setupinfo properly, if not, add single line for settign your config there.


    Ken Slovak MVP - Outlook
    Wednesday, January 30, 2013 2:46 PM
    Moderator
  • Thanks Damian, I have already tried accessing the config through xml. However, I have some pre-developed common components that access the config for things such as sql connection strings.

    Is there no way to combine the config file entries to the outlook config at runtime? If not, for me to use VSTO or the COM Shim wizard for Outlook 2003, I would have to revert to VS2008 & .NET 3.5, am I correct?

    Wednesday, January 30, 2013 10:28 PM
  • first question - no

    second one: for vsto yes, for com shim wizard - initialization of .net framework and creation of appdomain is made there in code, so if you want you could cenrtailny modify it so that it loads whatever .net version that you want. of course please remember that only from .net 4.0 there is capability to host multiple .net versions in single process.

    Thursday, January 31, 2013 5:15 AM
  • Hi Damian,

    Sorry for the long time to respond, I was stuck with some other issues on the add-in that I had to fix urgently.

    I had an idea, and I want to know the pros and cons of it, for I know it is not an optimum solution.

    What if I write to that location (C:\Program Files\Microsoft Office\OFFICE11 - the outlook installed folder) a file named OUTLOOK.EXE.CONFIG that contains my appSettings during the install of my add-in? If a file already exists, I could just merge/combine them.

    Wednesday, February 6, 2013 2:41 AM
  • first of all - writing to %programfiles% where outlook is installed required elevated priviliges. Second - what if other plugin also had this 'suboptimal' idea? you would break each other this way. If this plugin will only be used inside your own organization then i guess you could do it - if it will be released to third parties - i would refrain from going this way.
     And third option - you can always invoke those components that depend on standard app.config from other AppDomain that you created yourself with proper setupinfo.
    Wednesday, February 6, 2013 5:00 AM
  • Thanks Damian, I was looking for reasons not to do it anyhow.

    Wednesday, February 6, 2013 5:26 AM
  • Damian,

    what should I do when I need to add a config entry that is required by the system (like runtime>generatePublisherEvidence) ? If I understand VSTO / Shim correctly, adding that entry to my add-in config file will not work. Am I correct?

    How can I solve a problem like that?

    Wednesday, February 6, 2013 6:35 AM
  • what do you mean by adding? during runtime when plugin is running or something else?
    Wednesday, February 6, 2013 7:19 AM
  • no, setting it during design-time.
    Wednesday, February 6, 2013 1:05 PM
  • if by desing time you mean deployment via setup name-of-your-main-dll.config then VSTO and Shim will work just fine.
    Wednesday, February 6, 2013 1:57 PM
  • Hi Damian,

    I am unsure if you didn't understand my question or if I am not understanding your answer. For my consolation let me repeat my question in a more verbose manner:

    What I want to ask is, when I want to define (type it on the .config file) a configuration value required by the application level - such as generatePublisherEvidence (key/values that will be under other sections than the appSettings/connectionStrings) - will defining them in in my add-in config file during development make them available for the application (in my case Outlook) after deployment if I use VSTO?

    I am asking this because I found out yesterday that a colleague of mine has had a problem with VSTO on .NET 2.0 on Excel 2003 where adding generatePublisherEvidence to the add-in.dll.config did not work. He had to add it to EXCEL.EXE.CONFIG. And he has done it using the 'suboptimal' method I mentioned above.

    Wednesday, February 6, 2013 11:53 PM
  • i must admit i do not remember anymore if vstor 2005 actually respected dll.config file. You can check it yourself by making simple add-in and printing that AppDomain.SetupInformation which i mentioned above. If it would turns out that it did not, you would have to create your own appdomain in code or use shim and modify its code to pass that info to appdomain (which is almost exactly the same).
    Thursday, February 7, 2013 5:23 AM