Results 1 to 7 of 7

Thread: DLL that works with both framework 2 and framework 4

  1. #1

    Thread Starter
    Addicted Member
    Join Date
    May 2004
    Posts
    141

    DLL that works with both framework 2 and framework 4

    If I build a program targeting Framework 2 then I understand that that program needs framework 2. It obviously can't run on a machine that does not have framework 2 installed.
    (For example a fresh install of Windows 10 does not have FW2)

    If I build a program targeting Framework 4 then that program needs framework 4. I accept that it can't run on a machine that does not have Framework 4 (For example a fresh install of Windows 7 does not have FW4)

    But now I'm looking at "Devart.Data.MySql.DLL" (a .net connector for MySQL databases)

    That dll, just the one file, works on any machine no matter what framework is installed. So it works on a machine that only has FW2 and also works on another machine that only has FW4

    How do they do that? How do they make a .net assembly that works on either framework?

  2. #2
    eXtreme Programmer .paul.'s Avatar
    Join Date
    May 2007
    Location
    Chelmsford UK
    Posts
    25,458

    Re: DLL that works with both framework 2 and framework 4

    Each successive Framework subsumes the previous Frameworks. So a .Net 2.0 dll will work with .Net 4

  3. #3

    Thread Starter
    Addicted Member
    Join Date
    May 2004
    Posts
    141

    Re: DLL that works with both framework 2 and framework 4

    Quote Originally Posted by .paul. View Post
    Each successive Framework subsumes the previous Frameworks. So a .Net 2.0 dll will work with .Net 4
    That's not true. Framework 3.5 is, as you said, based on top of framework 2. In fact 3 and 3.5 are just additions to FW2. That's why FW3 and 3.5 are so damn big.

    But FW4 is different. It is not built on top of FW3 or 3.5 an application that targets 2, 3 or 3.5 will not work on a machine that ONLY has FW4
    Last edited by Axcontrols; Nov 12th, 2017 at 07:06 AM.

  4. #4

    Thread Starter
    Addicted Member
    Join Date
    May 2004
    Posts
    141

    Re: DLL that works with both framework 2 and framework 4

    But now I built my own DLL that specifically targets FW2 and, strangely, it also works on a machine that only has FW4

    So, whereas an .EXE appears to check what frameworks are available and displays box saying that FWx is required. The same does not apply to a DLL. Maybe once the EXE has checked then the DLL called by that EXE just works as long as functions it calls exist in the framework being used by the EXE.

    or something like that.

  5. #5
    eXtreme Programmer .paul.'s Avatar
    Join Date
    May 2007
    Location
    Chelmsford UK
    Posts
    25,458

    Re: DLL that works with both framework 2 and framework 4

    Quote Originally Posted by Axcontrols View Post
    That's not true. Framework 3.5 is, as you said, based on top of framework 2. In fact 3 and 3.5 are just additions to FW2. That's why FW3 and 3.5 are so damn big.

    But FW4 is different. It is not built on top of FW3 or 3.5 an application that targets 2, 3 or 3.5 will not work on a machine that ONLY has FW4
    You might want to check. There's FW4 and there's FW4 Client Profile which isn't the full Framework

  6. #6
    eXtreme Programmer .paul.'s Avatar
    Join Date
    May 2007
    Location
    Chelmsford UK
    Posts
    25,458

    Re: DLL that works with both framework 2 and framework 4


  7. #7
    You don't want to know.
    Join Date
    Aug 2010
    Posts
    4,578

    Re: DLL that works with both framework 2 and framework 4

    You're not quite right, .paul., but the real answers are so convoluted I don't even know if I know all of them anymore.

    Versioning .NET up to recently you've had to keep track of two things: "Which CLR does it use?" and "Which libraries does it come with?"

    The CLR is the big thing you have had to install for the most part. Getting the libraries is the other half. If you have a compatible CLR *and* compatible libraries, you can run. It turns out "compatible" is more complicated than you might think.

    .NET 1.0 and .NET 1.1 are completely incompatible CLRs. There is no way to make apps interoperate without recompiling.

    .NET 2.0 is another new CLR. It is not compatible with .NET 1.0 or 1.1.

    .NET 3.0 is a new set of libraries added to the set installed with the .NET 2.0 CLR. So if you have .NET 3.0, you can run .NET 2.0 apps safely. But you can't always run .NET 3.0 apps on .NET 2.0 systems. If you try, you have to make sure you don't accidentally use any .NET 3.5 libraries.

    .NET 3.5 is a new set of libraries added to the set installed with .NET 3.0. Basically everything in the last paragraph applies.

    .NET 4.0 came with a new CLR with a new, interesting feature: it can be installed and run side-by-side with the .NET 2.0 CLR. It's intended to be mostly compatible with the .NET 2.0 CLR, but there are a handful of breaking changes. I'm not sure how every way worked, but I know I had to mess with some app.config files to make some .NET 2.0 libraries agree to run on the .NET 4.0 CLR.

    .NET 4.5 is 'more libraries with the .NET 4.0 CLR'.

    Everything past that is some kind of nightmare hellscape and the reason a lot of people quit. All I remember about compatibity is there's some 4.6.? version that was a limited time-exclusive for Windows 10, as if that encourages developers to use it.

    Going forward, the compatibilty story is:

    • If you target the .NET Framework, you inherit this versioning story and will only work on Windows safely.
    • If you target .NET Core, you will always be compatible with future .NET Core versions and your program might work on Linux and Mac OS.
    • If you target .NET Standard, you will be limited in what libraries you can use but you will always be compatible with EVERY future .NET version and EVERY future .NET CLR, and your program will work on Windows, Mac, Linux, Android, iOS, and platforms that haven't been invented yet.


    So, anyway, towards Axcontrols:

    The DLL works because the 2.0 and 4.0 CLRs are "mostly compatible". It is probably compiled against .NET 4.0, but I could be wrong about the direction that complains. But it's possible there have been some changes in either CLR, that could cause subtle bugs that didn't exist in its "original" framework.

    It's really best to choose your target carefully and recommend your customers have exactly that framework installed. Going forward, the smartest thing to do when writing libraries is to target .NET Standard so you can be safe until Microsoft throws it in the garbage and replaces it with something else next year.
    This answer is wrong. You should be using TableAdapter and Dictionaries instead.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width