I\'m trying to use Microsoft.Bcl.Async and Code Analysis, but when I run Code Analysis I get one or more errors.
I\'m using Visual Studio 2012 with Update 2.
T
As mentioned by Nicole, this occurs because Code Analysis/FxCop is enforcing that strong names including versions match exactly. This behavior makes sense for .NET Framework, until you start to factor in binding redirects (or other platforms such as Store, Phone & Silverlight which always allow later versions of an assembly to match an earlier version), which FxCop does not respect.
I wrote this original behavior in FxCop, and it was over optimizing for correctness vs real world. At the time, we didn't have an opt out other than via the App.Config. However, luckily after I left the team, some smart person on the team added one both via the command-line and within Visual Studio.
Via the command-line:
FxCopCmd.exe /assemblycomparemode:StrongNameIgnoringVersion ...
Via Visual Studio:
<PropertyGroup>
element, add the following: <CodeAnalysisAdditionalOptions> /assemblycomparemode:StrongNameIgnoringVersion</CodeAnalysisAdditionalOptions>
This will only work in Visual Studio 2012 and higher.
This happens because the versions of the dependencies declared in Bcl.Async assemblies don't match those available at analysis time. The simplest workaround is to adjust FxCop's AssemblyReferenceResolveMode
as described at http://davesbox.com/archive/2008/06/14/reference-resolutions-changes-in-code-analysis-and-fxcop-part-2.aspx.
Having the same problem, and looking for a solution. The only mention I've found is in the comments of the bcl blog post - Microsoft.Bcl.Async is Now Stable (page 3 of comments) where Immo Landwerth's response to someone having the same issue is;
We're looking into it. At first glance it seems like a unification issue in the VS static code analysis feature (FxCop). We've contacted the owners of it. Unfortunately, I don't think there is a workaround other than disabling code analysis for those projects :-(
The response is dated 26th April 2013, whether there have been any developments since then.
So for now I guess the workarounds are:
TaskEx.Delay()