EDN Admin
Well-known member
Hello,
we are porting our VS 2008 code to 2012 and weve noticed quite a change in the handling of utility projects in 2012.
We use utility projects to copy large sets of 3rd party binaries into output directory using a pre-build command with xcopy. This has worked fine in 2008 but 2012 handle things differently. We have noticed that once a utility project has been build it is marked as successful and wont be run again unless we recompile it.
This is quite annoying because the utility copies files and after updating the files from a repository the user must explicitly rebuild the utility. In 2008 the utility was always run and due to xcopy /d only newer files were copied and the overhead of the utility had no impact when everything was up to date.
The behaviour changed in 2010/2012, I suppose due to the shift to msbuild. To reproduce that, I have created anentirely new solution in 2012 with one c++ project containing a main.cpp and a utility project that does echo "Hello" in its pre-build step. The utility is set as a dependency on the c++ project.
Here is the minimal reproduction case: https://skydrive.live.com/redir?resid=214692BB08C60DE2!1321&authkey=!AGrYyOPChsT-VeE
Running the thing once outputs the hello string but then I can do what ever I want, like modifying to the c++ project but the utility is never run again.
Is this a known behaviour? I am aware that I could delete the intermediate directory or touch the files generated there to always trigger a rebuild, but from my point of view this looks like a breaking change and I was unable to locate this change in the 2010 and 2012 breaking change lists.
This post is originally created in the wrong forum (for reference: http://social.msdn.microsoft.com/Forums/en-US/visualstudiogeneral/thread/d0ff9ec3-a1ea-4fd4-97b3-b316b2f969bd/?prof=required)
I doubt we are the only one that copies third party binaries and the new behaviour of utilities will pretty sure introduce some nasty bugs with outdated binaries due to missing copy calls used in conjunction with new headers (since they are not copied but referenced from where they are checked out).
View the full article
we are porting our VS 2008 code to 2012 and weve noticed quite a change in the handling of utility projects in 2012.
We use utility projects to copy large sets of 3rd party binaries into output directory using a pre-build command with xcopy. This has worked fine in 2008 but 2012 handle things differently. We have noticed that once a utility project has been build it is marked as successful and wont be run again unless we recompile it.
This is quite annoying because the utility copies files and after updating the files from a repository the user must explicitly rebuild the utility. In 2008 the utility was always run and due to xcopy /d only newer files were copied and the overhead of the utility had no impact when everything was up to date.
The behaviour changed in 2010/2012, I suppose due to the shift to msbuild. To reproduce that, I have created anentirely new solution in 2012 with one c++ project containing a main.cpp and a utility project that does echo "Hello" in its pre-build step. The utility is set as a dependency on the c++ project.
Here is the minimal reproduction case: https://skydrive.live.com/redir?resid=214692BB08C60DE2!1321&authkey=!AGrYyOPChsT-VeE
Running the thing once outputs the hello string but then I can do what ever I want, like modifying to the c++ project but the utility is never run again.
Is this a known behaviour? I am aware that I could delete the intermediate directory or touch the files generated there to always trigger a rebuild, but from my point of view this looks like a breaking change and I was unable to locate this change in the 2010 and 2012 breaking change lists.
This post is originally created in the wrong forum (for reference: http://social.msdn.microsoft.com/Forums/en-US/visualstudiogeneral/thread/d0ff9ec3-a1ea-4fd4-97b3-b316b2f969bd/?prof=required)
I doubt we are the only one that copies third party binaries and the new behaviour of utilities will pretty sure introduce some nasty bugs with outdated binaries due to missing copy calls used in conjunction with new headers (since they are not copied but referenced from where they are checked out).
View the full article