How to make Visual Studio resolve and include all the dependencies of my project during build?

Question

I have a large solution currently under VS2010, with lots of projects and dependencies. Some of them are installed to the GAC, some of them are just included from a "lib" folder. I need to build one of my projects (specifically a WinForms app) to able to run on any, non-development computers without any installation process (except for the .NET runtime of course), just as portable apps do.

For this to work, I need to have all of the referenced DLLs and their whole dependency tree in the output folder of my EXE. I can do it for exemple by marking the dependencies to "Copy local" in the properties window, but that works only for the direct references of the EXE project, so it's far not enough. Another way is to make a setup project, but my client and also I want to avoid that (in the final version I'm gonna use ClickOnce). Of course I can always do it purely by hand, gathering all the DLLs manually, but that's quite a nightmare.

Is there some tool, msbuild trick, command-line option, whatever hack to force Visual Studio to gather the whole dependency tree of my EXE during build, and copy them to the output folder? So that I could just ZIP everything together and send to my client.

Solution 1

I actually chose a somewhat "middle" solution, the following way.

1. I created a "dummy" setup project, not caring about setting anything but adding the project outputs (primary output, localized resources, contents, etc.). It was a 2 minute task this way.
2. I built the setup project, and got the MSI file as the output.

3. I've extracted the contents of the MSI file to a specific folder, called "MyAppPortable" for example. I found the solution here. The command-line command is

   msiexec /a "absolute_path_to_my_MSI_output" /qb TARGETDIR="absolute_path_to_my_desired_output_folder"

4. I got the full application with all of its resolved dependencies (except for late-binding dependencies, but I took care of them manually, by adding them as references to my projects). I could ZIP the whole folder, put it on another computer, and voila, everything worked fine.

Solution 2

Basically, using Visual Studio, you can set all of your Solution's Projects to build into the same Output folder and use this folder as your Windows Form application folder (where the application EXE will reside).

By doing this, you will coordinate all of the possible assemblies references that your app is depend on.

In VS 2012, right-click on a Project => Properties => Select Build (left pane) => Set your Output path:

I would select a a solution-level folder as the Output path.

And if it's prohibited to perform such a modification at your workplace so I would suggest you to use dependency analysis tools like the following in order to interrogate and gather the appropriate assemblies that your app is depend on and will require at run-time:

• Dependency Walker
• NDepend
• Red-Gate Reflector

Update:

Using the above mentioned tools will not yields assemblies references which are late-bounded (at run-time), for this case you may use: Fusion (the Assembly Binding Log Viewer)

Comments

[Zoltán Tamási]

Thank you, but as you wrote, I don't have possibility to do such a global change. And it even does not sound as a good practice. I'm gonna check the tools which you suggested, but will wait a bit for maybe getting or finding an easier way.

[Yair Nevet]

@ZoltánTamási What ever you're going do, take on account that your application may use Late-Binding for assemblies resolving - something which is not possible to figure out using the tools I've mentioned. See my update for late binding.

[Yair Nevet]

Interesting.. by extracting the files from the MSI package you could retrieved the entire dependency tree of your application?

[Zoltán Tamási]

Yes, because the setup project inclues all of them (dlls, resources, PDBs, everything what you add to the setup project) for a full installer. I just "hacked out" the installation files from the MSI, just as a normal installation process puts them in the program files folder.

[Yair Nevet]

Couldn't you just create a new folder and copy all of the required dependencies files into? How the MSI helped you? what is its added value? Did it automate something for you? It's not clear what it the real benefit of using the MSI - It's sounds just like a very long copy-pate operation.

[Zoltán Tamási]

The problem is to FIND all the required files. A setup (or more generally, deployment) project can recursively gather all dependency DLLs, resources, content files together, no matter if they are in the GAC, "lib" folder, any installed third party library, or any referenced project. All this stuff is packagesd into the MSI file. Gathering all of this (ie. deploying your application) manually is a nightmare (I tried it), and cause errors in a lot of way (missing DLLS, missing content files or resources, not matching versions, platforms, etc.).

[Yair Nevet]

But you said: "(dlls, resources, PDBs, everything what you add to the setup project)". So you're responsible to add them or the MSI can do it automatically for you?

[Zoltán Tamási]

I ment "add" like adding "Primary output from MyWinformsProject", or "Debug Symbols from MyWinformsProject", etc. in the VS setup project designer.

[Yair Nevet]

I really suggest you to read this answer: How to include dependencies in Setup and Deployment Project?

[Zoltán Tamási]

Thank you for pointing that out. I've experiences such behaviours before, but it was more likely that it included DLLs which could have been excluded. But this is not problem for me, the VS feature is satisfactory.

[Shiv]

Instead of outputting an .msi, a setup project can be configured to output loose files saving the effort of extraction.