views:

38

answers:

1

I'm looking for a tool that can tell me what frameworks a .NET assembly will work under. Or more specifically, what BCL (base class libraries) versions the methods within it requires.

What triggered me was this: Today I got a bug-report against an application we're making that basically said: "you're using WaitOne(Int32) but that only works for .NET 3.5 SP1, not plain 3.5; use WaitOne(Int32,Boolean) instead". And indeed the user was right. WaitOne has existed forever in .NET but the particular overload that takes only an int was introduced in service packs for 1.0, 2.0 etc. Therefore, our app would fail on e.g. a plain 3.5 framework installation. And frankly we hadn't tested for that.

Instead of testing/loading the app on machines with all kinds of frameworks installed, which is not very easy, I'm therefore looking for a tool that can simply tell me what officially released framework versions the methods in a given assembly will work under - or, more interestingly, what versions it will not work under and what the offending methods are.

A: 

Hi there.

I don't personally know of any tool which can analyse a .NET assembly and tell you which methods are available/unavailable to a specific framework version.

I think the best you can do is run the code under various configurations of the framework. For example, you could try using VMWare or Hyper-V to create virtual machines which have different versions of the .NET framework installed. Might be worth a shot.

Other then that, you will have to manually look at your .NET code and review it by hand, cross referencing the code with MSDN to work out whether a method if valid for a specific framework version.

I'd be interested in other people's answers - if there is a tool that can analyse .NET code to determine validity on different versions, then that's a killer app! :)

Cheers. Jas.

Jason Evans
I appreciate the suggestion, and have actually a number of images for testing stuff. But doing this for all framework versions and all their servicepacks is simply too much manual work. I'd rather spend that time writing the tool myself instead :-)
Richard Flamsholt