Question

For working with VS2005 and VS2008 we defined our current ca rules in a sharepoint list.

In the list there is a column where all excluded assemblies are listed semikolon sepperated.

A custom build task read the sharepoint list and was responsible to exclude the specified rule in the project file with "-!CA..." in a team build.

Now we are planning to migrate our projects to VS 2010 and the new code analysis ruleset make some problems.

First idea was to

  • create the ruleset file from sharepoint
  • add a GlobalSupressions.cs as a solution item and add the file in every project as a linked file
  • create a SupressMessage entry in the GlobalSupressions.cs with target namespace and the exclude

I tested it with a small solution with one project. It looks like that the target namespace doesnt work.

I searched around stackoverflow and the internet and the main answer was that suppressions with target namespace are not working.

The main application contains more than 250 projects.

For me it seems that the only working way is to create n custom rulesets for the different projects where the excluded rules are disabled.

I dont want to go through the complete application and resuppress all the rules in code.

How are you working with the new rulessets in such a situation?

Any idea how i can work with the new rulesets in a simple and maintainable way? The sharepoint list is the leading part for the definition of the code analysis rules.

Edit 1

In previous projects we manage our definition of the code analysis ruleset in a sharepoint list. The list displays all ca rules as a list

  • ca number
  • activated
  • handled as error
  • exclusion (contains project name party like 'Test' or full project/assembly name)

From the list a ruleset is created where

  • activated + handleAsError = rule is enabled
  • !activated = disable rule
  • activated + !handleAsError = warning

If the exclusion column has a value like 'Test' for example, then in all test project the rule should be disabled.

Was it helpful?

Solution

Nothing is forcing you to move to the new .ruleset file approach in VS2010. You can, if you wish, continue to use .fxcop project files or fxcopcmd.exe command line switches in your builds, so your existing approach should presumably continue to work (possibly after a few minor tweaks).

That said, I'm guessing that there is probably a much simpler way to achieve what you wish. However, I'm not sure that I fully understand your end goal since your question focuses much more on adapting your existing approach. If you would like assistance with attempting to find an approach that fits well with the new tool capabilities, could you please provide more details concerning what exactly you are attempting to accomplish?

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top