What is the best way to store some data in VSTO addin?

Question

I have developed one outlook add-in, that has to be On or Off.

to do that i have declared one static variable as shown below,

ThisAddIn.cs

public static bool isAddInOn = false;

RibbonButton.cs

    private void btnRibbon_Click(object sender, RibbonControlEventArgs e)
    {
        if (ThisAddIn.isAddInOn )
        {

            ThisAddIn.isAddInOn = false; 
            btnRibbon.Label = "Disabled";

        }
        else
        {

            ThisAddIn.isAddInOn = true;
            btnRibbon.Label = "Enabled";


        }
    }

It is working. But the static variable reset again when i close outlook and open it again. That means when i open outlook by default my add-in is in disabled state.

I just want to store that value at some place. so i can check that value when outlook reopened.

Scenario:

1) open outlook

2) Enable add-in by clicking on its logo (that is in ribbon)

3) now close the outlook

4) when i open outlook again it must enabled

so how can i achieve this ?

Answer 1

Settings can be stored as a hidden (associated) item in a folder, such as the Inbox or the Calendar folder. For example, Outlook stores the list of categories as a hidden item in the Calendar folder. POP3 message ids are stored in a hidden item in the Inbox. The advantage of the hidden items is the roaming capability - Exchange mailbox user can see the data from any computer.

You can see the hidden items in OutlookSpy (I am its author) - click IMAPIFolder button, go to the "Associated Contents" tab.

Programmatically, such items can be accessed using MAPIFolder.GetStorage in the Outlook Object Model.

Answer 2

There are several techniques you can use to achieve this result. For sure your settings must be serialized to some storage/deserialized during startup of add-in.

One of possible solution could be to use registry for that (in this case probably HKCU (Current user, then it will be private for each user using your add-in) and no special permission is needed.

For storing variable:

    public void StoreInRegistry(string keyName, string value)
    {
        RegistryKey rootKey = Registry.CurrentUser;
        string registryPath = @"Software\YourCompanyName\YourAddInName";
        using (RegistryKey rk = rootKey.CreateSubKey(registryPath))
        {
            rk.SetValue(keyName, value, RegistryValueKind.String);
        }
    }

For reading variable:

    public string ReadFromRegistry(string keyName, string defaultValue)
    {
        RegistryKey rootKey = Registry.CurrentUser;
        string registryPath = @"Software\YourCompanyName\YourAddInName";
        using (RegistryKey rk = rootKey.OpenSubKey(registryPath, false))
        {
            if (rk == null)
            {
                return defaultValue;
            }

            var res = rk.GetValue(keyName, defaultValue);
            if (res == null)
            {
                return defaultValue;
            }

            return res.ToString();
        }
    }

Such stored/retrieved variable should be used during add-in initialization to set your properties. So modification could look like:

ThisAddin.cs

public static bool isAddInOn = ReadFromRegistry("MySetting1", "0") == "1";

RibbonButton.cs

private void btnRibbon_Click(object sender, RibbonControlEventArgs e)
{
    if (ThisAddIn.isAddInOn )
    {

        ThisAddIn.isAddInOn = false; 
        btnRibbon.Label = "Disabled";

    }
    else
    {

        ThisAddIn.isAddInOn = true;
        btnRibbon.Label = "Enabled";


    }
    StoreInRegistry("MySetting1", ThisAddIn.isAddInOn ? "1" : "0");
}

Other options could serialization to file - some class with settings serialized to i.e. isolated storage, database (local or central) etc.

Answer 3

I've used several methods over the years to store configuration data for users.

• Properties.Settings.Default.Properties, so writing in the application project properties. It's solid, never had an issue with it, for hundreds of users over several years.

• Local config files in text, so writing to a known area for the user with fallback. In a stable environment, one can choose the home area for the user, and read/write to the local config file, which also makes it accessible to support if it breaks and needs manual changes. As a fallback, one could write to the local temp folder.

• Registry is an option i have not used in this case, but it is likely to be a good choice.

Performance is likely a key concern considering it will impact the UI for users. Another concern is ease of use for the developer. For both, my choice would be setting it in the application's properties, where reading and writing is very simple and handled within code, and likely very fast.

Write

Properties.Settings.Default.PropertyName = propertValue;

Read

var propertValue = Properties.Settings.Default.PropertyName;

Answer 4

2018 UPDATED ANSWER

The recommended way to achieve this is now to use the already configured settings files in your project's properties. These files are auto-generated when create your project :

And open the following window when clicked :

You can access your settings value programmatically into Properties.Settings.Default.Properties anywhere.

The header bar at the top of the Settings page contains several controls:

Synchronize

Synchronize restores user-scoped settings that the application uses at run time or during debugging to their default values as defined at design time. To restore the data, remove run-time generated application-specific files from disk, not from project data.

Load Web Settings

Load Web Settings displays a Login dialog box that enables you to load settings for an authenticated user or for anonymous users. This button is enabled only when you've enabled client application services on the Services page and specified a Web settings service location.

View Code

For C# projects, the View Code button enables you to view the code in the Settings.cs file. This file defines the Settings class, which enables you to handle specific events on the Settings object. In languages other than Visual Basic, you must explicitly call the Save method of this wrapper class in order to persist the user settings. You usually do this in the Closing event handler of the main form. Following is an example of a call to the Save method: C#

Properties.Settings.Default.Save();

For Visual Basic projects, the View Code button enables you to view the code in the Settings.vb file. This file defines the MySettings class, which enables you to handle specific events on the My.Settings object. For more information about accessing application settings by using the My.Settings object, see Access application settings.

For more information about accessing application settings, see Application settings for Windows Forms.

Access modifier

The Access modifier button specifies the access level of the Properties.Settings (in C#) or My.Settings (in Visual Basic) helper classes that Visual Studio generates in Settings.Designer.cs or Settings.Designer.vb.

For Visual C# projects, the access modifier can be Internal or Public.

For Visual Basic projects, the access modifier can be Friend or Public.

By default, the setting is Internal in C# and Friend in Visual Basic. When Visual Studio generates helper classes as Internal or Friend, executable (.exe) applications cannot access the resources and settings that you have added to class libraries (.dll files). If you have to share resources and settings from a class library, set the access modifier to Public.

For more information about the settings helper classes, see Manage application settings.

Settings grid

Settings Grid is used to configure application settings. This grid includes the following columns:

Name

Enter the name of the application setting in this field.

Type

Use the drop-down list to select a type for the setting. The most frequently used types appear in the drop-down list, for example, String, (Connection string), and System.Drawing.Font. You can choose another type by selecting Browse at the end of the list, and then selecting a type from the Select a Type dialog box. After you choose a type, it's added to the common types in the drop-down list (for the current solution only).

Scope

Select either Application or User.

Application-scoped settings, such as connection strings, are associated with the application. Users can't change application-scoped settings at run time.

User-scoped settings, such as system fonts, are intended to be used for user preferences. Users can change them at run time.

Value

The data or value associated with the application setting. For example, if the setting is a font, its value could be Verdana, 9.75pt, style=Bold.

Documentation link

Reading settings

Writing settings