This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.

Topics: General Questions
Jul 13, 2013 at 12:21 PM

I'm working on a deployment for a BizTalk 2013 application. I'm developing on a Windows 2012 machine.
When I try to deploy my solution, the DeployComponents target fails with the error 'This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.'. As you can see below, the 2.0 gacutil is being used here whereas all my assemblies are built for .NET 4.0. The task GetFrameworkPath apparently comes up with 2.0 instead of 4.0. Where is the code for the GetFrameworkPath task located, I couldn't find it in the DeploymentFramework.BuildTasks source code. I did install the latest version of the BTDF.
Any tips on why the wrong .NET Framework version is being used?

Using .NET Framework Install Path 'C:\Windows\Microsoft.NET\Framework\v2.0.50727'.

Target DeployComponents:
            Deploying components to GAC...
            "D:\BizTalkApplications\ESB\1.0\Deployment\Framework\DeployTools\gacutil.exe" /i "..\ESB.Utilities.dll"
            Microsoft (R) .NET Global Assembly Cache Utility.  Version 2.0.50727.42
            Copyright (c) Microsoft Corporation.  All rights reserved.

            Failure adding assembly to the cache:   This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.
Nils Gruson
Jul 15, 2013 at 5:12 AM
Hi Nils,

When you say "the latest version", do you mean the v5.1 beta? If not, that is the only supported path for BizTalk 2013. The correct version of GacUtil.exe is installed during the Deployment Framework installation when it detects which version of BizTalk is installed on the machine. I'm assuming that you installed the Deployment Framework after installing BizTalk 2013? Another possibility -- are you just building this all locally, or on a build server? Sometimes people upgrade BTDF on the developer side but forget to upgrade the build server.

Jul 15, 2013 at 7:37 AM
Hi Tom,

I wasn't aware there was a 5.1 version. I installed it and I got it working ok now. I'm building and deploying on my dev environment.
One note: after installation of 5.1 I had to alter the registry in order to be able to make a build.
I needed to copy the values from HKEY_LOCAL_MACHINE/SOFTWARE/Wow6432Node/DeploymentFrameworkForBizTalk to
HKEY_LOCAL_MACHINE/SOFTWARE/DeploymentFrameworkForBizTalk. I've seen this earlier with version 5.0 though.
Since it's a 64-bit server, the registry values end up in the Wow6432node registry key. Apparently the framework isn't aware (enough) that the server where the build is being made is 64-bit? Minor issue imo, I can live with the workaround ;).

Jul 16, 2013 at 5:20 AM
Hi Nils,

What are you using to drive the build? Visual Studio is a 32-bit app, and the Deployment Framework is designed to run with the 32-bit version of MSBuild. Likewise, the Deployment Framework installer is 32-bit. However you are running the build, you should be calling the 32-bit version of MSBuild.

Jul 16, 2013 at 10:05 AM
I execute the batchfile BuildDebugMsi or BuildReleaseMsi to make builds. The problem was that I added the Framework64 folder to the PATH environment variable, so the 64-bit MSBuild was being used instead of the 32-bit MSBuild. I solved that now.