Menu
I am in the happy situation (</sarcasm>) where I work on a Visual Studio 2012 solution containing 168 projects.
We are working in approximately 15 of them, and the other ones we do not touch.
When we run code analysis on the entire solution it runs for 23 minutes, and that's a bit long.....
But it's also a pain when we have to figure out on each checkin which projects were touched so we can run code analysis for only those projects.
So the question is if it's possible to create a custom set of projects to run code analysis on?
709
In Solution Explorer, select the project. On the Analyze menu, select Run Code Analysis on [Project Name].
Create a custom rule set from an existing rule setIn Solution Explorer, right-click the project and then select Properties. On the Properties pages, select the Code Analysis tab. In the Active rules drop-down list, do one of the following: Choose the rule set that you want to customize.
Build and run your code in Visual Studio To build your project, choose Build Solution from the Build menu. The Output window shows the results of the build process. To run the code, on the menu bar, choose Debug, Start without debugging. A console window opens and then runs your app.
Simply put, Visual Studio doesn't have a way of running its code analysis tool on a subset of the projects in a solution.
However there are a few possible workarounds you could consider.
Extract the active projects into a separate solution:
Create a new blank solution, add all of the existing active projects to it, and run code analysis on the smaller solution. The solutions will be in sync as the project files are the same. Might give false reports if those projects depend on inactive projects.
Use an empty ruleset for inactive projects:
Add a new file of type "Code Analysis Rule Set", edit it, change its name to "No Rules" in its Properties window, and uncheck all of the rules (if any are checked).
Then go to your solution properties, select "Common Properties -> Code Analysis Settings", and change all the rulesets for inactive projects to "No Rules". You can do this in 306 clicks.
This will give the best runtime for code analysis, but will also flood the results window with CA0064: No analysis was performed because the specified rule set did not contain any FxCop rules.
Use a trivial ruleset for inactive projects:
As above, but then add any one rule to "No Rules" that you don't expect to see at all. This will make code analysis slower (but still much faster than using an actual ruleset) and you will no longer get warning CA0064.
To be perfectly honest, Visual Studio's in-built code analysis has some fundamental flaws and I would recommend the use of a professional external tool such as ReSharper, or tools suggested in other comments. Using an empty/trivial ruleset should certainly achieve the required result, but it's more of a workaround than an actual solution.
98
If you're unwilling to revisit your solution approach (which, like others, I would strongly recommend), multiple solution build configurations would probably be the simplest way to enable different sets of assemblies for code analysis under various scenarios. For example, you may wish to consider a set of solution configurations like the following (where "core" projects are the 15 you usually work on):
(If you're willing to go a bit fancy on project configurations, externalizing the relevant parts of the project-level configurations to imported MSBuild .targets files would make managing all of this across much simpler, particularly given the number of affected projects.)
Most developers would probably choose to work under DebugNoBuild or DebugCompileOnlyCore for most of their day-to-day activities, and Debug or DebugCore (as you deem appropriate) could be selected for pre-commit rule verification. Normally, I'd recommend using full Debug (with all relevant static analyses) for continuous integration builds, but that may not be practical in your case given the duration of the full analysis. If you are using CI, it might be best to use DebugCore (or a variant that compiles everything but only runs static analysis over the core projects) for the CI build, then add a regularly scheduled build that runs more frequently than daily (say every hour or two) to run a build that uses the full Debug configuration.
24
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
