clariuslabs / TransformOnBuild

Transform Text Templates On Build
Apache License 2.0
48 stars 17 forks source link

Visual Studio 15.8.3 - Could not load file or assembly Clarius.TransformOnBuild.MSBuild.Task.dll #53

Closed 3breadt closed 5 years ago

3breadt commented 5 years ago

Since updating to Visual Studio 15.8.3 I can no longer build projects using Clarius.TransformOnBuild in Visual Studio.

This is the Build Output:

1>CopyTaskAssemblyToTempFolder: 1> Creating directory "C:\Users\MyUserName\AppData\Local\Temp\29c1cdd1-49b5-413d-a473-04f96c0be9bb". 1> Copying file from "C:\\MyProject\packages\Clarius.TransformOnBuild.1.21.0\build\Clarius.TransformOnBuild.MSBuild.Task.dll" to "C:\Users\MyUserName\AppData\Local\Temp\29c1cdd1-49b5-413d-a473-04f96c0be9bb\Clarius.TransformOnBuild.MSBuild.Task.dll". 1>_CopyFilesMarkedCopyLocal: 1> Touching "C:\\MyProject\MyProject\obj\Debug\MyProject.csproj.CopyComplete". 1>C:\\MyProject\packages\Clarius.TransformOnBuild.1.21.0\build\Clarius.TransformOnBuild.targets(43,5): error MSB4062: The "Clarius.TransformOnBuild.MSBuild.Task.TransformOnBuildTask" task could not be loaded from the assembly C:\Users\MyUserName\AppData\Local\Temp\3380110d-bf98-4c4f-b30c-663cadce97f1\Clarius.TransformOnBuild.MSBuild.Task.dll. Could not load file or assembly 'file:///C:\Users\MyUserName\AppData\Local\Temp\3380110d-bf98-4c4f-b30c-663cadce97f1\Clarius.TransformOnBuild.MSBuild.Task.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.

christopherstamm commented 5 years ago

Same here.

Its a problem in "\packages\Clarius.TransformOnBuild.1.21.1\build\Clarius.TransformOnBuild.targets" The copyTask uses different Folder than execution. Maybe generation of tempfolder is called twice.

For my fix see attached File (must remove .txt) Clarius.TransformOnBuild.targets.txt

HowardvanRooijen commented 5 years ago

Also hit by this yesterday.

Quarkonaut commented 5 years ago

We ran into this issue as well. The proposed .targets file from @ChristopherStamm works for us. Is there a good reason that the original .targets file is copies the library to a temporary directory?

HowardvanRooijen commented 5 years ago

That fix works locally, but not on a build server :(

andersforsgren commented 5 years ago

The msbuild system used to evaluate the temp dir (using the random guid) only once, so it ran the dll from the same folder it was deployed to. This stopped working somewhere in 15.8.X while it was fine in 15.7.X. I have reported it as a bug in VS but it would be nice if the temp path deployment could be turned off so this bug could be worked around. Perhaps a short term solution would be to switch it off entirely in TransformOnBuild and take back the old behavior - including any occassional locking issues or whatever it was that drove the adoption of the temp path? In any case it's now unusable in the latest VS it seems, so anything would be better.

Here is the VS problem report, you can always vote for it to bring attention to it: https://developercommunity.visualstudio.com/content/problem/348806/msbuild-properties-evaluated-more-than-once.html

Interestingly, the ReSharper build system has had the same bug for ages- forcing us to stop using that and using vanilla msbuild in order to use TransformOnBuild: https://youtrack.jetbrains.com/issue/RSRP-468134

Perhaps it's the case that propertries should or can be evaluated per target? Or that it's not part of the spec at all so it's up to the implementation? In that case the idea of using a guid path is broken.

rsheptolut commented 5 years ago

@mnaoumov @andersforsgren I'm also experiencing the problem and it seems that 5 days ago a VS dev replied that this is not a bug, but can be fixed as part of a change in TransformOnBuild. I'm not qualified in MSBuild enough to prepare a pull request with a fix. Do maybe you know what he's talking about and whether it's a simple change?

mnaoumov commented 5 years ago

@rsheptolut I'll take a look today

andersforsgren commented 5 years ago

Perhaps it's possible to use something other than a random guid that is still fixed between invocations, such as a ThreadID/ProcessID or similar?

rsheptolut commented 5 years ago

Thanks, works like a charm again!