Dave's Box : Bugs, FxCop

Make sure you use the tools at your disposal

David Kean — Thu, 19 Feb 2009 15:00:00 GMT

I ran across something interesting on an internal alias about a new marketing campaign on the Visual Studio Team System marketing site that allows you to customize an amusing video that you can send to friends and team members. What caught my eye wasn’t the video itself, but the error that some users were encountering when attempting to view one of the Silverlight-based videos:

Message: Unhandled Error in Silverlight 2 Application [Format_InvalidString]
Arguments:

Debugging resource strings are unavailable. Often the key and arguments provide sufficient information to diagnose the problem. See http://go.microsoft.com/fwlink/?linkid=106663&Version=2.0.31005.0&File=mscorlib.dll&Key=Format_InvalidString   at System.Number.StringToNumber(String str, NumberStyles options, NumberBuffer& number, NumberFormatInfo info, Boolean parseDecimal)
   at System.Number.ParseDouble(String value, NumberStyles options, NumberFormatInfo numfmt)
   at System.Double.Parse(String s, NumberStyles style, NumberFormatInfo info)
   at System.Double.Parse(String s, IFormatProvider provider)
   at System.Convert.ToDouble(String value)
   at PepTalk_Full.DataObjects.doTextOverlay..ctor(XElement element)
   at PepTalk_Full.DataObjects.doPepTalk.Init()
   at PepTalk_Full.DataObjects.doPepTalk..ctor()
   at PepTalk_Full.App.wc_DownloadStringCompleted(Object sender, DownloadStringCompletedEventArgs e)
   at System.Net.WebClient.OnDownloadStringCompleted(DownloadStringCompletedEventArgs e)
   at System.Net.WebClient.DownloadStringOperationCompleted(Object arg)

To keep download sizes smaller, the client Silverlight plug-in does not contain Exception error messages, but by clicking the URL above, or by looking at the stack can you guess what the problem is? I’ll give you a hint – Convert.ToDouble(String) passes CultureInfo.CurrentCulture as the IFormatProvider argument to Double.Parse.

Yep, you guessed it, basically, the application is attempting to parse a string that it has downloaded from the web and the call to Convert.ToDouble is failing because it is expecting the format of the string to match the current culture, while the string itself is formatted using another culture. For example, the string likely contains a value formatted using the invariant culture, say ‘1.00’, but when a visitor from Germany or Norway comes to visit, Convert.ToDouble(String) is looking for a string in the format ‘1,00’.

The irony in all this is that if the Microsoft team or contractor that wrote the Silverlight application were actually using the Code Analysis feature of Team System, they would have received the following warning from Specify IFormatProvider:

Because the behavior of 'Convert.ToDouble(string)' could vary based on the current user's locale settings, replace this call in 'doTextOverlay.doTextOverlay(XElement)' with a call to 'Convert.ToDouble(string, IFormatProvider)'. If the result of 'Convert.ToDouble(string, IFormatProvider)' will be displayed to the user, specify 'CultureInfo.CurrentCulture' as the 'IFormatProvider' parameter. Otherwise, if the result will be stored and accessed by software, such as when it is persisted to disk or to a database, specify 'CultureInfo.InvariantCulture'.

All the developer has to do is to call the overload of Convert.ToDouble that takes an IFormatProvider passing it CultureInfo.InvariantCulture and the application would work on all systems regardless of the user’s culture.

The moral of the story is, use the tools available at your disposal – if you have Team System, use Code Analysis, otherwise, we still offer FxCop as a free download – they both catch bugs like this one.

Code Analysis failing with ‘Invalid settings passed to CodeAnalysis task’

David Kean — Fri, 26 Dec 2008 15:00:00 GMT

I’ve seen recent reports of Visual Studio Code Analysis failing (such as this one) with the following error:

Invalid settings passed to CodeAnalysis task. See output window for details.

Looking in the output window will show something similar to:

Switch '/targetframeworkversion' is an unknown switch.

As I’ve mentioned earlier, the /targetframeworkversion switch was added in Visual Studio 2008 SP1 to support the new multi-targeting rule. The fact that the FxCop does not understand the switch, is a big indicator that something went astray with the installation of the service pack.

Luckily the fix is rather easy, simple re-install it.

BUG: Multi-targeting rule not firing on usages of 2.0 SP2 and 3.0 SP2

David Kean — Sat, 29 Nov 2008 15:00:09 GMT

Previously, I've spoken about the new multi-targeting rule that shipped in Visual Studio 2008 SP1 and FxCop 1.36. This rule helps to prevent users from inadvertently taking a dependency on a .NET service pack. Unfortunately, it shipped with a bug that when targeting .NET 3.5, prevented it from firing on usages of types and members only available in .NET 2.0 SP2 and .NET 3.0 SP2 (both installed by 3.5 SP1).

Luckily, the fix is rather simple.

In Visual Studio 2008 SP1:

From an elevated (right-click and Run as administrator) Visual Studio command-prompt, type the following and press <ENTER>:

devenv "%PROGRAMFILES%\Microsoft Visual Studio 9.0\Team Tools\Static Analysis Tools\FxCop\Repository\Compatibility\Desktop2.0SP2.xml"

In the <CompatibilityEntry> element in the file that opens, change the Priority attribute from 3015 to 3515:

<CompatibilityEntry Name=".NET Framework 2.0 Service Pack 2"
                    Platform="Desktop" 
                    Version="2.0.2" 
                    Priority="3515">

Save the file.
From the previously opened command-prompt, type the following and press <ENTER>:
devenv "%PROGRAMFILES%\Microsoft Visual Studio 9.0\Team Tools\Static Analysis Tools\FxCop\Repository\Compatibility\Desktop3.0SP2.xml"

Similar to above, in the <CompatibilityEntry> element, change the Priority attribute from 3020 to 3520:

<CompatibilityEntry Name=".NET Framework 3.0 Service Pack 2"
                    Platform="Desktop" 
                    Version="3.0.2" 
                    Priority="3520">

Save the file.

In FxCop 1.36:

Follow the above steps, changing the paths above from %PROGRAMFILES%\Microsoft Visual Studio 9.0\Team Tools\Static Analysis Tools\FxCop\Repository\Compatibility to %PROGRAMFILES%\Microsoft FxCop 1.36\Repository\Compatibility.

To verify the fix:

In Visual Studio, start a new C# WPF Application, and paste the following code in the code-behind of App.xaml:

public partial class App : Application
{
    System.ComponentModel.DateTimeOffsetConverter field1;
    System.Windows.Data.BindingGroup field2;
}

In Solution Explorer, right-click on the project and choose Run Code Analysis.
If the above steps were followed correctly, you should see warnings similar to the following:

This will be fixed in a future release of Visual Studio.

Thanks to Andrew Smith for bringing this my attention.

Reference resolution changes in Code Analysis and FxCop – Part 2

David Kean — Sat, 14 Jun 2008 14:00:00 GMT

Previously, I mentioned the reference resolution changes that were made in Code Analysis for 2008 and FxCop 1.36. Unfortunately, not long after we shipped Visual Studio 2008, we found an uncommon scenario in which the strong name matching prevented Code Analysis/FxCop from analyzing a binary even though all assemblies used for compilation were present.

The scenario occurs when you have something similar to the following:

As you can see above, Assembly 1.0.0.0 has a reference to VSLangProj 8.0.0.0 and EnvDTE 8.0.0.0. Whereas, VSLangProj 8.0.0.0 has a reference to EnvDTE 7.0.3300.0.

Surprisingly, the C# compiler actually allows you to compile the above assembly against VSLangProj with a later version of EnvDTE. It allows this, by substituting the 7.0.3300.0 version of the EnvDTE types exposed by VSLangProj, with their 8.0.0.0 equivalent. However, when doing this, it stills adds a reference in the assembly manifest to both versions of EnvDTE; 7.0.3300.0 and 8.0.0.0, even though you never explicitly added a reference to the former.

In contrast to the compiler, both Code Analysis and the CLR itself by default do not consider types from a later version of an assembly to be the same as their equivalent from an earlier version. In other words, the compiler behavior and the runtime behavior are in direct conflict of each other. In fact, the only way to get such an assembly to load in the CLR, is to add a binding redirect from EnvDTE 7.0.3300.0 –> 8.0.0.0.

When you attempt to run Code Analysis/FxCop over an assembly with references similar to above, you might encounter two different errors with the same underlying cause:

The first error complains about a missing reference:

error : CA0058 : The referenced assembly 'EnvDTE, Version=7.0.3300.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' could not be found. This assembly is required for analysis and was referenced by: 'Assembly.dll'.

Whereas, the second error complains about failing to load the assembly:

error : CA0055 : Could not load Assembly.dll.
error : CA0052 : No targets were selected.

Opening the [AssemblyName]CodeAnalysisLog.xml in output directory will contain something similar to:

<Exceptions>
<Exception Keyword="CA0055" Kind="AssemblyLoad">
   <Type>Microsoft.FxCop.Common.AssemblyLoadException</Type>
   <ExceptionMessage>Could not load Target.exe.</ExceptionMessage>
   <InnerType>Microsoft.FxCop.Sdk.InvalidMetadataException</InnerType>
   <InnerExceptionMessage>The following error was encountered while reading module 'Assembly': Could not resolve member reference: VSLangProj.BuildManager::get_ContainingProject.</InnerExceptionMessage>
   <InnerStackTrace>   at Microsoft.FxCop.Sdk.Reader.HandleError(ModuleNode mod, String errorMessage)
   at Microsoft.FxCop.Sdk.Reader.GetMemberFromRef(Int32 i, TypeNodeCollection& varArgTypes, Int32 numGenericArgs)
   at Microsoft.FxCop.Sdk.Reader.GetMethodDefOrRef(Int32 codedIndex)
   at Microsoft.FxCop.Sdk.Reader.GetTypeMembers(TypeNode type, Object handle)
   at Microsoft.FxCop.Sdk.TypeNode.get_Members()
   at Microsoft.FxCop.Engines.Introspection.LoadVisitor.VisitType(TypeNode type, TargetType target)
   at Microsoft.FxCop.Engines.Introspection.BaseVisitor.VisitTypes(TypeNodeCollection types, TargetNamespaceDictionary targets)
   at Microsoft.FxCop.Engines.Introspection.LoadVisitor.VisitModule(ModuleNode module, TargetModule target)
   at Microsoft.FxCop.Engines.Introspection.BaseVisitor.VisitAssembly(AssemblyNode assembly, TargetFile target)
   at Microsoft.FxCop.Engines.Introspection.LoadVisitor.VisitAssembly(AssemblyNode assembly, TargetFile target)
   at Microsoft.FxCop.Engines.Introspection.LoadVisitor.Load(TargetFile target, Boolean buildTree, Boolean queueItems, AssemblyNode loadedAssembly)
   at Microsoft.FxCop.Engines.Introspection.IntrospectionAnalysisEngine.LoadTargets(TargetFile target)
   at Microsoft.FxCop.Common.EngineManager.LoadTargets(TargetFile target, Boolean resetCounts, String loadEngine)</InnerStackTrace>
</Exception>
<Exception Keyword="CA0052" Kind="Engine">
   <Type>Microsoft.FxCop.Sdk.FxCopException</Type>
   <ExceptionMessage>No targets were selected.</ExceptionMessage>
</Exception>
</Exceptions>

Luckily, there are a couple of workarounds for those that run into this:

Add a reference to the earlier version of the assembly (ie above this would be EnvDTE 7.0.3300.0), removing the reference to the later version.

Unfortunately, if you need features only available in the later version or the earlier version of the assembly is not always available (if you are hitting this with EnvDTE, then this is most likely the case), this option will not work. In those cases, use the next option.
Use an unsupported configuration setting and change Code Analysis/FxCop’s resolving logic:
1. Using a text editor, open the FxCopCmd.exe.config file located in %PROGRAMFILES%\Microsoft Visual Studio 9.0\Team Tools\Static Analysis Tools\FxCop (Code Analysis) or %PROGRAMFILES%\Microsoft FxCop 1.36 (FxCop)
2. Change the AssemblyReferenceResolveMode from StrongName to StrongNameIgnoringVersion
3. Save the text file
4. If using FxCop standalone, repeat the same procedure for FxCop.exe.config
Once you have changed this setting, Code Analysis/FxCop will start treating the references similar to how the compiler does. Taking above as an example, types in EnvDTE 8.0.0.0 will be considered a match for their 7.0.3300.0 counterparts.

In future versions, it is likely that Code Analysis/FxCop will move to a model that closely mimics the C# compiler’s /reference switch, which will allow it to dynamically choose the correct resolving mode based on the available references.