In Visual Studio, there are formatting rules found in the options menu that specify things such as where to include line breaks, how many spaces to use when tabbing (or to use tabs instead of spaces, etc.)
Is there a way to push these rules to each programmer's machine using a domain policy or some other way?
Those aren't actually rules -- they're preferences for automatic formatting applied by the IDE as you type. You can share those preferences by exporting them from one VS instance and importing them into another, but no amount of preference application will actually verify the contents of edited files.
If you want to actually apply rules regarding code formatting, you might want to consider using a tool like StyleCop.
http://www.phphosts.org/2010/05/share-the-same-visual-studio-settings-between-team-members/
That does not necessarily ENFORCE things though. You might have to do that in a login script after you figure out where those settings go.
Related
My question is in big environment preferably would like to lockdown people from editing the generated CSS files instead of in our case .scss files.
Highly recommend anyone who is using Visual Studio for front end development to check out Web Workbench plugin, that allows you to takeadvantage of precompiling CSS with SASS/LESS and javascript with CoffeeScript. You will need to install IronRuby but both are very easy installs.
You can accomplish this through the Check-in policies that come with the Team Foundation Server Power Tools. There's a forbiddenpattern policy that will prevent checking in files that match a specific pattern.
If needed, you can combine this with the Custom path policy to scope these blocked patterns to specific locations (so that you can check in the compiled result into certain folders, but not just anywhere)
You can overrule either rule, if you want, but need to provide a reason comment for that. These overrides can be monitored.
More information on Check in policies.
If you use Visual Studio 2008 and have many project files within solutions how do you keep them in sync? In other words, if you change a property in one project, how do you ensure that this property is automatically changed in other projects?
Given that enough contributors are mystified about the notion of nested solutions, I'll just work from the assumption you meant "solution with multiple projects". You give them common settings by using a project property sheet. Start with View + Other Windows + Property Manager. Open one of the nodes, right-click a configuration and choose Add New. Choose a location that makes sense for the solution, the solution directory for example. Configure the settings the way you want them.
Repeat this procedure for all other projects in your solution, now using Add Existing. Every project will inherit the settings you configured in the sheet, unless it overrides them explicitly. You may have to go back to the project properties and change an override back to "inherit".
IDE support for project property sheets is a bit flaky, be sure to save them explicitly when you make a change.
I have to say, I've not heard of "nested solutions", and I'd need a pretty compelling reason to do anything of this sort. Especially considering your question really centers on "how do I maintain duplication?" since you say the solutions will share properties. It's a cardinal rule in programming "do not duplicate thyself".
You could put the required options into a compiler response file, and use the same response file in each of your .vcproj files.
See here: http://msdn.microsoft.com/en-us/library/3te4xt0y(VS.71).aspx
Basically, you create a text file like SharedOptions.rsp, and on each line of the file specify a different command-line compiler option. Like /I.\include or /DDEFINE or whatever.
Then in the c++ command-line property page of each project, you add this in the additional options box: #"SharedOptions.rsp".
Then when you edit the options in the text file, they will be picked up by all projects. It is possible that the property manager solution provided by nobugz is just a gui for this - I don't know, I am more of a command-line kinda guy.
I guess you've already done something about this in the last 2 months, but this answer is more for the googlers...
I ended up using global variables available within Visual Studio. These were variables like $ProjectName and the like. There are many available already within VS, they can be user-defined as well.
I would like to hand edit a Visual Studio team settings file to make a few changes. Is there a documented schema anywhere (either XSD or English prose) for .vssettings files?
Could you please elaborate on what you want to edit, and why? I'd be very surprised if you came across something that isn't settable from the GUI. If you need to automate some IDE setup across multiple machines, I'd suggest IDE macros.
Technically - the answer is no. vssettings files are not validated against any schema, documented or not.
In case it isn't obvious from the element names how to achieve what you want - you might, for example, set the desired option with the GUI and diff the resulting vssettings with the initial one.
But, again, why would you want to do that?
I'd like to create a script that will configure the Visual Studio IDE the way I like it. Nothing vastly complicated, just a few Tools/Options settings, adding some External Tools, that kind of thing.
I know that this can be done inside VS with Import/Export Settings, but I'd like to be able to automate it from outside of VS. Is this possible, and if so, how?
Edited to add: doing it from outside of VS is important to me -- I'm hoping to use this as part of a more general "configure this newly-Ghosted PC just the way I like it" script.
Edited again: the solution seems to be to hack CurrentSettings.vssettings, or use AutoIt. Details below.
Answering my own question, in two ways:
In VS2005/8, the things I mentioned (Tools/Options, External Tools) are all stored in the CurrentSettings.vssettings file, in the folder "Visual Studio 200{5|8}\Settings". This file is just XML, and it can be edited programmatically by anything that knows how to parse XML. You can also just paste a new vssettings file over the top of the default one (at least, this works for me).
The larger question of configuring a virgin PC. It turns out that not everything I want to change has an API, so I need some way of pretending to be a user who is actually sitting there clicking on things. The best approach to this seems to be AutoIt, whose scripting language I will now have to learn in my Copious Free Time.
An easy way is to use the macro recorder to do something simple, then look at the code it produces and edit it as you see fit.
On my machine Visual Studio stores it's local settings in a file called VCComponents.dat. Its a text file, so perhaps you could find a way of placing your settings directly in there.
The file is stored in my users local AppData\Local\Microsoft\VC folder
I would like to have all developers on my team to use the same rules for formatting several types of code (ASPX, CSS, JavaScript, C#). Can I have visual studio look to a common place for these rules?
I would like to not rely on export/import settings as that brings many settings along. I (for example) don't care what font colors the developer uses when typing, I just want similar formatting. Can you import a subset of settings?
StyleCop, originally called "Source Analysis" is the best choice for C#. The first version was rather inflexible, but after recognizing the value that it provides for the community, Microsoft has opened it up to extensions and customizations. It's a solid tool.
For Visual Studio settings, it's trivial to export a sub-set of your settings into a .settings file and require that other team members import and use these settings.
Like any standards, the tools are only as good as the team members, so it probably goes without saying that you will need team buy-in regardless of what tool you use for enforcement.
If you're using C#, take a look at StyleCop.
Visual Studio uses the settings in Tools > Options > Text Editor > [your language] > Formatting to set how it auto-formats code.
You can set it up how you like and then use Tools > Import and Export settings to create a .settings file for your team to import and use. It won't enforce rules, but it will make the default VS behavior the same for everyone.
There is a tool called NArrange which will arrange your code. This is particular useful to avoid conflicts in source control systems, but also has several other advantages. Check out the web site.
No-one's mentioned Team Settings yet? You just export the desired settings to a network share, then get everyone to map to it. Job's a good 'un.
Tools -> Options -> Import and Export Settings, then tick "Use Team Settings"
An extensive use of Visual Assist's snippets (bits of pre-formatted codes) may help...
I second Luke's answer. StyleCop can help you enforce common coding style across your team. If you want to share formatting rules take a look at ReSharper AFAIK it allows you to export and share this settings.
Editor settings are stored in the registry, so no luck having a single source for them. You'll need to go with an external tool to ensure uniformity.
A free, quick solution would be exporting the relevant registry settings and loading them up on everyone's machine. They'll still be able to change them (and they will -- naughty developers!), but you'll at least have a common starting point.
We use the following tools:
StyleCop (as mentioned before)
Resharper
StyleCop for Resharper
The reason we use the latter two is twofold: First you are able to do a Clean Up of your code. This allows you to clean your code in one go and solve all warnings. At least that is what the brochure says. In reality you need to set quite a few settings in Resharper. Have a look at links like this to see how that works. Second: Resharper integrates the Stylecop violations in the source editor. Extremely useful as they are visible while writing code and can therefore be solved on the spot.
Code Review.