MSBuild: Path used for inline task reference is not honored - by CoolDadTx

Status : 

  By Design<br /><br />
		The product team believes this item works according to its intended design.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


3
0
Sign in
to vote
ID 768289 Comments
Status Closed Workarounds
Type Bug Repros 2
Opened 10/22/2012 10:54:52 AM
Access Restriction Public

Description

The documentation for the Reference element applied to an inline MSBuild task says the Include attribute is the path to an assembly to be referenced.  This is not working as expected.

During compilation the path is used so the task will compile.  But when the task attempts to run it will fail to load the referenced assembly.

The defacto example that several people have posted online about is using the TransformConfig task from $(VSToolsPath)\Web\Microsoft.Web.Publishing.Tasks.dll.  Specifying this as the Include of a reference gets around the compiler but when the task is loaded only the GAC is searched.
Sign in to post a comment.
Posted by CoolDadTx on 10/31/2012 at 7:12 AM
This is not resolved. This has nothing to do with TransformXml, TransformConfig or anything else. The underlying problem that I pointed out is that there is no way to get MSBuild to load an assembly outside of the standard assembly paths. If you run the task that I provided and you look at the fusion log you'll see that the assembly (Publishing.Tasks.dll) cannot be loaded by the CLR because it is only searching the standard assembly paths. It has already been mentioned by others (see here:
http://stackoverflow.com/questions/9455354/msbuild-inline-task-reference-non-standard-microsoft-assemblies).


In order for the Reference element of an inline task to truly support path-based assembly references the path needs to somehow get added to the search path for assemblies during loading. Otherwise it is a false positive for non-GAC assemblies because it will fail when the task executes.

My workaround was to explicitly load the assembly and use dynamic to work with it. Alternatively I could have hooked into the assembly resolve event and load it using the correct path but that was more code than dynamic.
Posted by Microsoft on 10/30/2012 at 3:20 PM
Thank you for your feedback. After reviewing the issue we believe that you should be using TransformXml instead of TransformConfig.

The below two topics contain more info:
MSBuild Inline Tasks : http://msdn.microsoft.com/en-us/library/dd722601.aspx

How to use TransformXml task: http://sedodream.com/2010/04/26/ConfigTransformationsOutsideOfWebAppBuilds.aspx
Posted by Microsoft on 10/23/2012 at 2:08 AM
Thank you for submitting feedback on Visual Studio and .NET Framework. Your issue has been routed to the appropriate VS development team for investigation. We will contact you if we require any additional information.
Posted by Microsoft on 10/22/2012 at 11:51 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)