I'm trying to improve our build process, and to that end I've been looking at turning off copy local and having the whole solution build to a common \bin directory.
What however, is best practise for getting the no longer copied references into the bin directory? I don't want to do this in one of the actual implementation projects as many of them use the same referenced components, and it will mean a proliferation of post build steps.
I know I could create a custom msbuild file but then that would need to be run manually outside of visual studio (I think)? which seems like friction. Is there a way I can create an msbuild project for example, and then have that as part of my solution.
Or is it best just to manage this outside my solution build and have a copy_references.bat file which the dev has to run once to setup their environment getting them into the /bin/debug and /bin/release directories? This seems a bit fragile, but better than checking /bin开发者_C百科 and the files into svn directly.
One idea I've had is to create an empty c# component project and add the references to it, with copy local turned on. If this was then made a dependency of all other projects it would manage the copying.
Next question is how to manage this with nuget references? My preference is to not check the references into svn, but tell nuget to grab them. So this would also need to be a build step, but again at the solution level.
Additional Info
For a bit more background on why I am evaluating this approach, have a look here:
http://www.ndepend.com/Res%5CNDependWhiteBook_Assembly.pdf
The goal is to massively speed up compilation time by stopping all these redundant copies. Also side benefits if it works might be not having to manually work around the times dependency evaluation doesn't work. Causing one to have to pull referenced assemblies' dependencies into your top level project to ensure they end up in the bin folder.
I suppose in some ways the desire to turn off copy local is an artifact of the inefficiency of the ms build process at both tracing dependencies and evaluating the need to copy things.
You can override the $(OutDir) property globally and keep CopyLocal enabled. Since every project is copying to the same $(OutDir), you won't end up with too much duplication. This is pretty straight forward.
Much more involved, you can also create a shared import file that wires into the standard build and performs a custom post-build deployment. For example,
<Target Name="Deploy"
DependsOnTargets="Deploy)"
AfterTargets="Build">
... copy all output files ...
e.g. use wildcards $(OutDir)\*.dll
e.g. $(OutDir)\$(TargetName)$(TargetExt)
e.g. copy referenced assemblies and copy, see below
</Target>
To get the references, you can call the ResovleAssemblyReferences target and use Returns, or create your own target to get a specific collection as shown in the answer here, Return the ReferenceCopyLocalPaths from <MSBuild> task It can be rather involved, but easily configured if you can declare your own "rules" in an item array with metadata.
精彩评论