locked
Is there any issues installing multiple .net frameworks parallel in same windows server? RRS feed

  • Question

  • User-777350147 posted

    Hi,

    I have 2 applications one is using .net framework 4.6.2 and other application using .net framework 4.8.

    Currently, the system has framework version 4.6.2, I am planning to install the 4.8 version of .net framework.

    Registry Editor shows "Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full" with 4.6.2 now.

    I have this doubt because of following reasons:

    1. The folder where .net framework binaries are saved is C:\Windows\Microsoft.NET\Framework64\
    2. This folder will contain a separate folder for each version of the .net framework like v2.0, v3.0, v3.5, v4.0.
    3. This folder will have one subfolder for each .net framework runtime but not for .net framework DLLs.
    4. Framework - Runtime + Base classes like System, System.Web, System.Configuration etc.
    5. Now for there will be DLLs of version 4.6.2 in this v4.0 folder.
    6. Once I install 4.8 version all these DLLs will be replaced right. I am expecting that 4.8 DLLs will be 100% compatible with 4.6.2.
    7. I believe this is one of the reasons to introduce .net core where the runtime is separated from the framework, so that framework can evolve as fast as possible.

    Q1. Please comment on my assumptions and also let me know if I can assume that it will be 100% compatible and can install a 4.8 version of .net framework? If there could be any issues let me know.

    While development when I try to reference a higher version of DLL to a lower version of the project it will not build.

    Q2. But how will it run with the higher version of the runtime but not while building?

    With regards.

    Nithin B.

    Monday, July 27, 2020 7:41 PM

All replies

  • User475983607 posted

    nithin.bandaru1

    Q1. Please comment on my assumptions and also let me know if I can assume that it will be 100% compatible and can install a 4.8 version of .net framework? If there could be any issues let me know.

    The .NET frameworks has always run side by side.  It is up to you to target the new framework in your project.  It is also up to you to do a basic analysis to make sure the code is not referencing using any deprecated APIs or methods.

    nithin.bandaru1

    Q2. But how will it run with the higher version of the runtime but not while building?

    It is up to you to change the target framework in Visual Studio and recompile your code to take advantage of the new framework.

    Monday, July 27, 2020 8:05 PM
  • User-777350147 posted

    mgebhard

    The .NET frameworks has always run side by side.  It is up to you to target the new framework in your project.  It is also up to you to do a basic analysis to make sure the code is not referencing using any deprecated APIs or methods.

    I am not convinced with this point because there could be many applications that are not developed by me running in the environment. It will break a lot of applications if it is not compatible with the previous versions(.net frameworks for those that are saved into the same folder as I mentioned above which will overwrite DLLs of previous versions).

    It just sounds very dangerous and if that's true it will be a serious consideration by anyone who uses dot net because I would not expect me installing framework 4.8 in my windows will break applications using 4.6.2 which are applications I did not develop.

    mgebhard

    It is up to you to change the target framework in Visual Studio and recompile your code to take advantage of the new framework.

    smilesmile I know it's up to me, but my question was why does the build fail though the frameworks are compatible with lower versions.

    For example, I have a library project that is developed using the 4.6.2 version of .net and another library project 4.8 version of .net framework. Now if I refer 4.8 framework library project into 4.6.2 framework library project, it will give build errors as it says I have referenced a higher version of the framework.

    So here my question was why should it fail because 4.8 is compatible with 4.6.2 or it fails because when you are referencing a project its becomes a dependency. So, build expects all dependencies to be less or equal to the .net version of the main library project probably because it expects it to run in the main library project framework version.

    Tuesday, August 4, 2020 6:43 AM
  • User1535942433 posted

    Hi ,

    As far as I think, if you refer  a .Net 4.8  framework library project to the .Net 4.6.2 framework library project,it will not resolve or in other words, the reference simply won't work.

    The degree of .NET Framework support for backward and forward compatibility is version-specific. 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. In the context of the .NET Framework, backward compatibility means that an application created using an early version of the .NET Framework will run on a later version. Conversely, forward compatibility means that an application created using a later version of the .NET Framework will run on an earlier version.

    The .NET Framework provides a high degree of support for backward compatibility. For example, most applications created using version 1.0 will run on version 1.1 and applications using version 1.1 will run on version 2.0. The .NET Framework also supports forward compatibility for version 1.1 only. However, for forward compatibility you might need to modify an application so that the application runs as expected. Applications created with version 2.0 will not run on earlier versions of the .NET Framework. For both backward and forward compatibility, a change to the .NET Framework that helps improve security, correctness, or functionality might also raise compatibility issues.

    Best regards,

    Yijing Sun

    Tuesday, August 4, 2020 8:37 AM
  • User753101303 posted

    Hi,

    You'll find detailed compability information at https://docs.microsoft.com/en-us/dotnet/framework/migration-guide/application-compatibility

     including both "runtime changes" (ie how an older 4.x application behaves when using a later runtime) and "retargeting changes" (ie what changes if you change and recompile a 4.x app to target a later framework).

    Tuesday, August 4, 2020 8:45 AM
  • User475983607 posted

    I am not convinced with this point because there could be many applications that are not developed by me running in the environment. It will break a lot of applications if it is not compatible with the previous versions(.net frameworks for those that are saved into the same folder as I mentioned above which will overwrite DLLs of previous versions).

    It just sounds very dangerous and if that's true it will be a serious consideration by anyone who uses dot net because I would not expect me installing framework 4.8 in my windows will break applications using 4.6.2 which are applications I did not develop.

    Seems to me you made up your mind before asking the question.

    For example, I have a library project that is developed using the 4.6.2 version of .net and another library project 4.8 version of .net framework. Now if I refer 4.8 framework library project into 4.6.2 framework library project, it will give build errors as it says I have referenced a higher version of the framework.

    ]So here my question was why should it fail because 4.8 is compatible with 4.6.2 or it fails because when you are referencing a project its becomes a dependency. So, build expects all dependencies to be less or equal to the .net version of the main library project probably because it expects it to run in the main library project framework version.

    A machine can, and often does, have many different versions of .NET installed.  It is very common for a server to host many web applications that target different version of .NET.  The part you misunderstand is the concept of a web application as a whole.  A web application can have many libraries.  The libraries cannot exceed the .NET version the main web application targets.  

    In your scenario, you must upgrade  the 4.6.2 project to 4.8 before the project can reference 4.8 features.   That is why I explained, it is up to you to do an analysis to make sure you can upgrade the target .NET framework.

    Tuesday, August 4, 2020 11:18 AM
  • User-777350147 posted

    Seems to me you made up your mind before asking the question.

    I not sure if I didn't explain my question correctly.

    What I am trying to say is there are already some applications that are using 4.6.2 that I didn't develop, I downloaded exe and installed from internet.

    So, Now if I install .NET framework 4.8 and if it brakes those applications I have installed from the internet, it will be a disaster, isn't it? How could I analyze the applications I have not developed.

    I would probably sound like I have made up my mind that this is now .net framework should work, but I am here to get validation because I didn't find any website claiming that.

    A machine can, and often does, have many different versions of .NET installed.  It is very common for a server to host many web applications that target different version of .NET.  The part you misunderstand is the concept of a web application as a whole.  A web application can have many libraries.  The libraries cannot exceed the .NET version the main web application targets. 

    Yes, I absolutely know this but it just that this is based on experience. I am looking for some claim by Microsoft or something like that.

    In your scenario, you must upgrade  the 4.6.2 project to 4.8 before the project can reference 4.8 features.   That is why I explained, it is up to you to do an analysis to make sure you can upgrade the target .NET framework.

    Ok. I have to just tried referencing .net framework version 4.8 in .net framework version library 3.5, 4.6.1, and 3.5 console app. To my surprise all three lower version projects build was successful without any errors or warnings.

    My assumptions on this look wrong somehow. I have no idea how it is able to build. I mean I was expecting something like 4.8 cant be referenced in 3.5 or something like that.

    Tuesday, August 4, 2020 8:31 PM
  • User475983607 posted

    I not sure if I didn't explain my question correctly.

    What I am trying to say is there are already some applications that are using 4.6.2 that I didn't develop, I downloaded exe and installed from internet.

    So, Now if I install .NET framework 4.8 and if it brakes those applications I have installed from the internet, it will be a disaster, isn't it? How could I analyze the applications I have not developed.

    I would probably sound like I have made up my mind that this is now .net framework should work, but I am here to get validation because I didn't find any website claiming that.

    As stated above, the .NET framework versions are backward compatible.  Perhaps read the official docs if you do not believe the community.

    https://docs.microsoft.com/en-us/dotnet/framework/migration-guide/versions-and-dependencies

    Tuesday, August 4, 2020 9:47 PM
  • User-777350147 posted

    Perhaps read the official docs if you do not believe the community.

    I am very sorry if I have offended the community.

    It's just that it takes more than a community opinion to prove a point in the software industry and especially if the software is being used in sensitive domains. It expects to provide some claim from the authors of the framework or technology. I was just asking community if they can show me a direction to make the assumptions facts.

    Anyway thanks for your time and help here I really appreciate it smile.

    Tuesday, August 4, 2020 10:22 PM
  • User1535942433 posted

    Hi nithin.bandaru1,

    As far as I think,there are changes from .NET Framework 4.6.2 to 4.8 when runtime.

    ASP.NET

    1.ASP.NET Fix handling of InputAttributes and LabelAttributes for WebForms CheckBox control

    2.ASP.NET Incorrect multipart handling may result in lost form data.

    3.ASP.NET ValidationContext.MemberName is not NULL when using custom DataAnnotations.ValidationAttribute

    Core

    1..NET COM successfully marshals ByRef SafeArray parameters on events

    2..NET Interop will now QueryInterface for IAgileObject (a WinRT interface)

    3.Allow Unicode in URIs that resemble UNC shares

    4.Support special relative URI notation when Unicode is present

    Runtime

    1.Improved WCF chain trust certificate validation for Net.Tcp certificate authentication

    2.RSACng and DSACng are once again usable in Partial Trust scenarios

    More details,you could refer to below article:

    https://docs.microsoft.com/en-us/dotnet/framework/migration-guide/runtime/4.6.2-4.8

    Best regards,

    Yijing Sun

    Wednesday, August 5, 2020 7:54 AM