Which MSBuild target copies the .dll from a project reference?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
I'm trying to develop a custom MSBuild task and test it by invoking it from another project in the same solution. Originally I set up UsingTask in the test project to reference the .dll in the task project:
<UsingTask TaskName="FooTask" AssemblyFile="..Taskbin$(Configuration)Task.dll"/>
<Target Name="RunFooTask" BeforeTargets="Compile">
<FooTask/>
</Target>
This mostly works. But frequently and seemingly at random, building the test project leaves the task project .dll locked by MSBuild and/or Visual Studio, which requires killing the rogue MSBuild process and restarting Visual Studio. This sounds similar to Visual Studio 2008 locks custom MSBuild Task assemblies and Visual Studio 2008 locks dll in bin folder and doesn't let go of it. But my task is already an AppDomainIsolatedTask and I've tried setting GenerateResourceNeverLockTypeAssemblies. This does not solve the problem.
So I tried adding a project reference from the test project to the target project, thinking it would copy the .dll into the test project and UsingTask could find it there:
<UsingTask TaskName="FooTask" AssemblyFile="$(OutputPath)Task.dll" />
This seems to solve the problem with the .dll being left locked. The problem now is that the .dll has not been copied yet when the task is invoked. If I understand correctly, BeforeTargets="Compile" means any time before compile, not necessarily immediately before compile. So I think I need to also specify AfterTargets with whatever target copies the .dll from the referenced project. What target would that be?
Incidentally, I also tried changing BeforeTargets="Compile" to BeforeTargets="Build". Now the .dll is copied before the task runs, but that's because it runs after the build! I boiled this down to a test target that doesn't involve UsingTask at all:
<Target Name="Hello" BeforeTargets="Build">
<Message Importance="high" Text="Hello" />
</Target>
Output:
1>------ Rebuild All started: Project: Test, Configuration: Debug Any CPU ------
1> Test -> C:[redacted]MSBuildTest2TestbinDebugTest.exe
1> Hello
This makes me doubt everything I thought I knew about what's going on.
msbuild
asked Nov 26 '18 at 19:24
TKKTKK
335211
|
show 2 more comments
I'm trying to develop a custom MSBuild task and test it by invoking it from another project in the same solution. Originally I set up UsingTask in the test project to reference the .dll in the task project:
<UsingTask TaskName="FooTask" AssemblyFile="..Taskbin$(Configuration)Task.dll"/>
<Target Name="RunFooTask" BeforeTargets="Compile">
<FooTask/>
</Target>
This mostly works. But frequently and seemingly at random, building the test project leaves the task project .dll locked by MSBuild and/or Visual Studio, which requires killing the rogue MSBuild process and restarting Visual Studio. This sounds similar to Visual Studio 2008 locks custom MSBuild Task assemblies and Visual Studio 2008 locks dll in bin folder and doesn't let go of it. But my task is already an AppDomainIsolatedTask and I've tried setting GenerateResourceNeverLockTypeAssemblies. This does not solve the problem.
So I tried adding a project reference from the test project to the target project, thinking it would copy the .dll into the test project and UsingTask could find it there:
<UsingTask TaskName="FooTask" AssemblyFile="$(OutputPath)Task.dll" />
This seems to solve the problem with the .dll being left locked. The problem now is that the .dll has not been copied yet when the task is invoked. If I understand correctly, BeforeTargets="Compile" means any time before compile, not necessarily immediately before compile. So I think I need to also specify AfterTargets with whatever target copies the .dll from the referenced project. What target would that be?
Incidentally, I also tried changing BeforeTargets="Compile" to BeforeTargets="Build". Now the .dll is copied before the task runs, but that's because it runs after the build! I boiled this down to a test target that doesn't involve UsingTask at all:
<Target Name="Hello" BeforeTargets="Build">
<Message Importance="high" Text="Hello" />
</Target>
Output:
1>------ Rebuild All started: Project: Test, Configuration: Debug Any CPU ------
1> Test -> C:[redacted]MSBuildTest2TestbinDebugTest.exe
1> Hello
This makes me doubt everything I thought I knew about what's going on.
msbuild
asked Nov 26 '18 at 19:24
TKKTKK
335211
Do you need to run before compile? Usually you'd develop these tasks in a way that doesn't require referencing them from VS because of this reason.
– Martin Ullrich
Nov 26 '18 at 22:56
@MartinUllrich It's a code generator, so yes.
– TKK
Nov 27 '18 at 0:07
If you don't want it to lock VS, I suggest splitting the solutions and trying to build a NuGet Package / SDK package containing the task + targets along with integration tests that invoke MSBuild itself, then use the NuGet package in the project you want to use code generation from inside VS. Nevertheless, I suggest importing the file via a direct path since references are copied AFTER compilation
– Martin Ullrich
Nov 27 '18 at 0:11
@MartinUllrich I packaged the task as a NuGet package and installed it in the project that needs to use it. This has the same effect as a project reference: the .dll does not exist in$(OutputDir)until after the build. In other build systems it would be a compile scope dependency, but MSBuild apparently has no concept of that. I also expectedUsingTaskto be able to useAssemblyNameinstead ofAssemblyFilewhen consuming a NuGet package, but that doesn't work, either. Perhaps I don't understand the correct usage ofAssemblyName.
– TKK
Nov 27 '18 at 0:23
Maybe a MSBuild task is entirely the wrong thing to use for this purpose. I originally wrote my code generator as a console app, but I thought a build task would be less hacky.
– TKK
Nov 27 '18 at 0:27
|
show 2 more comments
I'm trying to develop a custom MSBuild task and test it by invoking it from another project in the same solution. Originally I set up UsingTask in the test project to reference the .dll in the task project:
<UsingTask TaskName="FooTask" AssemblyFile="..Taskbin$(Configuration)Task.dll"/>
<Target Name="RunFooTask" BeforeTargets="Compile">
<FooTask/>
</Target>
This mostly works. But frequently and seemingly at random, building the test project leaves the task project .dll locked by MSBuild and/or Visual Studio, which requires killing the rogue MSBuild process and restarting Visual Studio. This sounds similar to Visual Studio 2008 locks custom MSBuild Task assemblies and Visual Studio 2008 locks dll in bin folder and doesn't let go of it. But my task is already an AppDomainIsolatedTask and I've tried setting GenerateResourceNeverLockTypeAssemblies. This does not solve the problem.
So I tried adding a project reference from the test project to the target project, thinking it would copy the .dll into the test project and UsingTask could find it there:
<UsingTask TaskName="FooTask" AssemblyFile="$(OutputPath)Task.dll" />
This seems to solve the problem with the .dll being left locked. The problem now is that the .dll has not been copied yet when the task is invoked. If I understand correctly, BeforeTargets="Compile" means any time before compile, not necessarily immediately before compile. So I think I need to also specify AfterTargets with whatever target copies the .dll from the referenced project. What target would that be?
Incidentally, I also tried changing BeforeTargets="Compile" to BeforeTargets="Build". Now the .dll is copied before the task runs, but that's because it runs after the build! I boiled this down to a test target that doesn't involve UsingTask at all:
<Target Name="Hello" BeforeTargets="Build">
<Message Importance="high" Text="Hello" />
</Target>
Output:
1>------ Rebuild All started: Project: Test, Configuration: Debug Any CPU ------
1> Test -> C:[redacted]MSBuildTest2TestbinDebugTest.exe
1> Hello
This makes me doubt everything I thought I knew about what's going on.
msbuild
asked Nov 26 '18 at 19:24
TKKTKK
335211
I'm trying to develop a custom MSBuild task and test it by invoking it from another project in the same solution. Originally I set up UsingTask in the test project to reference the .dll in the task project:
<UsingTask TaskName="FooTask" AssemblyFile="..Taskbin$(Configuration)Task.dll"/>
<Target Name="RunFooTask" BeforeTargets="Compile">
<FooTask/>
</Target>
This mostly works. But frequently and seemingly at random, building the test project leaves the task project .dll locked by MSBuild and/or Visual Studio, which requires killing the rogue MSBuild process and restarting Visual Studio. This sounds similar to Visual Studio 2008 locks custom MSBuild Task assemblies and Visual Studio 2008 locks dll in bin folder and doesn't let go of it. But my task is already an AppDomainIsolatedTask and I've tried setting GenerateResourceNeverLockTypeAssemblies. This does not solve the problem.
So I tried adding a project reference from the test project to the target project, thinking it would copy the .dll into the test project and UsingTask could find it there:
<UsingTask TaskName="FooTask" AssemblyFile="$(OutputPath)Task.dll" />
This seems to solve the problem with the .dll being left locked. The problem now is that the .dll has not been copied yet when the task is invoked. If I understand correctly, BeforeTargets="Compile" means any time before compile, not necessarily immediately before compile. So I think I need to also specify AfterTargets with whatever target copies the .dll from the referenced project. What target would that be?
Incidentally, I also tried changing BeforeTargets="Compile" to BeforeTargets="Build". Now the .dll is copied before the task runs, but that's because it runs after the build! I boiled this down to a test target that doesn't involve UsingTask at all:
<Target Name="Hello" BeforeTargets="Build">
<Message Importance="high" Text="Hello" />
</Target>
Output:
1>------ Rebuild All started: Project: Test, Configuration: Debug Any CPU ------
1> Test -> C:[redacted]MSBuildTest2TestbinDebugTest.exe
1> Hello
This makes me doubt everything I thought I knew about what's going on.
msbuild
msbuild
asked Nov 26 '18 at 19:24
TKKTKK
335211
asked Nov 26 '18 at 19:24
TKKTKK
335211
edited Nov 26 '18 at 19:49
TKK
asked Nov 26 '18 at 19:24
TKKTKK
335211
asked Nov 26 '18 at 19:24
TKKTKK
335211
asked Nov 26 '18 at 19:24
TKKTKK
335211
335211
Do you need to run before compile? Usually you'd develop these tasks in a way that doesn't require referencing them from VS because of this reason.
– Martin Ullrich
Nov 26 '18 at 22:56
@MartinUllrich It's a code generator, so yes.
– TKK
Nov 27 '18 at 0:07
If you don't want it to lock VS, I suggest splitting the solutions and trying to build a NuGet Package / SDK package containing the task + targets along with integration tests that invoke MSBuild itself, then use the NuGet package in the project you want to use code generation from inside VS. Nevertheless, I suggest importing the file via a direct path since references are copied AFTER compilation
– Martin Ullrich
Nov 27 '18 at 0:11
@MartinUllrich I packaged the task as a NuGet package and installed it in the project that needs to use it. This has the same effect as a project reference: the .dll does not exist in$(OutputDir)until after the build. In other build systems it would be a compile scope dependency, but MSBuild apparently has no concept of that. I also expectedUsingTaskto be able to useAssemblyNameinstead ofAssemblyFilewhen consuming a NuGet package, but that doesn't work, either. Perhaps I don't understand the correct usage ofAssemblyName.
– TKK
Nov 27 '18 at 0:23
Maybe a MSBuild task is entirely the wrong thing to use for this purpose. I originally wrote my code generator as a console app, but I thought a build task would be less hacky.
– TKK
Nov 27 '18 at 0:27
|
show 2 more comments
Do you need to run before compile? Usually you'd develop these tasks in a way that doesn't require referencing them from VS because of this reason.
– Martin Ullrich
Nov 26 '18 at 22:56
@MartinUllrich It's a code generator, so yes.
– TKK
Nov 27 '18 at 0:07
If you don't want it to lock VS, I suggest splitting the solutions and trying to build a NuGet Package / SDK package containing the task + targets along with integration tests that invoke MSBuild itself, then use the NuGet package in the project you want to use code generation from inside VS. Nevertheless, I suggest importing the file via a direct path since references are copied AFTER compilation
– Martin Ullrich
Nov 27 '18 at 0:11
@MartinUllrich I packaged the task as a NuGet package and installed it in the project that needs to use it. This has the same effect as a project reference: the .dll does not exist in$(OutputDir)until after the build. In other build systems it would be a compile scope dependency, but MSBuild apparently has no concept of that. I also expectedUsingTaskto be able to useAssemblyNameinstead ofAssemblyFilewhen consuming a NuGet package, but that doesn't work, either. Perhaps I don't understand the correct usage ofAssemblyName.
– TKK
Nov 27 '18 at 0:23
Maybe a MSBuild task is entirely the wrong thing to use for this purpose. I originally wrote my code generator as a console app, but I thought a build task would be less hacky.
– TKK
Nov 27 '18 at 0:27
Do you need to run before compile? Usually you'd develop these tasks in a way that doesn't require referencing them from VS because of this reason.
– Martin Ullrich
Nov 26 '18 at 22:56
Do you need to run before compile? Usually you'd develop these tasks in a way that doesn't require referencing them from VS because of this reason.
– Martin Ullrich
Nov 26 '18 at 22:56
@MartinUllrich It's a code generator, so yes.
– TKK
Nov 27 '18 at 0:07
@MartinUllrich It's a code generator, so yes.
– TKK
Nov 27 '18 at 0:07
If you don't want it to lock VS, I suggest splitting the solutions and trying to build a NuGet Package / SDK package containing the task + targets along with integration tests that invoke MSBuild itself, then use the NuGet package in the project you want to use code generation from inside VS. Nevertheless, I suggest importing the file via a direct path since references are copied AFTER compilation
– Martin Ullrich
Nov 27 '18 at 0:11
If you don't want it to lock VS, I suggest splitting the solutions and trying to build a NuGet Package / SDK package containing the task + targets along with integration tests that invoke MSBuild itself, then use the NuGet package in the project you want to use code generation from inside VS. Nevertheless, I suggest importing the file via a direct path since references are copied AFTER compilation
– Martin Ullrich
Nov 27 '18 at 0:11
@MartinUllrich I packaged the task as a NuGet package and installed it in the project that needs to use it. This has the same effect as a project reference: the .dll does not exist in
$(OutputDir) until after the build. In other build systems it would be a compile scope dependency, but MSBuild apparently has no concept of that. I also expected UsingTask to be able to use AssemblyName instead of AssemblyFile when consuming a NuGet package, but that doesn't work, either. Perhaps I don't understand the correct usage of AssemblyName.– TKK
Nov 27 '18 at 0:23
@MartinUllrich I packaged the task as a NuGet package and installed it in the project that needs to use it. This has the same effect as a project reference: the .dll does not exist in
$(OutputDir) until after the build. In other build systems it would be a compile scope dependency, but MSBuild apparently has no concept of that. I also expected UsingTask to be able to use AssemblyName instead of AssemblyFile when consuming a NuGet package, but that doesn't work, either. Perhaps I don't understand the correct usage of AssemblyName.– TKK
Nov 27 '18 at 0:23
Maybe a MSBuild task is entirely the wrong thing to use for this purpose. I originally wrote my code generator as a console app, but I thought a build task would be less hacky.
– TKK
Nov 27 '18 at 0:27
Maybe a MSBuild task is entirely the wrong thing to use for this purpose. I originally wrote my code generator as a console app, but I thought a build task would be less hacky.
– TKK
Nov 27 '18 at 0:27
|
show 2 more comments
0
active
oldest
votes
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53487734%2fwhich-msbuild-target-copies-the-dll-from-a-project-reference%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53487734%2fwhich-msbuild-target-copies-the-dll-from-a-project-reference%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Do you need to run before compile? Usually you'd develop these tasks in a way that doesn't require referencing them from VS because of this reason.
– Martin Ullrich
Nov 26 '18 at 22:56
@MartinUllrich It's a code generator, so yes.
– TKK
Nov 27 '18 at 0:07
If you don't want it to lock VS, I suggest splitting the solutions and trying to build a NuGet Package / SDK package containing the task + targets along with integration tests that invoke MSBuild itself, then use the NuGet package in the project you want to use code generation from inside VS. Nevertheless, I suggest importing the file via a direct path since references are copied AFTER compilation
– Martin Ullrich
Nov 27 '18 at 0:11
@MartinUllrich I packaged the task as a NuGet package and installed it in the project that needs to use it. This has the same effect as a project reference: the .dll does not exist in
$(OutputDir)until after the build. In other build systems it would be a compile scope dependency, but MSBuild apparently has no concept of that. I also expectedUsingTaskto be able to useAssemblyNameinstead ofAssemblyFilewhen consuming a NuGet package, but that doesn't work, either. Perhaps I don't understand the correct usage ofAssemblyName.– TKK
Nov 27 '18 at 0:23
Maybe a MSBuild task is entirely the wrong thing to use for this purpose. I originally wrote my code generator as a console app, but I thought a build task would be less hacky.
– TKK
Nov 27 '18 at 0:27