How to implement configuration data for a vsix extension in Visual Studio 2010?

Question

I'm currently implementing a vsix extension tool window which will soon need a database connection string for querying some data to display to the developer in the tool window. I'd like to make this connection string configurable by the developer. As the developer is unlikely to change the config settings often a file would be sufficient.

Is it possible to just use an app.config file in the same folder as the sln file and if so must I use some custom configuration settings to wrap the file? NuGet seems to implement this approach but I don't fully understand the internal architecture to see how the config file is used.

I'd appreciate any alternative approaches too.

Edit:

I have since realised that the dynamic data the config store would serve must be solution specific so that a tool window used in one solution can use different properties to that of another solution. I guess one possibility would be to use the .settings file to store the location of a single config file that itself stores information related to different solutions.

Pneumatology

Answer 1

The best place to store settings for a .vsix extension is to use a .settings file. In order to create one do the following

• Right Click on the project and select "Properties"
• Go to the Settings Tab
• Click on the link to create a default settings file

This will create a couple of files in your solution.

• Settings.settings
• Settings.Designer.cs

Additionally it will bring up a designer from which new settings can be added. These can be accessed afterwards by using the Settings.Default static property

Stagehand

This looked promising but I've since realised that the properties I need to dynamically store must be solution specific hence the separate config file placed in the solution folder, or even better named by convention (MySolution.customtool.config). – Pneumatology

Limitations of Application Settings You cannot use application settings in an unmanaged application that hosts the .NET Framework. Settings will not work in such environments as Visual Studio add-ins, C++ for Microsoft Office, control hosting in Internet Explorer, or Microsoft Outlook add-ins and projects. – Winfield

@aloneguid what makes you believe that? I use Application Settings in my VSIX add-in all the time and it works properly. Visual Studio is a native process which hosts the .Net Framework. – Stagehand

MSDN: msdn.microsoft.com/en-us/library/k4s6c3a0.aspx. There must be some magic happening in VS then. – Winfield

@aloneguid yeah that documentation appears to be incorrect. It specifically lists Visual Studio as a place it won't work but I use them there regularly. Maybe it's referring to an early version of VS. I know application settings work in 10.0 – Stagehand

@Stagehand Now when F5 is run Visual Studio installs the extension to %UserProfile%\AppData\Local\Microsoft\VisualStudio\11.0Exp\Extensions\ and opens it in the experimental instance. it would be interesting get app.config file or another custom file. – Eason

This does work fine for global plugin settings, but OP asked for per-solution configuration. – Speedometer

@Stagehand this more recent -2014- pull request for Encourage shows that you seem to prefer WritableSettingsStore now. github.com/Haacked/Encourage/pull/27/files also you seem to be quoted here:haacked.com/archive/2014/07/30/… The use of application settings is not version safe in a VSIX. [...] Visual Studio itself doesn't support the use of application settings [...] The supported method of settings is the WritableSettingsStore. It's very similar to application settings and easy enough to access via SVsServiceProvider where is this quote from? – Embracery

Answer 2

Been there and in my opinion the built-in mechanism works best, detailed walkthrough: http://msdn.microsoft.com/en-us/library/ff460144.aspx

Adding a note from self I can see that the underlying implementation uses system registry subkey. However after VSIX extension uninstalled all the keys are removed automatically so your extension is not polluting the system leaving orphaned entries.

Winfield