FxCop Rule for Multi-Targeting
Two months ago, Scott blogged about the multi-targeting support in Visual Studio 2008. I worked on this feature in the planning phase (read “long time ago”), and so I am quite thrilled to see it finally in the hands of developers. Especially, that several years ago I remember our small working group sitting in a room and wondering whether such feature was even possible. The complexities of implementing it in a large project like the Visual Studio seemed quite daunting.
The thing that made implementing multi-targeting in one release possible was the concept of Red and Green bits. You can read about the concept here, here, and here, but quickly: red bits are Framework assemblies that existed in the .NET Framework 2.0 and were serviced in versions 3.0 and 3.5. Green bits are assemblies that were added either in the version 3.0 or 3.5. The servicing changes in Red bit APIs are limited (after all it is servicing) to a very small number of API additions and bug fixes.
We leveraged (and influenced) the decision to limit the number of changes to existing assemblies to drastically simplify the requirements for the multi-targeting system. That is, we made an assumption that the majority of differences between the Framework versions (targets) are on assembly boundaries.
But now I have to confess, there are some limitations in this design that we accepted when we made the original simplifying assumption. There is a very limited number of APIs being added to the Red assemblies and the multi-targeting system is currently not able to detect these. For example, if you set the target to the .NET Framework 2.0 and read the newly-added (albeit obscure) property GCSettings.LatencyMode the program will compile just fine but then fail to run on the .NET Framework 2.0 RTM. The reason is that the property was added to an existing (Red) class GCSettings, not to a new class in a new assembly. Despite that the number of such additional APIs in Red bits is very small (and that we recommend that you still test your programs on all targeted platforms), this can be quite annoying. And so feeling a bit responsible for this (and trying to promote FxCop J), I wrote an FxCop rule that can analyze IL of an assembly targeted at Framework 2.0 and warn you about all calls to members that are not present in 2.0 RTM.
Here is how it works: The test program below uses new LatencyMode enum and calls a new GcSettings.LatencyMode property. As I mentioned above, these APIs don’t exist in .NET Framework 2.0 RTM. Even if I built this project with the multi-targeting target set to Framework 2.0, the system would not complain about calling these APIs. But, as you can see in the error list, the FxCop analysis engine can deal even with this difficult to detect problem. You can think of the rule as a very smart (post) compiler-step.
A sample project with the rule is attached to this post. I provide it without any guarantees, as is, and in fact I am sure it has many bugs and problems. When I find time, I will work on it more to polish it a bit but I don't promise (i.e. treat it as a sample).
BTW, to install the rule, just build it and drop it to the FxCop rules directory. On my machine it is at C:\Program Files\Microsoft Visual Studio 9.0\Team Tools\Static Analysis Tools\FxCop\Rules. In addition you have to go to Project settings of the project you want to analyze and turn on FxCop analysis (the “Code Analysis” tab in the project properties). Lastly, you can either rebuild or right click on a project and choose “Run Code Analysis”. I hope it’s helpful.
Comments
Anonymous
October 02, 2007
PingBack from http://msdnrss.thecoderblogs.com/2007/10/02/fxcop-rule-for-multi-targeting-3/Anonymous
October 02, 2007
Hello Krzysztop, either I don't understand the red bits / green bits concept or there are some additional considerations. Should'nt the green bits from .NET 3.0 be red bits in 3.5 ?. Or is the green bits red bits concept only limited to the CLR ?Anonymous
October 03, 2007
Why not to release the full suite of assemblies every time you release a new version of .NET framework? It would make everyone's life much easier. Now people need to remember that System.ServiceModle.dll is part of .NET 3.0 but System.Data.dll is part of .NET 2.0. What is more now I have to keep on my hard drive both versions whereas I could just upgrade to .NET 3.0 and forget about .NET 2.0. Just my two cents.Anonymous
October 03, 2007
Nuova FxCop Rule per il controllo del Multi-TargetingAnonymous
October 03, 2007
Martin, yes, all assemblies in 3.0 are red in 3.5. Pawel, I might net be understanding your question, but we do release all assemblies in new versions of the framework. That is if you install Framework 3.5, you get all assemblies that were in 2.0 and 3.0, plus new assemblies.Anonymous
October 03, 2007
Yes, that is true regarding 2.0 and 3.5. But 3.0 is different and that's why people are confused so often.Anonymous
October 03, 2007
In your screenshot you have the error message "Test.Program.Main calls System.Runtime.GCLatencyMode which is not avaliable .NET Framework 2.0". You spelt "avaliable" wrong :-)Anonymous
October 03, 2007
Krzysztof, is there any chance to get this to be part of VS9 RTM ? It could be really useful with current implementation of multitargeting ... thanksAnonymous
October 04, 2007
Pawel, could you please point me to the place where you see a 3.0 redist without the 2.0 assemblies? I might be wrong but I was under the impression that 3.0 works just like the 3.5 redist. Paul, thanks for catching the type. I will fix it next time I update the rule project. Martin, I will forward you suggestion to the fxcop team. I would love to see this rule in the offiical product as well.Anonymous
October 04, 2007
My point is that if you want to add a reference and you have .NET 3.0 installed on your machine then the only version of System.Data.dll you see is 2.0. There is no v3.0 of System.Data. All I'm saying is that it would be better to either always release all the assemblies or release new ones with the same version which means V2.0 regarding for example System.ServiceModel.dll. Then you would not have to do all the juggling :).Anonymous
October 05, 2007
Krzysztof, thanks for the new rules. It would be great if this could be part of VS2008. Can this rule work with the standalone version of FxCop as well, since not everyone has access to the Team System editions?Anonymous
October 10, 2007
If you're using the new VS 2008 multitargeting features to target .NET 2.0 you should be aware that inAnonymous
October 15, 2007
When you install .NET 3.5 on your system, while the .NET CLR is the same and runs the same, there's someAnonymous
November 20, 2007
Thanks for this. One problem that we're running into: For a short while at least, we will be running side-by-side with VS2005, and the 2.0 red bits show up in there as well, but the compiled fxcop rule you present here does not seem to work for the VS2005 FX Cop engine, and recompiling under 2005 would require a bit of re-work as you use anonymous types in your source. Any easy solutions? Or should we just do the re-work to build it under 2005?Anonymous
November 21, 2007
Kirk, Scott Dorman has ported the rule to 2.0. You can read more about it at http://geekswithblogs.net/sdorman/archive/2007/10/09/Standalone-FxCop-Multi-Targeting-Rules.aspxAnonymous
December 20, 2007
In previous posts about Code Metrics and Code Reviews , I explored some metrics and techniques that IAnonymous
February 14, 2008
Nice Krzysztof Cwalina This should be part of VS2008 RTM with some configuration setting to show warning or errorAnonymous
April 07, 2008
If you are building and evolving APIs, Framework Design Studio is a tool you should check out. Anonymous
May 14, 2008
Krzysztof, thanks this is a great resource. One question though, in the downloadable sample, there are skeletons for comparing the changes in the 2.0 and 3.0 frameworks introduced with 3.5 + SPs. However, only the 2.0 rules are implemented. Would there be any possibility of getting a CallOnly30APIs.txt manifest and CallOnly30APIs.cs? That would be a huge help. Thanks!Anonymous
August 25, 2008
Just to let you know we've officially added a version of this rule to Visual Studio 2008 SP1 and FxCop 1.36. See the following post for more information: http://davesbox.com/archive/2008/08/25/new-for-visual-studio-2008-sp1-and-fxcop-1-36-multi-targeting-rule.aspxAnonymous
August 25, 2008
Back in October of last year, Krzysztof Cwalina talked about the multi-targeting changes in Visual StudioAnonymous
May 10, 2009
Great Post !!! I was preseting a session on FxCop rules and found this example very helpful. Just added this to my <a href="http://jomit.blogspot.com/2009/05/diving-exploration.html">link of the month</a> list Cheers, Jomit