Great; Microsoft reintroduced DLL hell with .NET 2.0 SP1 [modified]
-
Just to be clear; your attitude is developers and users should blindly accept everything Microsoft does. We shouldn't give feedback or criticism. If we do, it's because we hate them and should use something else. I find this perfectly silly--how can Microsoft improve its products if everyone remains silent? What incentive would Microsoft have to improve its products and business if they received no criticism. Like many others, my frustration is that Microsoft has violated promises it made to developers and has been overly concerned with the latest buzzword technologies at the expense of helping us provide solid solutions for our customers.
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
How is it whining to ask Microsoft to follow their own spec? This is a big reason I hate this industry.
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
modified on Thursday, October 9, 2008 3:09 PM
-
My point is that Microsoft stated that with .NET, they wouldn't introduce new methods without versioning .NET to ensure this doesn't happen. That means that if I target, say, .NET 2.0 my app would run on ANY installation of .NET 2.0. The contract I speak of are promises Microsoft gave to the developer community--basically they said that if we develop for .NET, we won't run into the problem they just introduced.
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
Could you actually proove to us that new overloads were added? I checked the WaitHandle.WaitOne() documentation on MSDN library, for all versions from 1.1 throuh 3.5. The following overloads have existed since the beginning of .NET time: bool WaitOne(); bool WaitOne(int, bool); bool WaitOne(TimeSpan, bool); I also checked the documentation for Mutex, Semaphor, and EventWaitHandle...they all have the same three methods, no additional ones... Am I missing something here?
-
Could you actually proove to us that new overloads were added? I checked the WaitHandle.WaitOne() documentation on MSDN library, for all versions from 1.1 throuh 3.5. The following overloads have existed since the beginning of .NET time: bool WaitOne(); bool WaitOne(int, bool); bool WaitOne(TimeSpan, bool); I also checked the documentation for Mutex, Semaphor, and EventWaitHandle...they all have the same three methods, no additional ones... Am I missing something here?
Yes, .NET 2.0 SP1 (not .NET 2.1) added: bool WaitOne(int) bool WaitOne(TimeSpan) (The documentation at: http://msdn.microsoft.com/en-us/library/system.threading.waithandle.waitone.aspx[^] is inconsistent.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
Yes, .NET 2.0 SP1 (not .NET 2.1) added: bool WaitOne(int) bool WaitOne(TimeSpan) (The documentation at: http://msdn.microsoft.com/en-us/library/system.threading.waithandle.waitone.aspx[^] is inconsistent.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
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.
-
How is it whining to ask Microsoft to follow their own spec? This is a big reason I hate this industry.
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
modified on Thursday, October 9, 2008 3:09 PM
-
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.
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
-
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
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
-
They added new overloaded methods to WaitHandle.WaitOne() which, if used, will break on systems that don't have SP1 installed. Mind you, the program will start without any complaint. I just wasted hours on that. Can we all chip in a buy a huge middle finger statue to build in front of Microsoft headquarters? (To counteract the virtual one they are showing to us.) ADDED: So everyone understands. Microsoft added some overloaded methods between .NET 2.0 and .NET 2.0 SP1. (Not between major versions, mind you, but between service packs!) Let me repeat; Microsoft changed an interface with a service pack.
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
modified on Wednesday, October 8, 2008 12:48 PM
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.
-
They added new overloaded methods to WaitHandle.WaitOne() which, if used, will break on systems that don't have SP1 installed. Mind you, the program will start without any complaint. I just wasted hours on that. Can we all chip in a buy a huge middle finger statue to build in front of Microsoft headquarters? (To counteract the virtual one they are showing to us.) ADDED: So everyone understands. Microsoft added some overloaded methods between .NET 2.0 and .NET 2.0 SP1. (Not between major versions, mind you, but between service packs!) Let me repeat; Microsoft changed an interface with a service pack.
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
modified on Wednesday, October 8, 2008 12:48 PM
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.
-
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.
"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
-
Chris Mankowski wrote:
It seems you're saying that if you use an overload that only available in 2.0 SP1, you want the compiler to only target that build? Just like you can target 1.0, 1.1, and 2.0? Sounds reasonable, and I would expect that there is a way to do it.
Unfortunately, no there isn't a way to tell the compiler to target a specific SP level. You can target specific major releases (2.0, 3.0, 3.5) through VS2008 but you actually get 2.0 SP1, 3.0 SP1, and 3.5 since the 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.
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
"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.
-
"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.
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 wrote:
He has a embedded .NET device, and people put their app on his device
Where does he say this? I re-read the thread and couldn't find any mention of that, but with 51 messages (so far) I may have missed it. I don't disagree that he should be taking an issue with this. If it really and truly is a breaking change, it shouldn't have been introduced with a service pack. At the very least it should be well documented, which it sounds like it wasn't.
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
-
What the hell are you talking about? Who the hell would put apache on an embedded device?
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
: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
-
They added new overloaded methods to WaitHandle.WaitOne() which, if used, will break on systems that don't have SP1 installed. Mind you, the program will start without any complaint. I just wasted hours on that. Can we all chip in a buy a huge middle finger statue to build in front of Microsoft headquarters? (To counteract the virtual one they are showing to us.) ADDED: So everyone understands. Microsoft added some overloaded methods between .NET 2.0 and .NET 2.0 SP1. (Not between major versions, mind you, but between service packs!) Let me repeat; Microsoft changed an interface with a service pack.
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
modified on Wednesday, October 8, 2008 12:48 PM
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.
-
: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
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
-
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
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, 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
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
-
They added new overloaded methods to WaitHandle.WaitOne() which, if used, will break on systems that don't have SP1 installed. Mind you, the program will start without any complaint. I just wasted hours on that. Can we all chip in a buy a huge middle finger statue to build in front of Microsoft headquarters? (To counteract the virtual one they are showing to us.) ADDED: So everyone understands. Microsoft added some overloaded methods between .NET 2.0 and .NET 2.0 SP1. (Not between major versions, mind you, but between service packs!) Let me repeat; Microsoft changed an interface with a service pack.
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
modified on Wednesday, October 8, 2008 12:48 PM
yeah.. the same is happened with GC.Collect ;}
peace & serenity