Visual Studio 2008 locks custom MSBuild Task assemblies

Question

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?

score 26 · Accepted Answer · edited Jun 09 '19 at 04:08

(Edit: Sayed Ibrahim Hashimi, who literally wrote the book on msbuild, suggests the AppDomainIsolatedTask class for a better approach)

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 notbuilt 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.

Launching another msbuild.exe process seems to be the only solution that works. I don't see how extending AppDomainIsolatedTask is supposed to work in this situation, since MSBuild has already loaded the assembly in the primary AppDomain by the time it tries to read the types. There needs to be a way in the project file itself to tell MSBuild to load the task in another AppDomain. Microsoft refuses to fix this major problem because of performance hits with using new AppDomains - well let us override an option and decide for ourselves? Why is this such a hard issue for MS "engineers" to fix? — makhdumi, Feb 06 '14 at 19:04
You don't have to create a separate MSBuild project. You can simply put a condition on your the target and make the `BeforeBuild` target execute the current project with some parameters, e.g. `` and ``. — user247702, Jan 27 '16 at 16:21

score 4 · Answer 2 · answered Aug 04 '10 at 06:53

4

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.

answered Aug 04 '10 at 06:53

Sayed Ibrahim Hashimi

43,864
17
144
178

I added this to all my projects and it now works perfectly. Thanks! – Steve Cooper Aug 04 '10 at 10:45
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 Aug 04 '10 at 13:26
8

If its a custom task you can extend Microsoft.Build.Utilities.AppDomainIsolatedTask to help you with that. – Sayed Ibrahim Hashimi Aug 04 '10 at 16:20
I tried this, restarted my Visual Studio and it worked until I choose "Deploy". If you deploy a .dll MSBuild lock the custom task anyway – Raffaeu Jan 06 '12 at 16:19
3

@SayedIbrahimHashimi Can you please explain how extending AppDomainIsolatedTask is supposed to work in this situation? I can see how it'd work when assemblies you load *in* your custom task are getting locked, but how would this work for the assembly MSBuild itself loads? Doesn't MSBuild need to load the assembly before it can see that it has AppDomainIsolatedTasks in it? Why wasn't a similar option provided with the UsingTask element? – makhdumi Feb 06 '14 at 19:11
@Al-Muhandis From a late-night rummage through the various build engine DLLs with ildasm, I'd say you're quite correct. The assembly load literally uses `Assembly.Load` or `Assembly.LoadFrom`, depending whether you specified the AssemblyName or AssemblyFile, respectively, in UsingTask. Any task that inherits from `MarshalByRefObject` appears to get loaded into a newly-created AppDomain before running, but the discovery happened by loading the assembly into the default app domain. I'm exploring writing a wrapper task to help, but... not tonight. – Andrew Jul 06 '14 at 07:37

score 3 · Answer 3 · answered Jul 10 '14 at 19:10

As I mentioned in a comment directed at @Al-Muhandis, it seems possible to create a wrapper around the custom task so that the wrapper gets locked but not the custom task DLL. I have taken an initial shot at doing so with the isolated-task project. It may be buggy, and it only works with VS2008 for now. Pull requests welcome.

The idea for the project was based on the observation that tasks deriving from MarshalByRefObject (using, perhaps, AppDomainIsolatedTask) appear to be loaded into the main application domain for reflection purposes, but a new application domain is created to execute the task. Since loading into the main application domain still seems to lock the DLL, it was useful to create a DLL with a task derived from AppDomainIsolatedTask that loads the custom task DLLs. That way, the wrapper DLL gets locked, but because it executes in its own app domain, the custom task DLLs are unloaded when the wrapper task's executing domain is unloaded. This procedure avoids keeping a lock on the custom task DLLs after the build is complete.

Visual Studio 2008 locks custom MSBuild Task assemblies

3 Answers3

Linked