Great; Microsoft reintroduced DLL hell with .NET 2.0 SP1 [modified]
-
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
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)
-
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
Joe, quit whining! (giggle)
-
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:
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.
I concur.. I don't get it. If you target 2.0 without the SP, don't use the new overloads. It's not rocket science. :zzz:
Joe Woodbury wrote:
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.
Clear case of RTFM :-D
-
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
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
-
John C wrote:
Programming is nothing if not endless sets of compromises between the ideal and the real.
Oh, I thought it was endless sets of compromises between sucks and sucks less.
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.
-
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 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.
-
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
Joe Woodbury wrote:
Let me repeat; Microsoft changed an interface with a service pack.
Microsoft seems interested in repetition. One of my favorite (no, DEFINITELY my favorite) articles on this site is this one: A Custom DataGrid which Allow freezing of Headers/Rwos/Columns. This scrollable DataGrid, with a modification I will discuss shortly, has become one of the most useful and used complex components in our Web interface. However, the original code fails due to a property that was added in SP1 for NET 1.1 that, when set, forced the cells of the header row of the HTML table that is generated as the final result of the DataGrid to render as th cells instead of td. Unhappily, our setup had not yet had the service pack applied, and it took some time to get approval to do so (yes, I know, NET 1.1 SP1 has been out for a LONG time, but that's corporate life for you). It was an interesting exercise to correct the code so it worked without the service pack; I wound up removing the line of code that produced the error, then I modified the Render function to explicitly replace the TD markup with TH in the first generated row of the table. However, it does emphasize the point that Microsoft makes a habit of making interface changes of this nature.
-
John C wrote:
Programming is nothing if not endless sets of compromises between the ideal and the real.
Oh, I thought it was endless sets of compromises between sucks and sucks less.
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:
John C wrote: Programming is nothing if not endless sets of compromises between the ideal and the real. Oh, I thought it was endless sets of compromises between sucks and sucks less.
And the effective difference is....? :laugh:
-
I agree with you. There should have been a version change or leave the changes out.
Rocky <>< Recent Blog Post: Browser Wars – IE lost – Firefox rising..
Rocky Moore wrote:
I agree with you. There should have been a version change or leave the changes out.
*nods* It's indicative of the general lack of release discipline at MS that changes like this occur. I'm sure some development manager will read this and feel his blood pressure creep up twenty points. How does one keep a nutjob developer or group from introducing changes like this without an audit that may cost nearly as much as the development effort itself? That might be a worthy thread of discussion
-
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