How to assemble multiple .NET executables in a sin

问题:

I have multiple solutions each having multiple projects.

What I want to do is to assemble a subset of these projects from possibly different solutions into a single "package" and deploy it as such.

I could edit each project and change it`s output folder but this would be counter productive, espacially that some of these projects are shared dependency amongst the different target packages. This would make a tedious mess and very error prone.

Ideally also I would like some freedom as to how these are assembled in the final package, perhaps this application goes in the root folder of the package but perhaps this other executable will go in a subfolder of the final package.

Finally the team I work with are not familiar with MSBuild so the final solution should be usable from VisualStudio.

I was thinking to create a task that would scan the project dependencies and simply copy the content of each output folder in the output folder of a specialized project (that would contain the task). Final destinations could be fine tuned via a property file if necessary.

Is there a better way ?

---

By Package I simply mean a folder containing all the artifacts may them be executables, DLLs, resources, config files etc. I still want to keep them as seperate entities however.

回答1:

I assume you're trying to get a single executable with no external dll's. To do this use a post-compile event on the exe to call into ILMerge to combine the exe and dll's into a single exe.

http://www.microsoft.com/en-us/download/details.aspx?id=17630

回答2:

I ended up creating a new output folder in which I copied the output of a project's build. Then other projects that depended on that first one would pull the content and merge with theirs before coping in their own extra output folder to repeat the process down the dependency tree.

This ensured that all artefacts follow through to the final application's build not just DLLs.

I needed that at the time to then package the whole thing in a click once archive.

It worked also on the build system as that extra folder was zipped-up as an artefact that downstream projects could use and merge. Was not very clean though but worked good enough for my needs. With hindsight I could probably have leveraged nuget to achieve the same outcome in a much cleaner and maintainable way.