Great; Microsoft reintroduced DLL hell with .NET 2.0 SP1 [modified]
-
I hate to jump on the anti-MS bandwagon, but even making the leap that you're correct, is it really the first time MS broke their design or promises to its customers? No. Vista was supposed to be a blessing to all those who have computers - you know, solve world hunger and all that. As initially proposed, it probably would have been a pretty good OS if they fulfilled all their original promises. Did they do so? No. Did the world end? No. Would Vista have been better? Probably. Is it "broken"? That depends on who you ask. If you can't install SP1, don't use its *added* functionality. Your previous calls to that function should continue to work just fine, and if not, maybe you should patch the application so that the framework doesn't get confused. Nothing was removed, nothing was changed. Things were added because of the changes to 3.5 and its dependencies on 2.0. NOT pushing it back to 2.0 would have arguably broken their design more than your argument.
You REALLY don't get it. .NET (Not Vista, not Win32, not CRT, not whatever, .NET) was designed that you could write your application for a specific version of the CLR and .NET would allow your application to run only if that version were installed. This was one of the design parameters of .NET--and is a design feature that you can leverage with great results with strongly typed assemblies.
Homncruse wrote:
Things were added because of the changes to 3.5 and its dependencies on 2.0.
Which was a HUGE mistake since it violated one of the design parameters of .NET, but your argument is incorrect since this change was introduced with .NET 2.0 SP1 AFTER .NET 3.5 was released (.NET 3.5 actually has a dependency on .NET 2.1, another mess.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
So...getting past the fact that Microsoft broke things for you application with the introduction of a Service Pack, I see a few options here: You can ensure that your application is not calling the new SP1 overload on
WaitHandle.WaitOne(), which will ensure that the application will behave properly on .NET 2.0 and .NET 2.0 SP1. You can add code in your application's startup to test for the correct version of .NET and take the appropriate action. You can take a look at this article[^] for a .NET way to do this. You can test for the correct version of .NET at install time and only install if the proper version and service pack are installed. If you want to do this correctly, you will need to write some C++ code (see the article I referenced earlier for links on some C++ code to do this).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
You missed the boat on his problem. He is not the one doing the calling. He has a embedded .NET device, and people put their app on his device. The developers who use his device can use the new SP methods, and it looks like his device is screwed, not their code. He should be pissed, since he can't protect himself from MS making him screw the pooch.
Silver member by constant and unflinching longevity.
-
You REALLY don't get it. .NET (Not Vista, not Win32, not CRT, not whatever, .NET) was designed that you could write your application for a specific version of the CLR and .NET would allow your application to run only if that version were installed. This was one of the design parameters of .NET--and is a design feature that you can leverage with great results with strongly typed assemblies.
Homncruse wrote:
Things were added because of the changes to 3.5 and its dependencies on 2.0.
Which was a HUGE mistake since it violated one of the design parameters of .NET, but your argument is incorrect since this change was introduced with .NET 2.0 SP1 AFTER .NET 3.5 was released (.NET 3.5 actually has a dependency on .NET 2.1, another mess.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
No, I get what you're saying, but my argument about MS eventually breaking their own design isn't without precedent. If anything, MS's SDLC must look something like this: 1.) Design 2.) Implement 3.) TestRelease 4.) Bugfix 5.) Repeat 3 and 4 n times until 6.) Violate Design In MOST of MS's ventures (I can't/won't say all) -- and to be fair, that of most ISVs as well, but they receive less attention due to their obviously smaller market hold -- initial design (and its parameters) only withstands for so long. Software design isn't perfect, and for an ongoing project like .NET and all its iterations, we should be lucky that we've gone this long without a significant design parameter change. But if you're really that worked up about it, you could actually try (futilely?) contacting them or overthrow the .NET PM.
-
You missed the boat on his problem. He is not the one doing the calling. He has a embedded .NET device, and people put their app on his device. The developers who use his device can use the new SP methods, and it looks like his device is screwed, not their code. He should be pissed, since he can't protect himself from MS making him screw the pooch.
Silver member by constant and unflinching longevity.
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
-
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. I think our definitions of contract is different: Isn't a "contract" between a specific interface/method overload and the caller? Does overloading a method invalidate exsisting contracts? I don't think so, and think that overloading a method between service packs is no worse than adding extension methods. Both are fine to do between releases. Your thoughts?
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
-
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
-
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.
-
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
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