Visual Studio 2012 Code Analysis Error CA0058

Question

I am currently working on a solution with multiple projects in it, and when I try to run the code analysis tool from VS12 I get the following error when trying to run it:

CA0058 Error Running Code Analysis CA0058 : The referenced assembly "Microsoft.Practices.Unity, Version=2.1.505.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" could not be found. This assembly is required for analysis and was referenced by: C:\MyProject\bin\Release\MyProject.exe, C:\MyProject\packages\Prism.UnityExtensions.4.1.0.0\lib\NET40\Microsoft.Practices.Prism.UnityExtensions.dll. [Errors and Warnings] (Global)

I also got two more erros:

CA0052: No targets were selected

and

CA0055 Error Running Code Analysis CA0055 : C:\MyProject\bin\Release\IntraEUA Management Software 2.0.exe The following error was encountered while reading module "Microsoft.Practices.Prism.UnityExtensions": Assembly reference cannot be resolved: Microsoft.Practices.Unity, Version=2.1.505.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35. [Errors and Warnings] (Global)

But the strange thing is, nowhere in my solution I use ersion 2.1.505.0 of UnityExtensions, I am using 4.1.0.0. And even stranger, in all other projects in this solution it works, using the exact same version of UnityExtensions, even the PublicKeyToken is identical in all the other projects.

I've tried to search the entire solution for the string "2.1.505.0" and found nothing., so where does VS get this Information?

Btw, I got UnityExtension using NuGet. And tried to delete and reinstall UnityExtensions, but with no effect. And I am using .NET 4.5.

Any idea to get rid of this, probably false error? Or at least a workaround to ignore it?

Answer 1

The underlying issue is due to the combination of two facts:

1. Prism.UnityExtensions version 4.1.0.0 references Unity in version 2.1.505.0, with a strong name, but you have a newer version, strongly signed with version 3.0.0.0;
2. In its default mode of operation, FxCop insists that the assembly name must match the reference, including having the exact version number, thereby ignoring assembly redirection (which is the only thing that allows that combination of assemblies to work at runtime);

Meaning that, this mess is not your fault, simply the result of attempting to use an "unexpected" combination of library versions, and of an oversight in FxCop's assembly resolution logic.

The main way to get past that issue is to set FxCop's AssemblyReferenceResolveMode to StrongNameIgnoringVersion. There are ways to achieve that, one on a per-machine setting, and the other on a per-project setting.

• One is to do as you did, to set AssemblyReferenceResolveMode to StrongNameIgnoringVersion in either FxCopCmd.exe.config (from VS12 invocation) or FxCop.exe.config (command-line call to FxCop.exe);
• The other is to add a line in each .csproj file, inside of a PropertyGroup XML element:

<PropertyGroup>
  <CodeAnalysisAdditionalOptions>/assemblyCompareMode:StrongNameIgnoringVersion</CodeAnalysisAdditionalOptions>
</PropertyGroup>

I would recommend using the per-project setting for any project that you intend to share with other people.

Answer 2

The only solution to get rid of this is indeed changing the AssemblyReferenceResolveMode of the FxCopCmd.exe.config from StrongName to StrongNameIgnoreVersion. I didn't came up with anything else, so I've got to live with that.