Rob Villahermosa's WebLog : Common Compatibility Questions

Configuring your V1.1 apps to run against V1.0

robvi — Thu, 22 Apr 2004 04:48:00 GMT

A friend of mine was trying to get his V1.1 app to run against V1.0 without much luck. His config file had a startup section that looked like this:

</startup>

This will NOT work on V1.0!

In V1.0, the V1.0 shim has no support for <supportedRuntime> tags so actually does not know what they mean.

Now, here is where it gets unintuitive:

In V1.1, they started worrying about backwards/forwards compatibility and decided that perhaps the <requiredRuntime> tag was not the best thing to use and introduced the <supportedRuntime> tag.

The V1.1 shim actually checks for the <supportedRuntime> tag first, and if it finds it ignores the <requiredRuntime>.

So, in V1.1 even if you have something like:

<?xml version=”1.0”>

</startup>

</configuration>

The V1.1 app will still run on V1.1 because the V1.1 shim reads the <supportedRuntime> tags first.

The V1.1 app WILL NOT run on V1.1 though, if you don’t include the <supportedRuntime> tags and only have the <requiredRuntime> tag.

<?xml version=”1.0”>

</startup>

</configuration>

In this case, the V1.1 shim sees the <requiredRuntime> tag since there are no <supportedRuntime> tags.

Breaking Changes: past, present, and I can't speak about the future

robvi — Sat, 21 Feb 2004 04:36:00 GMT

Ok, so a large part of my job is finding breaking changes and helping make sure that they get fixed. These changes are classified as backward or forward compatibility breakers. Backward compatibility means a newer version of the .NET FX can run older apps and forward compatibility means an older version of the .NET FX can run newer apps. There are currently two released versions of the .NET FX out there (excluding service packs) these are 1.0.3705 and 1.1.4322 or V1.0 and V1.1 for short.

There are a bunch of apps out there built on V1.0 that people are upgrading to V1.1. Keep in mind that you have to be aware of the breaking changes between these two versions! http://www.gotdotnet.com/team/upgrade/apiChanges.aspx gives you a list of API changes. To read the list after you've downloaded it, the left hand column represents removed API's and the right hand column represents added API's. Breaking changes are highlighted in Red. If you find an API has changed, you likely can get around the problem by updating your

http://www.gotdotnet.com/team/changeinfo/default.aspx gives a list of other breaking changes in both forward and backward directions. If you've upgraded to V1.1 and are encountering problems, check here. This is a great resource as it shows workarounds for a lot of common problems that I've seen being asked.

Obviously, our focus is predominantly on maintaining backwards compatibility. This makes sense, as you can't expect to take advantages of new features and expect your code to run fine on an older version of the FX where these features did not exist. At the same time, the line is tough to make - what about improvements?

Sometimes fit and finish and improvements to the overall quality of FX are somewhat hindered because of the requirement to maintain compatibility. A great example of this is making additions to enums. Trust me, there are a ton of extremely intelligent folks here who debate the issue of moving forward and making something great vs keeping things compatible to no end. In the end, rest assured we're doing our best to satisfy as many needs out there as possible.

This posting is posted “as is” and guarantees no warranties and confers no rights.

How do I detect what .NET Framework version is installed on a machine?

robvi — Wed, 18 Feb 2004 06:15:00 GMT

I see this question asked again and again on various newsgroups. After picking some of the BIG brains I work with here are two methods you may want to consider:

Method 1:

1.) Under HKLM\SOFTWARE\Microsoft\.NETFramework\policy\ check to see if the version you want is installed (for example, look for the v1.1 folder and 4322 for the version number to detect the released version of V1.1)

2.) Under HKLM\Software\Microsoft\.NETFramework\InstallRoot get the path where the Framework is installed. Create a directory string by concatenating the install root and the version under policy. E.g. "C:\WINDOWS\Microsoft.NET\Framework\" + "v1.1" + "." + "4322"

3.) Look at the directory, if mscorlib.dll (or another critical .dll to the .NET framework is there) the runtime is installed.

Method 2:

There's a caveat to this method in that the shim gets left behind when we uninstall if there is more than one version of the CLR on the machine, but it still can be useful depending on what version you're looking for:

LoadLibrary(“mscoree.dll“); - if this fails then there's no runtime installed

GetProcAddress(“CorBindToRuntime“); - if this fails there's no runtime installed

CorBindToRuntime(“GetRequestedRuntimeInfo“);

GetRequestedRuntimeInfo(xxxx); where xxxx is the build number.

This posting is provided "AS IS" with no warranties, and confers no rights.