none
How can I create a dll compatible to any dotnet framework RRS feed

  • Question

  • Hi,

    I have different projects with different dotnet frameworks 1.0, 1.1, 2.0 etc.
    all these projects integrated one custom licensing project (dll reference). Initially i made that licensing project (with output as dll) in dotnet 1.0.. to use that dll for 1.1 or 2.0 projects i have to convert licensing project to corresponding dotnet framework first and then i use that dll.

    I'm looking for some solution so that my dll will be same (without converting to other frameworks and then using) and i can use in any dotnet framework..

    There will be some way to make the dll consistent for any dotnet framework. For example if we use some third party controls etc those have one set of assemblies and same are used in any dotnet framework.

    Please help me out on this issue.. advance thnx! :)

    Regards,
    Thursday, July 10, 2008 9:57 AM

Answers

  • Per http://msdn.microsoft.com/en-us/library/47a587hk.aspx:

        The .NET Framework supports both backward and forward compatibility for applications created using version 1.1 only. It does not support forward compatibility in applications created using version 2.0.

    This would seem to suggest that you must release one version compiled for 1.0 and another compiled for 1.1.  However, you do not need to release different versions for 2.0, 3.0, or 3.5, unless you need to take advantage of the changes in those later frameworks.

    Searching on the web, I've found some conflicting info on whether you can just load 1.0 DLLs in CLR 2.0 and up.  Probably because the 1.0 version is not widely used.  Maybe someone else knows this answer.
    • Marked as answer by Zhi-Xin Ye Tuesday, July 15, 2008 6:54 AM
    Thursday, July 10, 2008 11:27 AM
  • Run your projects under different processes, having the processes run different versions of dotnet framework. To invoke methods across the processes, use remoting technologies.

    However, this method may not work if it involves user controls. It is because user controls do not work across process boundary, according to my experience.

    Good luck!

    • Marked as answer by Zhi-Xin Ye Tuesday, July 15, 2008 6:54 AM
    Saturday, July 12, 2008 4:15 PM

All replies

  • Per http://msdn.microsoft.com/en-us/library/47a587hk.aspx:

        The .NET Framework supports both backward and forward compatibility for applications created using version 1.1 only. It does not support forward compatibility in applications created using version 2.0.

    This would seem to suggest that you must release one version compiled for 1.0 and another compiled for 1.1.  However, you do not need to release different versions for 2.0, 3.0, or 3.5, unless you need to take advantage of the changes in those later frameworks.

    Searching on the web, I've found some conflicting info on whether you can just load 1.0 DLLs in CLR 2.0 and up.  Probably because the 1.0 version is not widely used.  Maybe someone else knows this answer.
    • Marked as answer by Zhi-Xin Ye Tuesday, July 15, 2008 6:54 AM
    Thursday, July 10, 2008 11:27 AM
  • The V2 CLR has no problem loading V1.x assemblies.  What made you decide you needed to build a CLR version specific version of your assembly?
    Hans Passant.
    Thursday, July 10, 2008 12:25 PM
    Moderator
  • Run your projects under different processes, having the processes run different versions of dotnet framework. To invoke methods across the processes, use remoting technologies.

    However, this method may not work if it involves user controls. It is because user controls do not work across process boundary, according to my experience.

    Good luck!

    • Marked as answer by Zhi-Xin Ye Tuesday, July 15, 2008 6:54 AM
    Saturday, July 12, 2008 4:15 PM