Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. The Lounge
  3. Great; Microsoft reintroduced DLL hell with .NET 2.0 SP1 [modified]

Great; Microsoft reintroduced DLL hell with .NET 2.0 SP1 [modified]

Scheduled Pinned Locked Moved The Lounge
csharpquestion
74 Posts 29 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • C Chris Mankowski

    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?

    J Offline
    J Offline
    Joe Woodbury
    wrote on last edited by
    #39

    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

    J Y 2 Replies Last reply
    0
    • M Member 4184135

      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.

      J Offline
      J Offline
      Joe Woodbury
      wrote on last edited by
      #40

      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

      1 Reply Last reply
      0
      • P popfly

        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.

        J Offline
        J Offline
        Joe Woodbury
        wrote on last edited by
        #41

        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

        1 Reply Last reply
        0
        • P popfly

          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.

          J Offline
          J Offline
          Joe Woodbury
          wrote on last edited by
          #42

          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

          J 1 Reply Last reply
          0
          • J Joe Woodbury

            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

            H Offline
            H Offline
            Homncruse
            wrote on last edited by
            #43

            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.

            J 1 Reply Last reply
            0
            • H Homncruse

              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.

              J Offline
              J Offline
              Joe Woodbury
              wrote on last edited by
              #44

              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

              H 1 Reply Last reply
              0
              • M Member 96

                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

                H Offline
                H Offline
                Homncruse
                wrote on last edited by
                #45

                I prefer the realist or "engineering" approach; it's still 4 ounces of liquid in an 8 ounce glass!

                1 Reply Last reply
                0
                • J Joe Woodbury

                  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

                  H Offline
                  H Offline
                  Homncruse
                  wrote on last edited by
                  #46

                  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.

                  J 1 Reply Last reply
                  0
                  • J Joe Woodbury

                    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

                    H Offline
                    H Offline
                    Homncruse
                    wrote on last edited by
                    #47

                    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.

                    J 1 Reply Last reply
                    0
                    • H Homncruse

                      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.

                      J Offline
                      J Offline
                      Joe Woodbury
                      wrote on last edited by
                      #48

                      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

                      1 Reply Last reply
                      0
                      • H Homncruse

                        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.

                        J Offline
                        J Offline
                        Joe Woodbury
                        wrote on last edited by
                        #49

                        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

                        H 1 Reply Last reply
                        0
                        • S Scott Dorman

                          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

                          R Offline
                          R Offline
                          RichardM1
                          wrote on last edited by
                          #50

                          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.

                          S 1 Reply Last reply
                          0
                          • J Joe Woodbury

                            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

                            H Offline
                            H Offline
                            Homncruse
                            wrote on last edited by
                            #51

                            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.

                            1 Reply Last reply
                            0
                            • R RichardM1

                              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.

                              S Offline
                              S Offline
                              Scott Dorman
                              wrote on last edited by
                              #52

                              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

                              R 1 Reply Last reply
                              0
                              • C Chris Mankowski

                                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?

                                S Offline
                                S Offline
                                Scott Dorman
                                wrote on last edited by
                                #53

                                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

                                T 1 Reply Last reply
                                0
                                • J Joe Woodbury

                                  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

                                  J Offline
                                  J Offline
                                  Jon Rista
                                  wrote on last edited by
                                  #54

                                  Stop whining. :wtf:

                                  J 1 Reply Last reply
                                  0
                                  • J Jon Rista

                                    Stop whining. :wtf:

                                    J Offline
                                    J Offline
                                    Joe Woodbury
                                    wrote on last edited by
                                    #55

                                    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

                                    J 1 Reply Last reply
                                    0
                                    • J Joe Woodbury

                                      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

                                      J Offline
                                      J Offline
                                      Jon Rista
                                      wrote on last edited by
                                      #56

                                      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?

                                      J 1 Reply Last reply
                                      0
                                      • J Jon Rista

                                        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?

                                        J Offline
                                        J Offline
                                        Joe Woodbury
                                        wrote on last edited by
                                        #57

                                        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

                                        J 1 Reply Last reply
                                        0
                                        • J Joe Woodbury

                                          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

                                          J Offline
                                          J Offline
                                          Jon Rista
                                          wrote on last edited by
                                          #58

                                          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.

                                          J 1 Reply Last reply
                                          0
                                          Reply
                                          • Reply as topic
                                          Log in to reply
                                          • Oldest to Newest
                                          • Newest to Oldest
                                          • Most Votes


                                          • Login

                                          • Don't have an account? Register

                                          • Login or register to search.
                                          • First post
                                            Last post
                                          0
                                          • Categories
                                          • Recent
                                          • Tags
                                          • Popular
                                          • World
                                          • Users
                                          • Groups