Great; Microsoft reintroduced DLL hell with .NET 2.0 SP1 [modified]
-
Come on, what's with all the Microsoft hating around here lately? You know if you've been through the wars as I have that's a far cry from dll hell in the classic sense and it's dead easy to check for the version of .net installed in both an installer and in code that relies on something.
"It's so simple to be wise. Just think of something stupid to say and then don't say it." -Sam Levenson
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
-
But surely you need to make sure that the correct version of the .NET runtime is installed anyway? Am I missing something here? It seems to me you are saying "If I use a function not supported by the installed runtime, bad things happen". * Graham goes back to coding all-statically-linked C++ programs *
Microsoft added some overloaded methods between .NET 2.0 and .NET 2.0 SP1. (Not between major versions, mind you, but between service packs.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
Microsoft added some overloaded methods between .NET 2.0 and .NET 2.0 SP1. (Not between major versions, mind you, but between service packs.)
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 still don't get the problem. New methods are in .NET 2.0 SP1. Fine. If you want your program to call them, surely you need to make sure .NET 2.0 SP1 is installed? Isn't that the case for any new version / service pack of the framework. If you want to use the new stuff, the new stuff has to be installed. As alluded to in my last post, I work in C++, not .NET. I'm not having a go at you at all - I just don't understand what the problem is.
-
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
The SP thing has been muddled for years with Microsoft. In some cases they're pure bug fixes. In others they're bug fixes + new functionality (e.g., VS 2008 SP1). In the past they've said that "SPs will be pure bug fixes from now on." But they never stick to this.
Kevin
-
I still don't get the problem. New methods are in .NET 2.0 SP1. Fine. If you want your program to call them, surely you need to make sure .NET 2.0 SP1 is installed? Isn't that the case for any new version / service pack of the framework. If you want to use the new stuff, the new stuff has to be installed. As alluded to in my last post, I work in C++, not .NET. I'm not having a go at you at all - I just don't understand what the problem is.
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
-
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
Yes there are some new classes with .NET 2.0 SP1 which are automatically available if you using .NET 3.5 (the whole .NET naming is confusing). Anyway, if you run VS 2008 Code Analysis on your projects (BTW I highly recommend that for anyone), you will get warnings for all these situations.
Proud to be a CPHog user
-
I still don't get the problem. New methods are in .NET 2.0 SP1. Fine. If you want your program to call them, surely you need to make sure .NET 2.0 SP1 is installed? Isn't that the case for any new version / service pack of the framework. If you want to use the new stuff, the new stuff has to be installed. As alluded to in my last post, I work in C++, not .NET. I'm not having a go at you at all - I just don't understand what the problem is.
The problem is that while Visual Studio has compiler options to ensure you target only .NET 2.0 / .NET 3.0 / .NET 3.5 assemblies, it doesn't have any options to ensure you're using only methods from the service pack level you're targeting. If you install VS08, VS05 will see some additional methods and you can end up accidentally using them! Even the MSDN documentation often doesn't say correctly in which service pack the method was introduced. However, I think I've seen an FxCop task somewhere that can check that you use only methods from a specific service pack level.
-
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 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..
-
Come on, what's with all the Microsoft hating around here lately? You know if you've been through the wars as I have that's a far cry from dll hell in the classic sense and it's dead easy to check for the version of .net installed in both an installer and in code that relies on something.
"It's so simple to be wise. Just think of something stupid to say and then don't say it." -Sam Levenson
John C wrote:
that's a far cry from dll hell in the classic sense
Sounds pretty close to the insanity surrounding MFC42.dll, actually. I seem to recall spending hours tearing out my hair in frustration while trying to track down the cause of problems on Win9x... only to find that an older version was loaded in memory and calls were subtly failing because of it. This was actually possible to fix once we killed support for Win9x, since it was possible then to ensure our own private copy of the DLL got loaded... i doubt that's an option for the .NET runtime.
----
You're right. These facts that you've laid out totally contradict the wild ramblings that I pulled off the back of cornflakes packets.
-
The problem is that while Visual Studio has compiler options to ensure you target only .NET 2.0 / .NET 3.0 / .NET 3.5 assemblies, it doesn't have any options to ensure you're using only methods from the service pack level you're targeting. If you install VS08, VS05 will see some additional methods and you can end up accidentally using them! Even the MSDN documentation often doesn't say correctly in which service pack the method was introduced. However, I think I've seen an FxCop task somewhere that can check that you use only methods from a specific service pack level.
Daniel Grunwald wrote:
However, I think I've seen an FxCop task somewhere that can check that you use only methods from a specific service pack level.
Yes, there is an FxCop rule that can be used for this: http://blogs.msdn.com/fxcop/archive/2008/08/25/new-for-visual-studio-2008-sp1-and-fxcop-1-36-multi-targeting-rule.aspx[^]
Daniel Grunwald wrote:
The problem is that while Visual Studio has compiler options to ensure you target only .NET 2.0 / .NET 3.0 / .NET 3.5 assemblies
The real problem here is that once you install one of the service packs, you're actually targetting the SP not the base RTM version. In this scenario, even though VS shows .NET 2.0 it's really .NET 2.0 SP1.
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
-
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
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
-
John C wrote:
that's a far cry from dll hell in the classic sense
Sounds pretty close to the insanity surrounding MFC42.dll, actually. I seem to recall spending hours tearing out my hair in frustration while trying to track down the cause of problems on Win9x... only to find that an older version was loaded in memory and calls were subtly failing because of it. This was actually possible to fix once we killed support for Win9x, since it was possible then to ensure our own private copy of the DLL got loaded... i doubt that's an option for the .NET runtime.
----
You're right. These facts that you've laid out totally contradict the wild ramblings that I pulled off the back of cornflakes packets.
The mfc files were the least of my problems back in the day, throw in Crystal Reports with it's own dll hell and requirements and several other third party apps and it quickly spiraled into a support nightmare. Checking for one single version of the .net framework is a cakewalk by comparison.
"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
Yes it's shitty what they did but it's easily overcome now that you know. I feel your pain and outrage but at the end of the day it's all about getting the job done however necessary. Programming is nothing if not endless sets of compromises between the ideal and the real.
"It's so simple to be wise. Just think of something stupid to say and then don't say it." -Sam Levenson
-
Yes it's shitty what they did but it's easily overcome now that you know. I feel your pain and outrage but at the end of the day it's all about getting the job done however necessary. Programming is nothing if not endless sets of compromises between the ideal and the real.
"It's so simple to be wise. Just think of something stupid to say and then don't say it." -Sam Levenson
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
-
The mfc files were the least of my problems back in the day, throw in Crystal Reports with it's own dll hell and requirements and several other third party apps and it quickly spiraled into a support nightmare. Checking for one single version of the .net framework is a cakewalk by comparison.
"It's so simple to be wise. Just think of something stupid to say and then don't say it." -Sam Levenson
John C wrote:
throw in Crystal Reports with its own dll hell and requirements
Don't remind me of CR. We are still living with that madness.
John C wrote:
Checking for one single version of the .net framework is a cakewalk by comparison.
Maybe so, but still it's a case where the OS loader has that functionality already built-in, and would already work if MS wasn't lazy/schizo about versioning (assuming i understand the issue correctly, this is a side-effect of using 2.0 as the base for 3.5 - changes to core components for 3.5 must be made to 2.0 assemblies).
----
You're right. These facts that you've laid out totally contradict the wild ramblings that I pulled off the back of cornflakes packets.
-
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
-
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:
The contract with .NET is
Yours came with a contract?
Mark Salsbery Microsoft MVP - Visual C++ :java:
-
John C wrote:
throw in Crystal Reports with its own dll hell and requirements
Don't remind me of CR. We are still living with that madness.
John C wrote:
Checking for one single version of the .net framework is a cakewalk by comparison.
Maybe so, but still it's a case where the OS loader has that functionality already built-in, and would already work if MS wasn't lazy/schizo about versioning (assuming i understand the issue correctly, this is a side-effect of using 2.0 as the base for 3.5 - changes to core components for 3.5 must be made to 2.0 assemblies).
----
You're right. These facts that you've laid out totally contradict the wild ramblings that I pulled off the back of cornflakes packets.
Shog9 wrote:
Don't remind me of CR. We are still living with that madness.
My sympathies. You can imagine the real joy I felt when we moved to .net and I consigned CR to the fiery pits of hell from which it came.
Shog9 wrote:
assuming i understand the issue correctly, this is a side-effect of using 2.0 as the base for 3.5 - changes to core components for 3.5 must be made to 2.0 assemblies
Actually I don't fully understand the issue either, it sounds like a service pack for 2.0 introduced a new overload from a method he's calling which seems to not be much of an issue just don't call it after all but what do I know anyway, I'm low on nicotine at the moment and arguing with a guy about fertilizer on a gardening thread when I should be working. :)
"It's so simple to be wise. Just think of something stupid to say and then don't say it." -Sam Levenson
-
Joe Woodbury wrote:
The contract with .NET is
Yours came with a contract?
Mark Salsbery Microsoft MVP - Visual C++ :java:
Yes, 800 pages long in tiny type.
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
I understand your frustration. While a hack is not always the best solution ... can you use reflection to ease your woes?
Need software developed? Offering C# development all over the United States, ERL GLOBAL, Inc is the only call you will have to make.
Happiness in intelligent people is the rarest thing I know. -- Ernest Hemingway
Most of this sig is for Google, not ego.