Great; Microsoft reintroduced DLL hell with .NET 2.0 SP1 [modified]

[Jon Rista]

Actually, according to the comment at the bottom of this[^], the features were added as part of 2.0 SP2, 3.0 SP2, and 3.5 SP1. Considering that .NET 3.5 is simply additional API's built on top of the .NET 2.0 base, this makes complete sense as to why they did it this way. WaitHandle is not a part of .NET 3.0 or 3.5 specifically...its a part of .NET 2.0. Since thats the case, any core framework changes like this must come as part of a service pack for .NET 2.0. And I don't think its surprising that Microsoft uses service packs this way. Thats what service packs are for Microsoft...it has been for years and years. Windows XP SP2 added a bunch of new features and updated dozens of Win32 API's. Get used to it...this is how Microsoft service packs work, and to my knowledge, thats how its always worked. It's nothing new. I for one have never made the assumption that something written on .NET 2.0 SP1 would be guaranteed to work on .NET 2.0.

[Jon Rista]

Your not asking...your whining. :P If you hate the industry...why are you still in it?

[Joe Woodbury]

From the documentation: Version Information .NET Framework Supported in: 3.5 SP1, 3.0 SP1, 2.0 SP1 Yet there was no reason for it. This had nothing to do with supporting .NET 3.5, it's simply adding more overloaded methods.

Jon Rista wrote:

Windows XP SP2 added a bunch of new features and updated dozens of Win32 API's.

A big point of .NET is that you are assured interfaces won't change within a specific version. This avoids the DLL (and COM) hell problem. In other words, if Microsoft wanted to change the interface within the constraints THEY designed for .NET, they would have produced a .NET 2.1 and you would have to compile against it and your application simply wouldn't run if .NET 2.1 wasn't present. Why they didn't do this is a mystery.

Jon Rista wrote:

I for one have never made the assumption that something written on .NET 2.0 SP1 would be guaranteed to work on .NET 2.0.

How do you know when you've used something from .NET 2.0 SP1? There is a tool in VS 2008, but not in VS 2005. Moreover, the claim with .NET was this was guaranteed. That's the entire point!

Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke

[Jon Rista]

From the comments at the bottom of the page I linked: "David M. Kean - MSFT Despite what the version information above states, this member was actually introduced in .NET Framework 2.0 SP2, 3.0 SP2 and 3.5 SP1. It was not introduced in .NET 2.0 SP1 and 3.0 SP1." This was added not as part of .NET 2.0 SP1, but as part of SP2...which was the mandatory service pack update required for .NET 3.5 SP1. This update is part of the .NET 3.5 SP1 update, it is NOT a random update done for no reason. Like I said before, .NET 3.0 and .NET 3.5 are not the same as .NET 2.0. The upgrade from .NET 1.1 to .NET 2.0 involved a completely new framework version. This is not the same with .NET 3.0 and 3.5, both of which are simply API extensions to the .NET 2.0 base framework. Brows to your %windir%\Microsoft.NET\Framwork\ folder and check out the v2.0.50727, v3.0, and v3.5 folders, and you'll see the differences. In terms of how do I know whether I have used something on .NET 2.0 SP1 or not isn't an issue. If you upgrade your development box to a new service pack, then the expected consequence of that upgrade should most definitely be to upgrade your production environments as well. I'm not saying its the ideal way to release API changes, I am simply saying that this is how Microsoft does it, and its how they have done it for at least a decade. Its unreasonable to EXPECT that you can update a development box to a new service pack and NOT upgrade your testing/staging/production environments and clients to the same service pack. Even in the abscense of any kind of API changes, the service pack was released for specific reasons, and is usually applied for specific reasons. Whatever bugs were fixed that prompted the installation of SP1 would be just as essential in your production environment as in your development environment...so it baffles me why you would be so irked that .NET 2.0 SP2 had a couple new overloads that previous versions did not. The fact that your not automatically upgrading all environments and clients to the latest version/service pack is confusing and unwise. I will agree, releasing .NET 2.1 would have made life easier on developers in one sense...but it would also be very cofusing to end users given that 3.0 and 3.5, additional major releases, were also released. (Why release a new minor version of an old major release when you have had two significant releases since then...people would figure that 3.0 and 3.5 provided whatever 2.1 provided and more). Microsoft has a much better chance of gett

[Yortw]

That's not the only thing they added overloads to, I think there's some new ones on GC.Collect and probably a bunch of others we haven't noticed. The real problem isn't that they added the new overloads, the problem is that you can't target 'SP1' specifically. If you could target 2.0 and 2.0 SP1 seperately, then you could just stick with targeting 2.0 and the IDE/compiler could ignore the additional stuff/prevent you from using it, while still running fine when deployed against SP1, for the purposes of getting the non-breaking changes, such as memory leak fixes etc. Of course the simple solution (as painful as it is) is just to upgrade your customers to SP1... it's backwards compatible with 2.0, so if you've used the new overloads it won't hurt because your customers will have them, and any other software developed against the unservice packed 2.0 version should also run fine since it's only using the older stuff that still works. A much bigger problem is that I think serialisation of some types got broken between 2.0 and SP1, so if you're returning complex types from a web service using automatic serialisation by the framework, I believe you can run into a situation where server and client can't understand each other anymore if the two aren't both service packed... but I'm not 100% sure on this. On the other hand, this isn't anything new, we've lived for this for years and MS did make the framework better by adding the overloads, so we can't complain too much... it's just a shame they didn't do them in 3.0 or make sp1 seperately targetable.

[Tim Yen]

I have to chip in here. The .net 3.5 sp1 broke database transactions to oracle from different Oracle schemas. What used to work in .net 3.5 does not work with the service pack. We write oracle LOB's to a configuration schema using a login and passsword from our main data schema. You may well say that was the problem there, but the point is it used to work. And one thing we can't control is if the user does have 3.5 sp1 installed. The frameworks should not have been patched they should have clocked up to 3.6. or 3.5.1 but NOT replaced the original dll's. One of the big philosphical points of .net was to avoid DLL hell. And the way to do this was use more disk space. Framework Service packs are reintroducing DLL hell.

[Tim Yen]

"Of course the simple solution (as painful as it is) is just to upgrade your customers to SP1" But how do you down grade them? "A much bigger problem is that I think serialisation of some types got broken between 2.0 and SP1" And cross schema oracle database transactions got broken too. "the problem is that you can't target 'SP1' specifically" I wholeheartedly agree, there shouldn't have been a sp1 it should have been 3.5.1 or 3.6

[Tim Yen]

"2.0 and 3.0 service packs are slipstreamed in to the major release and are required to be present in order for .NET 3.5 to function properly" This was a questionable decision, disk space is very cheap now. I reckon 3.5 should have been self contained and all the service packs should be too.

[Scott Dorman]

I agree, it could have been handled better but, at this point all we can do is hope that .NET 4.0 will provide a better experience.

Scott Dorman

Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]

---

Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai

[RichardM1]

Here he talks about his device, and other people running their code on it.[^] And sorry I said it kinda harsh, some days I'm more anal than others (other days, and other peoples)

Silver member by constant and unflinching longevity.

[etkid84]

:confused: I wasn't suggesting any of those products (apache, python, or ruby) be used on embedded devices. In fact, in my line of work -- we don't use Microsoft products for embedded development, it's all RTOS, UNIX, or Linux w/ POSIX real-time extensions. I was suggesting they be used as replacement for Microsoft products on Windows XP and Vista. Isn't that the source of the "dll hell"? Kind regards, :cool:

David

[CoolDadTx]

This isn't the first time that it has happened in .NET. One of the previous releases added a new feature that was only available on the XP+ version of the framework. So if you assumed that the framework was the same across the board then you already made a false assumption. Do a google search to find the related set of complaints about that one. Was it a bad choice on MS'es part? Yes. Is there anything you can do about it? No. To assume that MS won't add any new features in a SP is flawed though. MS has been doing that for years. Whether it is reasonable or not is a different story but it is what it is. The problem for the particular method in question is that the v2.0 and v3.5 source is the same. The functionality was needed in v3.5 so it was added. As a consequence the v2.0 runtime inherited it. Remember that v3.5 and v2.0 share the same core v2 RTL. In fact installing v3.5 upgrades v2.0 to SP2. So while it is in v2.0 it is probably recommended that you don't use it except for v3.5. The documentation for the method specifies that it is for SP1+ so there shouldn't be any confusion as to what you'll need.

[Joe Woodbury]

The source of "dll hell" are vendors changing interfaces and methodologies without versioning their tools in any obvious, protected (i.e. protecting the calling application) way. Python 2.6 and 3.0 are doing the single biggest DLL hell I've ever seen--it's utterly insane. Not only does nothing prevent Ruby or Apache from doing the same thing, they have many times. Ultimately, this is about the lack of discipline amongst engineering and engineering management. And, in almost every case, I can almost guarantee some, or many, engineers wrote a memo warning of this and proposing solid alternate solutions, warnings which were promptly ignored.

Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke

[etkid84]

Joe, Do you think it has something to do with how Microsoft approaches library construction vs. the UNIX model. I am not an expert here, but when you build a UNIX program, you can either create a static or dynamic library -- and i am sure there are advantages and disadvantages to both. But, there doesn't appear to be an issue on UNIX and Linux type architectures. Am I wrong here or is a non-issue? I could never understand why every application had to dump all their dll crap into the system directories in order for their stuff to work? And then when you deleted or removed an application or replaced it with a newer version, other apps would get all screwed up because they were all sharing some common library that was installed by others (not microsoft). Is this wrong or right?

David

[Joe Woodbury]

Microsoft is largely to blame for this; the system and system32 directories were not only unsecured, but Microsoft encouraged developers to put DLLs there. The same thing happened with Win.ini and System.ini. Even to this day there is no standard way to place and/or version DLLs. The only real solution is to keep all the non-system DLLs your project needs in your own directory. Likewise, the registry in and of itself it fine; what isn't fine is that Microsoft didn't put strong security in place immediately with it and was quite cavalier about how it could be used. In some cases, they even pushed out (Yes, this breaks when Microsoft changes one of the core modules, but that's also true of UNIX and any operating system for that matter.)

Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke

[radioman lt]

yeah.. the same is happened with GC.Collect ;}

peace & serenity

[Yortw]

Here's a useful tip relating to this... If you have static code analysis enabled you can turn on rule 1903 (under Portability rules) which will then give you compiler warnings if you use a method that is only availabe in SP1 and not in 2.0 (assuming you've targeted 2.0). This is in VS 2008... and I presume FXCop, but I haven't checked.