Coffeehouse Thread

15 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

DLL Hell gone - but .NET "framework" version problems ahead

Back to Forum: Coffeehouse
  • User profile image
    GrumpyWookie

    On of the best features of the .NET Framework would have to be the better control of version'ing of DLL's (assemblies).

    The old COM way of registering with a ProgID - and only allowed one - has been replaced by Strong Names - and the GAC - just awesome.

    We have a dev, UAT and prod backup "versions" of about 15 DLLs - all on the same machine - and all working simultaneouly - amazing.

    BUT - I'm forseeing a problem with VERSION's - with the .NET Framework as a whole !!

    Does anyone else have any thoughts or comments regarding the 1.0, 1.1 and forth-coming 2.0 frameworks ??

    Can a PC (client or server) run with BOTH - or "all three" ?!?

    Does that mean having to compile using a specific framework version ?   And the manifest within the assembly will know which framework to run with ??

    I guess it's a symptom of 'changes over time' - with new features & functionality - not as bad as the old DLL Hell - and MDAC nightmares...!

  • User profile image
    iStation

    chrisoc wrote:

    BUT - I'm forseeing a problem with VERSION's - with the .NET Framework as a whole !!


    This seems to be A BIG PROBLEM!
    ;(

  • User profile image
    jonathanh

    I'm developing 2.0 code while using client apps written using the 1.1 framework (and maybe even some against the 1.0 framework, I haven't checked).  It all works - you can have multiple versions installed side-by-side and it does the right thing.

  • User profile image
    Minh

    chrisoc wrote:

    Can a PC (client or server) run with BOTH - or "all three" ?!?

    Sure, if you look in the Windows directory, each runtime version (1.0, 1.1, 2.0) occupies a separate directory, so no problem co-existing.

    chrisoc wrote:

    Does that mean having to compile using a specific framework version ?   And the manifest within the assembly will know which framework to run with ??

    Yes. When you're adding a reference, you do it to a specific version -- likewise, your client must have that version to use your app.

  • User profile image
    Minh

    Beer28 wrote:
    why don't people just put the version in the actual filename like on linux?

    In a way that's how it works -- because each runtime is stored in its own uniquely named directory.

  • User profile image
    Minh

    iStation wrote:
    chrisoc wrote:
    BUT - I'm forseeing a problem with VERSION's - with the .NET Framework as a whole !!


    This seems to be A BIG PROBLEM!
    ;(
    How so?

  • User profile image
    iStation

    A simplicity at one place is a complexity elsewhere...

    Should I prepare for the preprocessor hell?

    # if FCL1.0
    # if FCL1.1
    # if FCL2.0
    # if FCL3.0
    ....

    ;O

  • User profile image
    jonathanh

    If you really want to compile multiple versions of your app, each targetting a different version of the framework, then yes, you can do that.  But since the different versions strive very hard for upwards compatibility, there's often no reason to. 

  • User profile image
    iStation

    for example
    WindowsForms
    Form1
      [STAThread]
      static void Main()
      {
          Application.Run(new Form1());
      }

      private void button1_Click(object sender, System.EventArgs e)
      {
          Form2 form2 = new Form2();
          form2.ShowDialog(this); 
          form2 = null;
      }

    Form2
      private void Form2_Activated(object sender, System.EventArgs e)
      {
          #if FCL2.0
          // OK for Whidbey(FCL2.0). 
          // Form1(Dialog owner) can not be focused during MsgBox is opened.
          MessageBox.Show(this, "Dialog owner Form1 should not be focused!");
          #else
          // But we have to use the code below for FCL1.1 to get the same behavior.
          MessageBox.Show(this.Owner, "Dialog owner Form1 should not be focused!");
          #endif

          this.Close();
      }

    ;(

  • User profile image
    Rossj

    I've got to ask, and hope a softie can answer.

    What is the biggest solution (in terms of LOC and projects/solution) that Microsoft built with VS.Net 2003 for testing before it was released?

  • User profile image
    Sampy

    iStation, why don't you just ship the app with the version of the framework you support? We offer a redistributable for just that reason.

    You can enforce your version choice with a config file. Say you only support 1.1 and that if a customer only has 2.0 they may experience some weirdness. Pick your version and stick with it until you want to move. I don't see a compelling reason to try and stradle versions.

  • User profile image
    phunky_avoc​ado

    One of the criticisms of Microsoft vs. Apple many years ago was the way Microsoft embedded the content type of a file in the file's name (e.g., a text file had the extension 'txt', etc.).  Anti-Microsoft types claimed that was a very bad thing.  I suppose people still use that as ammunition agains Microsoft although I have not seen it lately (maybe because Apple is now doing the same thing, I dunno).

    So anyway, if there was any merit to the above criticism, how would embedding a version string in the dll's name be considered a good thing?

    Beer28 wrote:
    why don't people just put the version in the actual filename like on linux?
    There is no dll hell with .so files because of just that.

    I can understand why not with COM servers because of those class id's but for object code dll's there's just no reason people always omit the version # out of the filename. It's simple and it works.


  • User profile image
    AndyC

    Beer28 wrote:
    why don't people just put the version in the actual filename like on linux?
    There is no dll hell with .so files because of just that.


    That's actually what Microsoft used to do with the old VBRUNxxx dlls However it introduces a subtle problem of its own:
     
    Let's say you write a dll called MyOwnDLLv1. Later this gets updated to MyOwnDLLv2, but since all your old applications are explicitly loading MyOwnDLLv1 they shouldn't break, right?

    Unfortunately you now discover a horrendous security bug which has been present since the first release and so you have to update and re-issue both versions, both with the original names (so that they get loaded as expected). All of a sudden DLL hell comes back, because there is no way to guarantee which version of each DLL is present and if your security fix breaks an application, there is nothing you can do about it other than possibly release yet another version with the same name.

    There really isn't an easy solution to this problem - short of not having shared libraries at all. COM goes some way by insisting on interface compatability, but even that doesn't actually guarantee that code won't break in some subtle way.

  • User profile image
    AndyC

    Beer28 wrote:


    If you're going to update an old version, you have to be extra careful. In the linux world, as far as I can tell, that's pretty rare, once a version hits it's life span end, people generally don't link it anymore.


    Linux gets round it with a bit of symbolic linking at the filesystem level. For a given library MySharedLibrary, with major version MV and minor version mv, the file system is set up such that:

    MySharedLibrary.so links to MySharedLibrary.MV.so

    and

    MySharedLibrary.MV.so links to the latest minor version of that library, MySharedLibrary.MV.mv.so

    Applications can therefore request a versionless filename and have the latest version load, or a specific major version and let the filesystem direct them to the latest bugfixed minor version of that major release.

    That solution actually works reasonably well (at the expense of having to traverse several symlinks) but is by no means bulletproof. It's also pretty much what .NET is doing "under the hood" to support installations of multiple CLR versions.

    It is better than the old Windows DLL system though, that's for certain.

  • User profile image
    iStation

    Sampy wrote:
    iStation, why don't you just ship the app with the version of the framework you support? We offer a redistributable for just that reason.

    As for customers, I agree with you, if they like to install many .NET versions.

    I don't want to have two source codes for the same app. After the release of FCL2.0, I'll freeze the development for FCL1.1 and migrate to 2.0.

    I'm adding codes of UI for FCL2.0 tested in small projects on Whidbey to my app on FCL1.1 in advance to prepare for the release of 2.0 internaly.

    Will you freeze FCL1.1 after the release of FCL2.0?
    I hope so.
    Smiley

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.