Copy local that BizTalk 2009 reference

I’m sure by now everyone has met the evil ‘copy local’ problem in BizTalk.  It’s blogged by Jan here and by Ryan as well. Often, you want to add your schema project as a reference to the map or orchestration project. Things might look allright at first, but then after some changes, you get build errors. Once you know what it is, it’s easy to solve, just put that ‘copy local’ setting on your reference to false, then directly back to true. Magically (?) it all works again.

It’s one of the issues that gets attributed to BizTalk 2009, but I just reproduced this in a C# project trying to reference a BizTalk project. What exactly happens? It did all work in 2005!

In fact, Visual Studio is fooling us all. The csproj and btproj files don’t actually have that copy local at all! For a copy local referenc, The project file should contain something like this:

<ProjectReference Include="..Mysolution.SchemasMysolution.Schemas.btproj">

However the part <Private>True</Private> is missing. So the compiler does not copy the dll locally.

Why this strange behaviour? I found an explanation in the MSDN:

At run time, components must be either in the output path of the project or in the Global Assembly Cache (GAC). If the project contains a reference to an object that is not in one of these locations, you must copy the reference to the output path of the project when you build the project. The CopyLocal property indicates whether this copy has to be made. If the value is True, the reference is copied to the project directory when you build the project. If the value is False, the reference is not copied.

If you deploy an application that contains a reference to a custom component that is registered in the GAC, the component will not be deployed with the application, regardless of the CopyLocal setting. In earlier versions of Visual Studio, you could set the CopyLocal property on a reference to ensure that the assembly was deployed. Now, you must manually add the assembly to the Bin folder. This puts all custom code under scrutiny, reducing the risk of publishing custom code with which you are not familiar.

By default, the CopyLocal property is set to False if the assembly or component is in the global assembly cache or is a framework component. Otherwise, the value is set to True. Project-to-project references are always set to True.

Since BizTalk assemblies are always deployed to the GAC, te fact if your copy local contains the right private setting depends on if your project was deployed before you added the reference. Even though you still seem to have copy local set right!

An unhappy side effect of this is that the orchestration / mapping is compiled against the schema that is in the GAC and not the one that is in your project. Leaving you to guess why that change you made did not compute at build time.

I also remember having some other problems with assemblies in the GAC referred in Visual Studio. Perhaps this is all related. I hope this issue is gets addressed in the next release!


  1. September 3, 2009    

    This very good idea to have just by the way

  2. Pim's Gravatar Pim
    January 25, 2010    

    Thanks Patrick.. So there’s a hotfix now.

  3. Ritesh's Gravatar Ritesh
    October 22, 2010    

    This is really frustrating and above trick – CopyLoca True/False doesnt work. The problem is my schema proj doesn’t compile even after releasing its ref from Map and Orch projects. Here is the error : Unable to copy file “objDebugMySchemas.dll” to “binDebugMySchemas.dll”. The process cannot access the file ‘binDebugMySchemas.dll’ because it is being used by another process.
    I have VS2008 with BT2009. Any suggestion to solve this?

  4. Ritesh's Gravatar Ritesh
    October 25, 2010
    This hot-fix did not solve this problem. Does anyone aware of any solution from Microsoft on this?

  5. Pim's Gravatar Pim
    October 26, 2010    

    Ritesh, these issues happen sometimes when a designer is open in visual studio, which is keeping your dll’s in use. If you close all documents in visual studio, then save the solution; close visual studio and open again, you should be able to build again.

No Pings Yet

  1. Hotfix for BizTalk 2009 and Visual Studio 2008 issues released « Connected Thoughts – Thiago Almeida on January 25, 2010 at 2:43 am
  2. João Pedro "jota" Martins : Visual Studio 2010 and BizTalk 2010 File Locking Problems on May 27, 2011 at 12:03 pm
  3. Visual Studio 2010 and BizTalk 2010 File Locking Problems | jotablog1 on September 23, 2013 at 8:40 pm
  4. Visual Studio 2010 and BizTalk 2010 File Locking Problems | Blog IT on September 16, 2014 at 1:27 pm

Leave a Reply