When I choose Tools > Run Style Cop (Ctrl + Shift + Y) it runs StyleCop over all projects, even the one which are set to not build in the current solution configuration.
How to use this hotkey to check only the projects that I want?
Check out the Disable stylecop analysis for specific projects within solution question at Disable stylecop analysis for specific projects within solution as I think this is what you are looking for.
To summarise, I managed to get this to work by adding the RulesEnabledByDefault global settings property to a Settings.StyleCop file which I put in the root folder of each project I did not want to be included in the StyleCop analysis.
<StyleCopSettings Version="105">
<GlobalSettings>
<BooleanProperty Name="RulesEnabledByDefault">False</BooleanProperty>
</GlobalSettings>
</StyleCopSettings>
If you make use of merged settings files, you may also have to include the MergeSettingsFiles global settings property. For example:
<StyleCopSettings Version="105">
<GlobalSettings>
<StringProperty Name="MergeSettingsFiles">NoMerge</StringProperty>
<BooleanProperty Name="RulesEnabledByDefault">False</BooleanProperty>
</GlobalSettings>
</StyleCopSettings>
Nope, that option isn't available in any shipped StyleCop version. If you want it added, either request the feature at http://stylecop.codeplex.com/workitem/list/basic or go ahead and add it yourself.
Related
We have a very large number of solutions spread across a wide number of repositories which do not always share a directory hierarchy in a way that makes it easy for us to update an .editorconfig such that it applies to all projects/solutions in the organization. We currently apply all of our code analysis configuration via an internal NuGet package and I was hoping we could include our organization-wide .editorconfig settings in this way as well?
I tried a quick experiment adding the following to a project to see if linked files would be honored (since we could simply add this to a props file we already have in the NuGet package), but it does not appear to be honored currently.
<ItemGroup>
<None Include="C:\SomeAlternatePath\ECTest\.editorconfig" Link=".editorconfig" />
</ItemGroup>
Is there some other MSBuild property or mechanism we could use to better facilitate this without literally writing a duplicate file to every solution/project/repo?
Is there some other MSBuild property or mechanism we could use to
better facilitate this without literally writing a duplicate file to
every solution/project/repo?
I'm afraid the answer is negative. Cause the .editorconfig file have nothing to do with msbuild or xx.csproj. Only file hierarchy can affect the behavior how the config file works. More details please check this document.
Some tests:
When I right-click project=>add .editorconfig to add this file in current project, there's one line added to the xx.csproj: <None Include=".editorconfig"/>.
If we set the indent_size = 32, it works for current project. Now we can right-click that file=>Exclude from Project to remove that file from current project system. (This action will remove the <None Include=".editorconfig"/> in xx.csproj, but the file is still in the same folder where xx.csproj exists)
Now reload the project, the settings(indent_size=32) still works. So it's obvious if we place this file in project directory, then it will take effect, no matter if we have definitions about it in project file(xx.csproj).
Suggestions:
According to your description, all your projects use the same .editorconfig file. Since this file's working scope is affected by file hierarchy, you can reduce some meaningless work by:
1.Place that file in Solution folder, it will work for all projects under that solution folder
2.Place that file in repos(C:\Users\xxx\source\repos) folder, it will work for all solutions and projects under this folder.
3.So if most of your solutions are under path C:\somepath, place that file here, all projects under that path will benefit from that. And about precedence in file hierarchy please see this one.
Hope all above makes some help :)
Up to VS2008, you set your native C++ project dependencies up in the solution file (Project Dependencies ...) and if (by default) the Linker Option
Properties -> Linker -> General : Link Library Dependencies = Yes
is set, the Visual Studio Build will automatically link in the .lib files of all projects (DLLs, LIBs) that this project is dependent on will be "statically" linked in.
Side Note: Microsoft changed how the dependencies worked in VS2010 and you are now supposed to add the dependency directly to the project
Common Properties -> Framework and References : (List of depenencies)
(each lib/dll has a separate option:
Project Reference Properties -> Link Library Dependencies : True|False
I'm fine with that. This is not what this question is about.
(One explanation here: Flexible Project-to-Project References.)
It is still possible however to define project dependencies on the Solution level and the General Linker option is also still there. However it doesn't work. See:
Link Library Dependencies not working?
Did Visual Studio 2010 break "Project Dependencies" between C++ projects?
Visual Studio 2010 not autolinking static libraries from projects that are dependencies as it should be supposed to
"but oddly enough, without removing the old UI, or in any way indicating that it no longer works"
and especially see here (acutal question follows)
MS Connect Bug 586113: "Link Library Dependencies" does not work
Where Microsoft confirms that the Linker Option doesn't do what the rest of the world's population expects it to do, and adds the following explanation:
Thanks for reporting this feedback. The issue you are experiencing is
by design. "Link Library Dependency" is a flag that only dictates
whether or not to pass the library as an input to the linker. It does
not find the dependency automatically. As a customer you will have to
define the depedency manually as you suggest.
Can anyone explain what that means, or more to the point: What does the "Link Library Dependency" linker option actually do in Visual Studio 2010?
What is an "input to the linker" that isn't actually linked supposed to be?
You have to give the setting the proper value to bring clarity:
2017 Re-Run. Yay.
TL;DR
This Option sets the default value(a) for the actual Link Library Dependecies on each project reference. If each project reference has LinkLibraryDependecies set, then it is in effect meaningless.
However, when adding a new reference, by default (in VS2010 and 2015) the new <ProjectReference> element in the vcxproj file does not have the setting set, so this option is relevant in that it provides the default for all newly added references, as long as their value isn't modified.
(a): It really should be the same for all Configurations (Debug/Release) and Platforms (Win32/x64) or things get really complicated.
Gory details
Hans pointed out that it appears to not do anything in VS2010 as such. However, this doesn't mean that it actually ain't used by VS/MSBuild.
The crux is how this option is inserted into the vcxprj file and how the defaults work for the <ProjectReference> setting in the msbuild file.
The setting on the Linker dialog as shown above is inserted as:
<Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
...
<ItemDefinitionGroup>
<ClCompile>
...
</ClCompile>
<Link>
...
</Link>
<ProjectReference>
<LinkLibraryDependencies>This option is not used by VS 2010!</LinkLibraryDependencies>
</ProjectReference>
...
</ItemDefinitionGroup>
</Project>
And while it appears to be somehow grouped together with the Link Option, that's just there to confuse you.
What this actually does in a given vcxproj file (or when coming from a .propsfile), is to set the default value of the Link Library Dependencies Value for each project dependency on the Frameworks and References section in a VS2010 VC settings dialog --
-- or in the subtree of the VS2015 References --
And this is relevant, because when you add a new project reference, the default entry in your vcxproj file will look like this:
...
<ItemGroup>
<ProjectReference Include="..\W32DynLib1\W32DynLib1.vcxproj">
<Project>{96be134d-acb5-....-....-....bb6fe4a7}</Project>
</ProjectReference>
</ItemGroup>
You'll notice that the <LinkLibraryDependecies>true|false</..> sub element is missing here: This means you "global" setting will actually be used to set the default value.
If your global setting is false (or No), the project reference won't link in anything. If it's true, it will link in.
What's more:
If this setting, LinkLibraryDependency, is completely missing from your settings, it will default to true (from the Microsoft.Cpp[.Common].propsfile in the MSBuild folder).
If you happen to have the value This is not used in your global setting, this will be interpreted as true.
If you have the value False is the new truth!, or maybe No way in this setting, it will also be interpreted as true by the build.
The VS2015 GUI will display a warning if it cannot interpret the string here:
The VS2010 GUI will display False for ALL values, except false, even though this is then interpreted as true when building the project.
What's even more:
It seems that when converting old Solutions with vcproj files, the converter will take the old dependencies that were specified in the sln and the value of the vcproj project's Linker option, and actually set the LinkLibraryDependency for each ProjectReference it inserts into the new vcxproj - thats one reason I thought that this is a dead option for so long - most of our projects have a conversion history dating back to VS2005.
Here the thing is you have to go to, project properties -> common properties -> framework and references and then add new reference to your projects. Then only it will work in VS 2010 not like in early versions of VS
This has to be set in the Properties / Common / Frameworks and References
Alternatively you can add something like the thing below in your vcxproj file, of course use the actual project you're referencing and the uuid of that project.
<ItemGroup>
<ProjectReference Include="..\Cpp\Cpp.vcxproj">
<Project>{c58574bf-9dd8-4cf8-b5b6-6551f2f3eece}</Project>
</ProjectReference>
</ItemGroup>
It seems like you also have to set
<IgnoreImportLibrary>false</IgnoreImportLibrary>
in the REFERENCED project.
Dinking around with stylecop settings files is getting annoying and messing with my repo structure. The repo is like this:
+ Trunk
+ src
- ProjectA
- ProjectB
- ...
+ lib
+ Icons
- ...
+ tools
+ NUnit
+ PartCover
- Settings.StyleCop
- ...
I would like all projects/solutions to use the settings file from trunk/tools and no others (preferable I'd like all settings file for only projects in this trunk to use that settings file, but system wide is acceptable.
I must be the only person who finds the way stylecop deals with settings files and merging settings files to be really annoying, or I just don't understand it properly.
You can create a parent settings file, which applies to all projects in subfolders of the folder where the settings file is located:
Sharing StyleCop Settings Across Projects
BUT: that means you can't put the settings file into the trunk/tools folder.
You have to put it directly into the trunk folder instead.
But in my opinion, that's no problem. I did this in my own project as well:
The StyleCop assemblies and the target file are in a subfolder named \Libs\StyleCop, only the settings file itself is in the root folder. I can live with that.
If you really don't want to put the settings file in the Trunk folder, then you do have one other option: Replace the settings file in the StyleCop install directory.
Definitely 'an option of last resort', it makes the project validate differently on another computer that hasn't replaced the default StyleCop settings file.
I wouldn't recommend going down this path unless absolutely necessary.
The best way to make all projects use the same settings is by having the settings file in the topmost directory shared by all projects, that's all there is to it.
Updated
See this guide (under, Analyzing All Projects) if you are using StyleCop.Analyzers nuget package.
If you are using StyleCop Installer (this is the old version of SyleCop), this is how it can be done:
I have several projects in my solution and I am using my Web project's StyleCop setting as the main (global) setting :
To do this, right click on any other project => StyleCop Settings
Choose: Merge with the following Settings file and choose the your main project's settings.StyleCop (in my case the Web project's setting):
That's it, now your main projects settings would be used for the other (child) project.
You can confirm this by opening your child project's StyleCop setting (note that it's hidden in VS):
And you can see that is referencing your global setting. You can repeat these step for all other required projects.
Ok, another FxCop question for today.
I've read the arguments regarding the IdentifiersShouldBeCasedCorrectly rule, and whether or not it should be "XML" or "Xml". Well, I'm an "XML" guy and I want to stay that way. Therefore, I do not want FxCop to correct me all of the time.
I have been using the SuppressMessage attribute only for specific cases. I have also used FxCop to mark a ton of errors and copied them as "module" level SuppressMessage statements into assemblyinfo.cs. That works pretty well.
However, now I really want to globally disable this annoying IdentifiersShouldBeCasedCorrectly rule. I'm using TeamCity 5.0.3, and am not using an FxCop project file (however, I could do this). I was hoping that I could pass a parameter to FxCopCmd to tell it to ignore this error, but it doesn't look that way from the documentation.
So... is there anything I can do short of creating an FxCop project file on the TeamCity build server and using it for the FxCop build runner?
Look in the install directory of FxCop (mine is c:/program files/microsoft fxcop 1.36). There should be a CustomDictionary.xml file in that directory. You can add XML to the CasingExceptions section at the end of CustomDictionary.xml and XML casing will be ignored for all namespace and function name elements of all projects on that machine (unless CustomDictionary.xml is overridden on the command line, of course).
You can also copy CustomDictionary.xml to the project directory and add XML in the CasingExceptions secion of the project directory copy. I think that this will be found automatically, with no need of an FxCop project file and will only be used for that project.
That's what I did for our TeamCity build, but I needed an FxCop project file for another reason, so I cannot remember (and cannot check) if CustomDictionary.xml will be found automatically by FxCop.
Example:
<Acronyms>
<CasingExceptions>
<Acronym>Pi</Acronym>
<Acronym>Na</Acronym> <!-- NaN -->
<Acronym>NESW</Acronym> <!-- North East South West -->
<Acronym>NWSE</Acronym> <!-- North West South East -->
<Acronym>XML</Acronym> <!-- XML -->
</CasingExceptions>
There is also a slightly different example of ignoring words at MSDN FxCop FAQ
Hope this helps!
I need to define a custom build rule for files in my projects.
However the rule may be different for different solutions (more percisely, for the same solution in a parallel dev branch).
I have two questions:
Can a .rules file be specified in a location relative to the solution? That way I'd be able to create rules per development branch.
MSDN says that the custom rule is inheritable similarly to the properties (vsprops). How can that be achieved? Where do I specify the inheritance?
Thanks,
Gil Moses.
.vcproj file will contain the following clause:
<ToolFiles>
<ToolFile
RelativePath="..\my.rules"
/>
</ToolFiles>
You can use $(SolutionDir) to customize placement of the .rules file, like this:
<ToolFiles>
<ToolFile
RelativePath="$(SolutionDir)..\..\..\my.rules"
/>
</ToolFiles>