views:

80

answers:

2

I'm developing a custom MSBuild task that builds an ORM layer, and using it in a project. I'm being hampered by Visual Studio's behaviour of holding onto MSBuild task DLLs and not letting go.

I'd like to organize my solution like this;

My Solution
 |
 +- (1) ORM Layer Custom Task Project
 |  |
 |  +- BuildOrmLayerTask.cs     // here's my task
 |  
 +- (2) Business Logic Project  // and here's the project that uses it.
    |
    +- <UsingTask TaskName="BuildOrmLayerTask" AssemblyFile="$(TaskAssembly)" />

However, when project (2) builds, it locks onto the assembly from project (1). So now I can't build project (1) again without closing the solution and re-opening it.

Is there any way I can organize things so that the custom build task is not kept locked by Visual Studio?

+2  A: 

Can you edit the project files and include the following property declaration

<PropertyGroup>
    <GenerateResourceNeverLockTypeAssemblies>true</GenerateResourceNeverLockTypeAssemblies>
</PropertyGroup>

Let me know if that works for you.

Sayed Ibrahim Hashimi
I added this to all my projects and it now works perfectly. Thanks!
Steve Cooper
Actually, when I started working with it, it locked up again. I have found the solution, though; see my answer. It seems that VS loads the custom tasks into the primary app domain, and that can never be unloaded, so all you can do is start a new MSBuild.exe process using Exec.
Steve Cooper
If its a custom task you can extend Microsoft.Build.Utilities.AppDomainIsolatedTask to help you with that.
Sayed Ibrahim Hashimi
+4  A: 

I've managed to solve this one myself...

Found this forum post from Dan Moseley, one of the MSBuild developers from Microsoft:

Hi there,

Unfortunately this is because MSBuild loads task assemblies in the primary appdomain. The CLR does not allow assemblies to unload from an appdomain as this allows important optimizations on their part.

The only workarounds I suggest is to call out tomsbuild.exe to build the projects that use the task. To do this, create MSBuild.exe <> as an external tool in VS.

Dan
developer on msbuild
DanMoseley - MSFT

So, it seems that to stop the locks, you must spawn out a new MSBuild.exe process. It can't be the one that runs inside Visual Studio, because when MSBuild runs, it loads the tasks into Visual Studio's primary app domain, and that can never be unloaded.

  • create a new MSBuild project (a .csproj or similar) which overrides the 'Build' Target and performs your custom actions, eg;

    <!-- fragment of Prebuild.csproj -->   
    <Target Name="Build">   
         <BuildOrmLayerTask Repository="$(Repository)" />   
    </Target>
    
  • Add it to visual studio if you want, but use Configuration Manager to make sure it is *not*built in any configuration. Just let VS take care of source control and suchlike, not building.

  • Edit the .csproj file of the project that depends on Prebuild.csproj. Add a BeforeBuild target which invokes MSBuild using the Exec task. This will start a new process, and when that process ends, the file locks are released. Example;

    <PropertyGroup>   
         <PrebuildProject>$(SolutionDir)Prebuild\Prebuild.csproj</PrebuildProject>   
    </PropertyGroup>   
    <Target Name="BeforeBuild">   
         <Exec Command="msbuild.exe &quot;$(PrebuildProject)&quot;" />   
    </Target>
    

Now, when you build the dependent project, it executes MSBuild in a new process before running the compile.

Steve Cooper