Great; Microsoft reintroduced DLL hell with .NET 2.0 SP1 [modified]
-
You're running .NET apps in an embedded environment? Sounds like a lot of unnecessary overhead to me... still though, failing the ability to do version checks for whatever reason, the simplest way to prevent and notify the user about this error would be a try/catch once at application initialization. If it fails, notify the user they need SP1 through appropriate means.
Homncruse wrote:
If it fails, notify the user they need SP1 through appropriate means.
The problem isn't the user installing SP1; they can't (and we can't just push out an update of this size over our relatively slow connections.) The problem is that this failure means that third party vendors using our device may run into the same issue and not be able to serve our joint customers well. Besides, my point, once again, was that Microsoft promised this wouldn't happen. The entire version model of .NET was designed to prevent this very thing from happening. Microsoft broke their own design and promises to us developers.
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
That too depending on if your a glass half full or half empty type of dude. :)
"It's so simple to be wise. Just think of something stupid to say and then don't say it." -Sam Levenson
-
How can you not get it? The contract with .NET is that if an interface changes, the version would change and a program written to that version would not work on a previous version. You don't change interfaces with a service pack, only with a new version. To make this even more complicated, when using Visual Studio, intellisense picks up the new interface and lets you use it WITH NO WARNING THAT IT APPLIES ONLY TO SP1. In the real world, this means someone writing software for our embedded device could use methods that Visual Studio shows as being valid and then the software fails on the device, sometimes without a clear error as to why (yes, an exception should be thrown and caught, but that's not always what you actually see.) Because of the way Microsoft did the service packs for .NET, they are super expensive to put on our devices.
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 Woodbury wrote:
You don't change interfaces with a service pack, only with a new version.
Right, because interfaces didn't change with XP SP2, and Vista SP1 didn't change the experience either. I understand you meant interfaces in a different definition of the word, but to some extent, there's a reason why that term is overloaded (no pun intended). Like others have said, to use the new functionality, you must install whatever it takes to enable that new functionality. Contrary to ludite beliefs, computers are not magic. All those 0s and 1s have to come from somewhere.
-
Homncruse wrote:
If it fails, notify the user they need SP1 through appropriate means.
The problem isn't the user installing SP1; they can't (and we can't just push out an update of this size over our relatively slow connections.) The problem is that this failure means that third party vendors using our device may run into the same issue and not be able to serve our joint customers well. Besides, my point, once again, was that Microsoft promised this wouldn't happen. The entire version model of .NET was designed to prevent this very thing from happening. Microsoft broke their own design and promises to us developers.
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
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.
-
Joe Woodbury wrote:
You don't change interfaces with a service pack, only with a new version.
Right, because interfaces didn't change with XP SP2, and Vista SP1 didn't change the experience either. I understand you meant interfaces in a different definition of the word, but to some extent, there's a reason why that term is overloaded (no pun intended). Like others have said, to use the new functionality, you must install whatever it takes to enable that new functionality. Contrary to ludite beliefs, computers are not magic. All those 0s and 1s have to come from somewhere.
You don't get it. One of the points of .NET is that you use a specific build of .NET and are assured it runs everywhere that version runs. When interfaces are changed, you version .NET. This was placed there by design to avoid this exact problem.
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
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
-
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.