Share via


msbuild failing to to find task (or to load assembly containing task)

Question

Monday, April 11, 2011 10:19 PM

I have encountered the all-too-familiar "task was not found" error after creating
a simple custom task and trying to get msbuild (invoked via Visual Studio 2010) to
execute that task after adding the appropriate target to my .csproj file.

Searching the web has not proved to be fruitful.

Here are the details.  I have a solution with two projects in it:  a C# class
library project which defines my custom task and a console application that
references the library project.  Both projects are targeting .NET Frameowrk 4.0.
I am running visual Studio 2010 (with Service Pack 1 installed) on Windows Server
2008 R2.  The purpose of the console app project is not to really produce a console
app, but rather to invoke the custom build task in order to apply xslt transformations
to some xml files.

At the top of the .csproj file for my console app, I have the following:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="Default" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <UsingTask AssemblyFile="C:\projectsExperiment02\LowLevelTransform\ApplyTransform\bin\Debug\LowLevelTransform.dll" TaskName="ModifyConfigFiles.MyTask" />
  <Target Name="Default">
    <MyTask SourceXmlFile="C:\projectsExperiment02\LowLevelTransform\ApplyTransform\input.xml" XsltFile="C:\projectsExperiment02\LowLevelTransform\ApplyTransform\transform.xslt" TargetXmlFile="C:\projectsExperiment02\LowLevelTransform\ApplyTransform\bin\Debug\output.xml" />
  </Target>

Note that I specify the namespace as well as the class name of the custom task in the
TaskName attribute of the UsingTask element.

From the following code snippet, you can see that the custom task has the appropriate
using statements and inherits from the Task class:

using System;
using System.IO;
using System.Xml;
using System.Xml.Xsl;
using Microsoft.Build.Framework;
using Microsoft.Build.Utilities;

namespace ModifyConfigFiles
{
    public class MyTask : Task
    {
  ....

In both the console app project and in the class library project, I added references to the following assemblies:

 Microsoft.Build.Framework
 Microsoft.Build.Utilities.v4.0

I should also mention that I looked at the Project Properties on both projects and have set the platform target
to "x86".   Perhaps the 64-bit verson of msbuild is getting invoked inadvertently?

I'm getting an error at build time:

Target "Default: (TargetId:68)" in project "C:\projectsExperiment02\LowLevelTransform\ApplyTransform\ApplyTransform.csproj" (entry point):
C:\projectsExperiment02\LowLevelTransform\ApplyTransform\ApplyTransform.csproj(5,5): error MSB4036: The "MyTask" task was not found.
Check the following:
1.) The name of the task in the project file is the same as the name of the task class.
2.) The task class is "public" and implements the Microsoft.Build.Framework.ITask interface.
3.) The task is correctly declared with <UsingTask> in the project file, or in the *.tasks files located in the "C:\Windows\Microsoft.NET\Framework\v4.0.30319" directory.
Done building target "Default" in project "ApplyTransform.csproj" -- FAILED.: (TargetId:68)

If I unload the project file for the console app, make some trivial edits, save it, reload it, and re-compile, I get a slightly
different error from the one shown above.

C:\projectsExperiment02\LowLevelTransform\ApplyTransform\ApplyTransform.csproj(5,5): error MSB4062: The "MyTask" task could not
be loaded from the assembly C:\projectsExperiment02\LowLevelTransform\ApplyTransform\bin\Debug\LowLevelTransform.dll.
Could not load file or assembly 'file:///C:\projectsExperiment02\LowLevelTransform\ApplyTransform\bin\Debug\LowLevelTransform.dll'
or one of its dependencies. The system cannot find the file specified. Confirm that the <UsingTask> declaration is correct,
that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.

But all subsequent attempts to build produce the error shown earlier.

Also note:  I manually copied the class library dll, LowLevelTransform.dll into the ApplyTransform\bin\Debug folder,
just in case msbuild was encountering some permissions problem trying to reach into the sibling project's bin\Debug folder.
In other words, AssemblyFile was initially set to:
  C:\projectsExperiment02\LowLevelTransform\LowLevelTransform\bin\Debug\LowLevelTransform.dll
but after copying over the dll, I changed it to:
  C:\projectsExperiment02\LowLevelTransform\ApplyTransform\bin\Debug\LowLevelTransform.dll

But making that change didn't help.

I tried running fuslog.exe (as administrator) from the following folder:
 C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\NETFX 4.0 Tools
I enabled logging of bind failures, but did not see anything being logged after trying
to build the console app (and yes I pressed the refresh button in fusion log viewer
afterwards).  Perhaps the fusion logger doesn't log assembly loads performed via
reflection (I've read that reflection is used to load the assembly containing the custom build task, but am not sure if that's correct).

I'm running out of ideas on how to pursue this and would greatly appreciate some help.

A second question I'd like to ask:
In the Visual Studio Tools -> Options dialog, under "Projects and Solutions" -> "Build and Run", I
set both <MSBuild project build output verbosity> and <MSBuild project build log file verbosity> to "Diagnostic". 
Can someone tell me where the build log file is located?

Mike

 

 

 

All replies (6)

Tuesday, April 12, 2011 6:01 AM âś…Answered

Hi Mike,

 

Thanks for your post.

Based on your description, I cannot find anything abnormal.

But as you mentioned, the best approach is to check your log file.

You can build your project file in command line with switch /fl

http://msdn.microsoft.com/en-us/library/ms164311.aspx

and a file named msbuild.log will be generated in the current working directory.

Ziwei Chen [MSFT]
MSDN Community Support | Feedback to us
Get or Request Code Sample from Microsoft
Please remember to mark the replies as answers if they help and unmark them if they provide no help.


Tuesday, April 12, 2011 2:42 PM

Ziwei,

The problem has gone away.  This is speculation, but it appears that some process (perhaps unrelated to Visual Studio or msbuild) might have had a lingering lock on the assembly, and the lock was preventing msbuild from accessing the assembly containing the custom task.  Today, I restarted Visual Studio and then I first tried running msbuild from the command line.  That worked without any problems.   Then I tried building my solution from within Visual Studio and that worked as well.

Thanks for your response.

Mike


Tuesday, April 12, 2011 3:57 PM

I can reproduce this behaviour by by running the debugger in VisualStudio to debug my custom Task code, by running msbuild as an external program in the debug settings.

What happens is that my custom task dll gets locked by VisualStudio and I have to quit and restart VisualStudio to continue working on it.


Tuesday, April 12, 2011 4:12 PM

Do you have to run msbuild as an external program in order to debug the custom task?

Anyway, good to know, Antek.   Thanks for passing on the info.

Mike

 


Tuesday, April 12, 2011 5:21 PM

Just like Antek reported, I am running into the locked assembly problem repeatedly and each time I have to exit and restart Visual Studio to get past the problem.   In other words, the first solution build works fine, but any subsequent builds fail because the dll that gets copied to the bin\debug folder under the console app's project directory is still locked.

Hopefully Microsoft will fix this in their next release.  It's quite annoying.

Mike

 


Wednesday, April 13, 2011 12:17 PM

This blog entry has the details on custom task code debugging: http://blogs.msdn.com/b/msbuild/archive/2005/09/28/474951.aspx

And here is another one on MSBuild script debugging: http://blogs.msdn.com/b/visualstudio/archive/2010/07/06/debugging-msbuild-script-with-visual-studio.aspx?wa=wsignin1.0