MSBuild.exe Copy task does not work properly unless the file version is displayed in the target

I am using MSBuild.exe v4.00. I have a build target in my project file that copies the Parameters.MyEnvironment.xml file to Parameters.xml. "MyEnvironment" may vary depending on when / where MSBuild.exe is called.

This is done, then the Parameters.xml parameter is used by other processes in the target MSDeployPublish environment.

Finally, I delete the Parameters.xml file because it is just a copy of one of my environment files.

When launched, as described above, the target MSDeployPublish behaves as if Parameters.xml were not, but did not report an error.

However, if I delete the delete task, so that Parameters.xml remains after completing my project build, MSDeployPublish sees it and uses it correctly. Oddly enough, any change to Parameters.MyEnvironment.xml is immediately reflected in the next build process.

To summarize - copying a file (which was not previously there) to the folder of my project, which uses the following target, does not work. However, if I leave the source file and overwrite it with the new version of the source, it works, reflecting the new content!

This author discovered a lock / open file issue with MSBuild, do I have the same thing as here? http://dotnet.dzone.com/articles/using-custom-webconfig-0

+1
source share
1 answer

Well, I still do not understand why the MSDeployPublish target is disabled on my Copy task. However, I have a dirty workaround that I can live with now.

I added these goals to my wdproj file:

<Target Name="BeforeTeamCity"> <Copy Condition="Exists('$(MSBuildProjectDirectory)\Parameters.$(Configuration).xml')" SourceFiles="$(MSBuildProjectDirectory)\Parameters.$(Configuration).xml" DestinationFiles="$(MSBuildProjectDirectory)\Parameters.xml" /> </Target> <Target Name="AfterTeamCity"> <Delete Files="$(MSBuildProjectDirectory)\Parameters.xml"/> </Target> 

I used to try to stack them in the rest of the assembly using the BeforeTargets and AfterTargets attributes, so I could do all of this with a single call to MSBuild.exe, and they would just connect well.

Having given up on this, I now call MSBuild.exe three times. Once for the BeforeTeamCity target, once for the target MSDeployPublish, and once for the AfterTeamCity target. Works great, go figure.

0
source

All Articles