nobugz

While researching two questions recently, it came to my attention that the .NET 3.0 version of the framework as installed on Vista is not the same as the one I installed on my laptop running XP SP2. On Vista, the setup utility overwrites all the V2.0 assemblies and upgrades them from version 2.0.50727.42 to 2.0.50727.312.

I looked at the differences between the 42 and the 312 revisions of mscorlib.dll and System.dll. There are indeed a few places where 312 checks for Vista. Several places where a SecurityPermission attribute is changed from InheritanceDemand to LinkDemand. And a bunch of, what looks like, bug fixes in PerformanceCounter, FileWebRequest, RuntimeMethodInfo and UdpClient. WaitHandle is the most visible class with new exceptions being thrown.

While I didn't look at the many other V2.0 assemblies, there's a potentially breaking change in HttpServerUtility as discovered by user Juan Llibre. It acquired a TransferRequest() method that is not present in the 42 revision. If you use this method, your code will not run on XP. The online version of the MSDN library appears to be accurate and up-to-date for the Vista version.
I approached MSFT about this and they declared the revisions non-breaking. The fact that you can't get the 312 revision installed on XP makes that a bit hollow.

I also looked at the V3.5 Beta1 version of the framework. Its setup utility silently overwrites the 42 revision with a 1318 revision. The changes in mscorlib and system are far more intense with many bug fixes. It looks like MSFT is addressing the "red bits", a code word for must-fix bugs. That revision is also declared non-breaking by my MSFT contact.

I'm a bit stunned that MSFT is giving up on side-by-side versioning of the most important assemblies in the framework. While I acknowledge that many of the fixes might be non-breaking, the fact that some are by accident is to be expected. It is too late to address the Vista vs XP versioning issue but I'd invite MSFT to make the V3.5 release coincide with an official SP1 release for V2.0 and V3.0

This will probably only happen when they hear the voice of their customers. Please post your thoughts to this thread.



Re: .NET Base Class Library [MsftFollowup] Vista framework version incompatible with XP version

Greg Beech

It's another example of how Microsoft have lost their backwards compatibility religeon.

This article makes interesting reading: http://www.joelonsoftware.com/articles/APIWar.html






Re: .NET Base Class Library [MsftFollowup] Vista framework version incompatible with XP version

Peter Ritchie

The only versioning difference you're discussing is the addition of three HttpServerUtility.TransferRequest overloads How is that a problem MSFT has stated adding a method to an interface doesn't affect forward compatibility of software using previous versions of a library.

Are you saying you don't want any bug fixes in the library Clearly changes need to be made to .NET 2.0 for Vista; but rather than force those changes to everyone they've only put them on Vista. Sounds like a wise choice to me. I wouldn't expect .NET 2.0.50727.42 to work on Vista...

I would hope V3.5 includes a new revisions as well, it should be pushing anything pushed on .NET 3.0 in Vista; plus other fixes. i.e. service pack.

As long as interface members aren't removed there are no versioning issues. If you find a .NET 2.0 application works when .NET 3.5 isn't installed but doesn't when 3.5 is installed then there's a problem.






Re: .NET Base Class Library [MsftFollowup] Vista framework version incompatible with XP version

nobugz

The fundamental problem here is that you can't easily test your app and be sure it will work as tested on the client's machine. You can't install the XP version on Vista nor the Vista version on XP. The bug fixes in the 312 revision are welcome, no doubt. What do you do when your client runs XP and your code happens to rely on the Vista bug fixes Asking her to install the V3.0 framework won't help. Insisting she switches to Vista is a mighty tough sale. The burden is on us to test our apps on both, violating a fundamental promise of the CLR.

In the big scheme of things, if the 312 revision is non-breaking, why couldn't it be installed on XP The code changes I saw that were Vista specific carefully checked the OS version number. The road to DLL Hell is paved with good intentions. I'll posit here that this was done because they thought they could get away with it but weren't that sure about it. I looked at the code changes, I'm not sure about it either. Seeing permission attributes changed gives me heartburn.

Given the complete lack of documentation of these changes, the fact that you can't find out because there are no tools available to show you the revision number, Vista was a perfect opportunity. Everybody will automatically assume that the incompatibility was caused by the OS, not the framework. Same outcome, but a million miles removed from finding the workaround.

This thread is an excellent example of the kind of misery this causes. I'll admit that my analysis was wrong, SendKeys is in fact completely different in the 312 revision. I was looking for another version of System.Windows.Forms.dll instead of looking at the version number (hard to do) or the code (hard to do too when the update doesn't get installed on my XP machine). What is endlessly worse is that the Microsoft employee didn't know either. Mark Rideout (former WF group member) promised that the change would be made in the V3.5 RTM version and didn't know it was already made in the 312 revision.

When people that should be in the know don't know and you can't find out what version you really have and can never be sure that the way it worked on your dev PC is the same way it will work on your customer's PC and you can't ask the customer to install the update, you've entered a zone all too familiar to old f*rts like me: DLL Hell sux and I honestly thought I'd never have to deal with it again.

This thread attracted an amazing number of page views in the last week. But no responses. If you think this all smells like past good intentions that didn't quite pan out, please respond. I'm fairly sure the SP isn't going to happen otherwise. I'm 100% for fixing the red bits. I want my customer to have them too, whatever OS they are running.





Re: .NET Base Class Library [MsftFollowup] Vista framework version incompatible with XP version

PhilipRieck

Peter,

This is not just academic, actually. I had an application "in the wild" FAIL on vista because of the difference in versions. Really. And there is no way to determine the version short of file property sniffing on some of the actual DLLS (you can't use requiredruntime or anything similar).

See http://philiprieck.com/blog/archive/2006/11/22/933.aspx





Re: .NET Base Class Library [MsftFollowup] Vista framework version incompatible with XP version

Peter Ritchie

PhilipRieck wrote:

Peter,

This is not just academic, actually. I had an application "in the wild" FAIL on vista because of the difference in versions. Really. And there is no way to determine the version short of file property sniffing on some of the actual DLLS (you can't use requiredruntime or anything similar).

See http://philiprieck.com/blog/archive/2006/11/22/933.aspx

What did Customer Support say






Re: .NET Base Class Library [MsftFollowup] Vista framework version incompatible with XP version

Peter Ritchie

If it's more than just an additional method and there's code that breaks, this isn't the forum for it; you should contact customer support. Something will occur *much* faster that way. You've got PSS tickets as an MVP, if you feel that strongly about it.

Forums like this take weeks for someone who cares about the problem to find it. Once they find it, they may not have a clue where to go with it. It could take months. The PSS folks have a deadline to maintain, they know who to call to get their 2-business-day answer for you. If you have a case (other than Philip's cases) you should contact PSS. Philip you should do the same, if you don't have any support incidents you an use, send me a private email (see my profile).






Re: .NET Base Class Library [MsftFollowup] Vista framework version incompatible with XP version

PhilipRieck

I wasn't looking for a fix for it on the forums.

I called customer support and they told me how to alter the code to get it to work, but that still requires a recompile and redistribution (thanks for the offer of help, though).

I was just chiming in that this problem is not a "look what could happen" - it's a look what did happen.





Re: .NET Base Class Library [MsftFollowup] Vista framework version incompatible with XP version

Inbar Gazit - MSFT

nobugz wrote:
It is too late to address the Vista vs XP versioning issue but I'd invite MSFT to make the V3.5 release coincide with an official SP1 release for V2.0 and V3.0

This will probably only happen when they hear the voice of their customers. Please post your thoughts to this thread.

We hear you.

The "red bits" part of 3.5 is in fact an SP1 to 2.0 and 3.0.

I know this is a little bit confusing but you should not think of 3.5 as a major new version but rather as a bunch of fixes - redbits and a bunch of new feature - greenbits.

Thanks for writing this thread, it's helpful and useful.






Re: .NET Base Class Library [MsftFollowup] Vista framework version incompatible with XP version

Juan T. Llibre

Yesterday, a security update for the .Net Framework 2.0 was pushed out through Windows Update.

The new version number for the .Net Framework 2.0,
running on Windows Server (SP2) is 2.0.50727.832.

It includes the TransferRequest method.

So, it looks like the "security update" was used to update
non-security related features of the .Net Framework 2.0.

The same update applies to XP and to Windows 2000:

See : http://support.microsoft.com/ id=928365







Re: .NET Base Class Library [MsftFollowup] Vista framework version incompatible with XP version

Peter Ritchie

I was just getting that update when I posted my post. That's weird.

My System.Web.dll was updated to 2.0.50727.832 and can confirm it also has a new TransferRequest method; on Windows XP SP2






Re: .NET Base Class Library [MsftFollowup] Vista framework version incompatible with XP version

Peter Ritchie

Juan T. Llibre wrote:

Yesterday, a security update for the .Net Framework 2.0 was pushed out through Windows Update.

The new version number for the .Net Framework 2.0,
running on Windows Server (SP2) is 2.0.50727.832.

It includes the TransferRequest method.

So, it looks like the "security update" was used to update
non-security related features of the .Net Framework 2.0.

Actually, I don't think that jives with Microsoft's Microsoft Update requirements. As far as I know they're not supposed to push new functionality on security updates, that would give them an edge over competitors. I don't know if that's voluntary or a DOJ mandate.






Re: .NET Base Class Library [MsftFollowup] Vista framework version incompatible with XP version

Peter Ritchie

PhilipRieck wrote:

I wasn't looking for a fix for it on the forums.

I called customer support and they told me how to alter the code to get it to work, but that still requires a recompile and redistribution (thanks for the offer of help, though).

I was just chiming in that this problem is not a "look what could happen" - it's a look what did happen.

Yes, but in all fairness would you honestly expect two different versions of software to have not even the minutest problem

I guess we'll also have to check to make sure our users have the latest security update for the .NET Framework when not running under Vista if we wish to support Vista and use XmlSerilizer/XmlSerializerFactory...






Re: .NET Base Class Library [MsftFollowup] Vista framework version incompatible with XP version

Peter Ritchie

Inbar Gazit - MSFT wrote:

nobugz wrote:
It is too late to address the Vista vs XP versioning issue but I'd invite MSFT to make the V3.5 release coincide with an official SP1 release for V2.0 and V3.0

This will probably only happen when they hear the voice of their customers. Please post your thoughts to this thread.

We hear you.

The "red bits" part of 3.5 is in fact an SP1 to 2.0 and 3.0.

I know this is a little bit confusing but you should not think of 3.5 as a major new version but rather as a bunch of fixes - redbits and a bunch of new feature - greenbits.

Thanks for writing this thread, it's helpful and useful.

If 3.5 is SP1 for .NET 2.0 (and 3.0) and 3.0 "adds nothing" to .NET 2.0, how is the addition of TransferRequest a "fix"




Re: .NET Base Class Library [MsftFollowup] Vista framework version incompatible with XP version

Juan T. Llibre

Peter Ritchie wrote:
Juan T. Llibre wrote:

Yesterday, a security update for the .Net Framework 2.0 was pushed out through Windows Update.

The new version number for the .Net Framework 2.0,
running on Windows Server (SP2) is 2.0.50727.832.

It includes the TransferRequest method.

So, it looks like the "security update" was used to update
non-security related features of the .Net Framework 2.0.

re:
!>Actually, I don't think that jives with Microsoft's Microsoft Update requirements.

I don't know whether it "jives" or not. It's just what actually happened.

re:
!> they're not supposed to push new functionality on security updates

I know. Nevertheless, it *did* happen.