Loading per solution settings with Visual Studio 2008
If you ever work on a number of projects (company, oss, contracting), you're likely familiar with coding style issues. At MindTouch we use a number of naming and formatting styles that are different from the Visual Studio defaults, so when I work on github and other OSS projects my settings usually cause formatting issues. One way to address this is to use ReSharper and its ability to store per solution settings. But I still run into some formatting issues with Visual Studio settings that are not being overriden by ReSharper, especially when using Ctrl-K, Ctrl-D, which has become a muscle memory keystroke for me.
While Visual Studio has only per install global settings, it does at least let you import and export them. You'd figure that that could be a per solution setting, but after looking around a bit and getting the usual re-affirmation that Microsoft Connect exists purely to poke developers in the eye, i only found manual or macro solutions. So i decided to write a Visual Studio 2008 Add-in to automate this behavior.
Introducing: SolutionVSSettings Add-in
The goal of the Add-in is to be able to ship your formatting rules along with your solution (which is why I also highly recommend using ReSharper, since you can set up naming conventions and much more). I wanted to avoid any dialogs or user interaction requirements with the process, but wanted to leave open options for overriding settings in case you do use the Add-in but have one or two projects you don't want accept settings for or want to have a default setup you want to use without a per solution setting. The configuration options are listed in order of precedence:
Use the per solution solutionsettings.config config xml file
The only option for the config file right now is an absolute or relative path (relative to the solution) to the .vssettings file to load as the solution is loaded. You can check the config file in with your solution, or keep it as a local file ignored by source control and point to a settings file in the solution or a common one somewhere else on your system. Currently the entirely of configuration looks like this:
The purpose of this method, even though it is the highest precendence, is to easily set up an override for a project that already has a settings file that the Add-In would otherwise load.
Recommended default: Include 'solution.vssettings' in Solution
If no solutionsettings.config is found, the Add-in will look for a solution item named 'solution__.vssettings' and load it as the solution settings. Since this file is part of the solution and will be checked in with the code, this is the recommended default for sharing settings.
Use environment variable 'solutionsettings.config'
Finally, if no settings are found by the other methods, the Add-in will look for an environment variable 'solutionsettings.config' to find an absolute or relative path (relative to the solution) to a config file (same as above) from which to get the settings file path. This is particularily useful if you have a local standard and don't include it in your own solutions, but need to make sure that local standard is always loaded, even if another solution previously loaded its own settings.
How does it work?
The workhorse is simply a call to:
The rest is basic plumbing to set up the Add-in and find the applicable settings file.
The Add-In subclasses IDTExtensibility2 and during initialization subscribes itself to receive all solution loaded events:
public void OnConnection(object application, ext_ConnectMode connectMode, object addInInst, ref Array custom) {
_applicationObject = (DTE2)application;
_addInInstance = (AddIn)addInInst;
_debug = _applicationObject.ToolWindows.OutputWindow.OutputWindowPanes.Add("Solution Settings Loader");
Output("loaded...");
_applicationObject.Events.SolutionEvents.Opened += SolutionEvents_Opened;
Output("listening for solution load...");
}
I also setup an OutputWindow to report what the Add-In is doing. OutputWindows are a nice, unobtrusive ways in Visual studio to report status and not be seen unless the user cares.
The event handler for solutions being opened does the actual work of looking for possible settings and if one is found to load it:
void SolutionEvents_Opened() {
var solution = _applicationObject.Solution;
Output("loaded solution '{0}'", solution.FileName);
// check for solution directory override
var configFile = Path.Combine(Path.GetDirectoryName(solution.FileName), "solutionsettings.config");
string settingsFile = null;
if(File.Exists(configFile)) {
Output("trying to load config from '{0}'", configFile);
settingsFile = GetSettingsFile(configFile, settingsFile);
if(!string.IsNullOrEmpty(settingsFile)) {
Output("unable to find override '{0}'", settingsFile);
} else {
Output("using solutionsettings.config override");
}
}
// check for settings in solution
if(string.IsNullOrEmpty(settingsFile)) {
var item = _applicationObject.Solution.FindProjectItem(SETTINGS_KEY);
if(item != null) {
settingsFile = item.get_FileNames(1);
Output("using solution file '{0}'", settingsFile);
}
}
// check for environment override
if(string.IsNullOrEmpty(settingsFile)) {
configFile = Environment.GetEnvironmentVariable("solutionsettings.config");
if(!string.IsNullOrEmpty(configFile)) {
settingsFile = GetSettingsFile(configFile, settingsFile);
if(string.IsNullOrEmpty(settingsFile)) {
Output("unable to find environment override '{0}'", settingsFile);
} else {
Output("using environment config override");
}
}
}
if(string.IsNullOrEmpty(settingsFile)) {
Output("no custom settings for solution.");
return;
}
var importCommand = string.Format("/import:\\"{0}\\"", settingsFile);
try {
_applicationObject.ExecuteCommand("Tools.ImportandExportSettings", importCommand);
Output("loaded custom settings\\r\\n");
} catch(Exception e) {
Output("unable to load '{0}': {1}", settingsFile, e.Message);
}
}
And that's all there is to it.
More work went into figuring out how to build an installer than building the Add-In.... I hate MSIs. At least i was able to write the installer logic in C# rather than one of the more tedious extensibility methods found in InstallShield (the least value for your money I've yet to find in any product) or Wix (a vast improvment over other installers, but it's still the victim of MSIs.)
Installation, source and disclaimer
The source can be found under Apache license at GitHub, which also has an MSI for those just wishing to install it.
NOTE: The MSI and source code come with no express or implied guarantees. It may screw things up in your environment. Consider yourself warned!!
This Add-In does blow away your Visual Studio settings with whatever settings file is discovered via the above methods. So, before installing this you should definitely back up your settings. I've only tested it on my own personal setup, so it may certainly misbehave on someone else's setup. It's certainly possible it screws up your settings or even Visual Studio install. I don't think it will, but I certainly can't call this well tested across environment, so backup and use at your own risk.