Great; Microsoft reintroduced DLL hell with .NET 2.0 SP1 [modified]
-
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
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?
-
Are you using C# or VB? The reason they don't have optional params in C# is to be "more resiliant in the face of interface changes" (Approximate quote, not sure where from, think msdn mag). C# will always bind to a specific overload. This should be a non-issue in C#. I wouldn't be too surprised if VB breaks when there are interface changes, but I suppose thats the cost of a more fluent language. So lemme get this right: 1. Compile an app under .Net 2.0. 2. Install SP1. 3. Do not recompile, app under .Net 2.0 "SP0" doesn't work. Is that your scenario? That would be really bad. If it's the following way, I am pretty sure it's one of those "breaking changes" that we seem to need to deal with (alot with Microsoft it seems): 1. Compile an app under .Net 2.0: success 2. Install SP1. 3. Compile the app under .Net 2.0 SP1: fails on compile.
He who asks a question is a fool for five minutes. He who does not ask a question remains a fool forever. [Chineese Proverb] Jonathan C Dickinson (C# Software Engineer)
I think what he's saying is this: 1. Compile an app under .NET 2.0 SP1 using newly available method signatures 2. Run that app on a PC that has .NET 2.0 (but NOT SP1) 3. App runs fine until it hits the code that uses the new methods then it bombs It is an issue, and is obviously a bug in the compiler by not flagging SP1 as a dependency on generated application
-
John C wrote:
it's dead easy to check for the version of .net installed in both an installer and in code that relies on something
In an embedded environment? You miss the point--Microsoft made a pledge that .NET wouldn't do this and it does. I've been through the wars and the DLL hell problem was largely one of Microsoft's making (they refused to version their own DLLs by name and still do!) Still, .NET was allegedly going to solve this it hasn't. SxS was supposed to solve it, it just introduced even more problems (like giving very vague errors when it can't find the proper DLL.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
You miss the point--Microsoft made a pledge that .NET wouldn't do this and it does. MS had to make this pledge because they were simply unable to control themselves with every other library they've ever released. It would be nice if they actually honored their pledge, but making the pledge didn't change their internal problems, so it's hardly suprising that they broke it. This is just one of the many things we have to accept when using MS-produced libraries. I've actually come to think of it as a small added bit of job security.
patbob
-
Why continue to roll the boulder up the hill (re: camus, the myth of sisyphus, pardon my speling, ;) There are better alternatives... including Apache. If not you, who? If not now, when? -- posted on a placard in the stairwell of the Halsey Field House, USNA
David
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
-
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?
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
-
Adding a new method (or a new overload to a method) is not breaking the interface. Breaking the interface would be changing the current declaration of the method (like changing return type, paramaters (and types), etc). Adding a new method is just simply adding to the interface.
Member 4184135 wrote:
Adding a new method is just simply adding to the interface.
I disagree. Microsoft said that if you develop against a version of .NET, it will run on any system running that version of .NET. By slipstreaming new methods into a Service Pack, you have broken the .NET 2.0 interface.
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
You hate Microsoft so bad stop using it! I hear people crying about what Microsoft is doing to them. They running a business. They try to make improvements to help users of their products. And I keep reading crap from a small number of user about what Microsoft is doing to them. There are millions of user that are satisfied with the effort put forth by Microsoft to help make our jobs easier. If you don't like it use something else and stop crying.
This is a bullshit response. Microsoft promised that if you target a specific version of .NET, it would work on all installations of that version. What Microsoft did with SP1 hurt users since applications that are signed to use .NET 2.0 may now fail. All I'm asking for is some respect from Microsoft to their own rules and to respect the promises they made to the developer community.
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
You hate Microsoft so bad stop using it! I hear people crying about what Microsoft is doing to them. They running a business. They try to make improvements to help users of their products. And I keep reading crap from a small number of user about what Microsoft is doing to them. There are millions of user that are satisfied with the effort put forth by Microsoft to help make our jobs easier. If you don't like it use something else and stop crying.
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
-
John C wrote:
it's dead easy to check for the version of .net installed in both an installer and in code that relies on something
In an embedded environment? You miss the point--Microsoft made a pledge that .NET wouldn't do this and it does. I've been through the wars and the DLL hell problem was largely one of Microsoft's making (they refused to version their own DLLs by name and still do!) Still, .NET was allegedly going to solve this it hasn't. SxS was supposed to solve it, it just introduced even more problems (like giving very vague errors when it can't find the proper DLL.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
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.
-
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