Mixed mode assembly is built against version ‘v2.0.50727’ of the runtime and cannot be loaded in the 4.0 runtime without additional configuration information.

One of the release management customer reported that while running a PS/DSC deployment script, the release management release is failing with following error:

Mixed mode assembly is built against version 'v2.0.50727' of the runtime and cannot be loaded in the 4.0 runtime without additional configuration information.

Praneeth Yenugutala from the team investigated this and observed that it occurs because the support for side-by-side runtime from .NET 4.0 onwards has changed w.r.t. the way with which .NET assembly binds to older mixed-mode assemblies (example: - assemblies compiled from C++\CLI, directX assemblies etc). Since the process which carries the PS/DSC deployment in release management is built against .NET framework 4.5 older .NET mixed-mode binaries fail to load in our deployment context.

To get past this error till the actual fix is done in the product, you should not load such mixed-mode dll’s directly in the .ps1 script. You should launch a new process in .ps1 and load them in that context. Having this configuration block in the assembly’s app.config file(which is launched as a new process) should work:

<startup useLegacyV2RuntimeActivationPolicy="true">


Please try this out and do let us know in case it still does not work for you.

Enjoy !!

Comments (12)

  1. Jesper says:

    I just ran into this using vNext release templates and calling "Invoke-Sqlcmd" in my powershell script. My work around is to call sqlcmd.exe from the script instead. Even though i found a workaround the issue is really annoying…

    Is there a fix coming? When? Is it reported as a bug on Connect so I can follow up on the progress there?


  2. Thanks Jesper for your comment, I will try out whether the issue is fixed in the latest code of RM and will keep you posted about my findings.


    Aseem Bansal

  3. Thanks Jesper, We have fixed this issue in the latest code and the fix should be available in the next release of RM.


    Aseem Bansal

  4. Aseem,

    while waiting for you next release, is there any workaround?

    I dont wanna just run my SQL code with sqlcmd.exe because my error handling wont work anymore. Is there a way i can use Invoke-SqlCmd using a vNext release template without having the 2.0 vs 4.0 issue?

    I'm on RM2013.Update4

  5. Praneeth Yenugutala says:

    Hi Dominic,

    Can you try wrapping the Invoke-SqlCmd in this fashion in the PS script?

    $job = Start-Job -ScriptBlock {Invoke-SqlCmd -argument ……}

    Wait-Job -Job $job | Out-Null

    Write-Verbose (Receive-Job $job) -Verbose

    if ($job.State -eq 'Failed') {

           throw $job.ChildJobs[0].JobStateInfo.Reason.Message


    In the above script if the $job.ChildJobs[0].JobStateInfo.Reason.Message does not contain anything in case of error you can also try: "throw $job.ChildJobs[0].Error"

  6. Kevin DPath says:

    When you say "the fix should be available in the next release of RM", do you mean 2015 RC? I just installed a local copy of TFS and Release Management 2015 RC and I am still getting the error.

    I am just doing a simple "Import-Module failoverclusters".

  7. Ashwini Rattihalli says:

    Kevin, this is not fixed in RC, it will be fixed in RTM.

  8. Georg Winkelhofer says:

    I've installed the Visual Studio 2015 RTM and get the same error 🙁

    Even using the Startup tag in my app.config doesn't help.

  9. Chaitanya Shrikhande says:

    Georg , could you please confirm that with your RM server setup 'VisualStudioRemoteDeployer.exe.config' file is present . If you have used the default installation location you can find it at – "C:Program Files (x86)Microsoft Visual Studio 14.0Release ManagementbinVisualStudioRemoteDeployer.exe.config"

  10. Simon Burgess says:

    I use RM to deploy SSIS so I use DSC to invoke a ps1 script that loads Microsoft.SqlServer.Management.Integration.Services. I was getting this mixed mode error until I wrapped the call to my ps1 script in a job as recommended in the comments here. I did iit like this (the crucial thing I found to surface the verbose output of my ps1 script was setting the $VerbosePreference flag:

    $job = Start-Job -ScriptBlock {


       $VerbosePreference = 'continue'

       pushd $ps1actions_dir

       & .DeploySSIS.ps1 -ssisManifestFile $manifestfullpath -ispacFolder $ispacfolder -deployConnectionString $connstring -envID $env | Write-Verbose


    } -ArgumentList $ps1actions_dir, $using:manifest, $using:ApplicationPath, $connectionString, $using:Environment

  11. SheldonS says:

    I just ran into this last week, and still have it as an issue.  It only appears when I run my tests in Visual Studio 2015.  I can edit and do a build and things seem to work fine.  My tests run fine in Visual Studio 2013.

    I have posted the question in a few forms and have done quite a few searches.  Everything seems to lean towards editing config files, which were already in place.

    Any suggestions?

  12. Praneeth Yenugutala says:

    Hi Sheldon,

    Are you trying to run tests using ReleaseManagement? Or is it directly using the VIsualStudio IDE?

Skip to main content