views:

2243

answers:

6

Hello. I have a relatively complex console application which relies on several dlls. I would like to "ship" this in the best form. My preferred way would be an exe file with all dependencies embedded in it (not that big, about 800K). Another thing would be to just zip the contents of the "Debug" folder and make that available, but I'm not sure if everything will be available like that (will all dependencies be resolved just by zipping the debug folder?)

So my question is: What reliable practices exist for deploying console apps written in C# using VisualStudio 2008?

(Again, apologies for the naive question.)

Thanks.

ANSWER: Thank you very much to all. I have decided to temporarily(!?) accept Jon's answer... simply by an Occam's razor argument. We will see how it scales up. If it doesn't, I will change the answer. I have also voted up Brien's answer, because it's a good one, just too "involved" for my purposes (there's also a usability problem: it makes users think they will get a windows program, when they only get a console). Thanks again.

+5  A: 

If you just copy the Foo.exe, dlls and Foo.exe.config files, it's likely to be okay. Have a look at what else is in the debug folder though - you (probably) don't want to ship the .pdb files, or Foo.vshost.exe. Is there anything else? If you've got any items marked as Content which are copied to the output folder, you'll need those too.

You could use ilmerge to put all the dependencies into one exe file, but I'm somewhat leery of that approach - I'd stick with exe + dependency dlls.

Jon Skeet
If you're going to do that, you should probably create a release configuration so you ensure the PDBs aren't included.
brien
What about ... compiling for release mode?
Lucas B
http://msdn.microsoft.com/en-us/library/wx0123s5.aspxIt's just a way of compiling without the debug symbols and pdb file.
brien
I just built for Release and the same files (and more!) are generated... including the pdb files and vshosts... what is the difference then?
Dervin Thunk
You should have a /bin/Release folder with fewer files (if I remember correctly) and the /bin/Debug will have all the debug stuff in it.
brien
I just deleted the bin/release and then ran it again... there are more files in it (including the pdb) and not other files that I need... but that is merely because I haven't set up the resources... but still.
Dervin Thunk
Just avoid copying the pdb files. You *can* change a setting under "Advanced" to stop them from being built (IIRC) but it's probably easiest just not to copy them.
Jon Skeet
Downvoters: care to comment?
Jon Skeet
+7  A: 

You should look into setup projects in Visual Studio. They let you set up dependencies and include the DLLs you need. The end result is a setup.exe and an MSI installer.

Here's a walkthrough that should help.

brien
A whole setup project for a console application? Isn't that a bit overkill?
Dervin Thunk
Not really, you can create a setup project really quickly that just copies the dlls and the exe that you need to the right place on the client machine.
brien
Windows Installer packages make it easy to automate installation, patching, and removal. Other solutions like EXEs make me sit at each machine and click things. If it were up to me, my company would never buy a license for software published as anything other than a Windows Installer package.
Jay Michaud
@JayMichaud: This is not that obvious for a console application. I'm still not satisfied with having a registry key, an icon and a start menu shortcut for a simple console app that takes options... One of the ideas behind building console apps is to make them simple to copy wherever, no?
Dervin Thunk
I'm however still intrigued why people have voted this as the best answer for a console app... It is, undoubtedly, the best answer for an app that uses a GUI... but a console?
Dervin Thunk
You don't have to include the icon, start menu shortcut, or modify the registry. You can make a setup project very, very simple. You're trying to create something that already exists in the tool you're using (but in a slightly more complex form). When you talk about packaging up your application and deploying it, that generally means you want a setup project. If you later decide you want your deployment to be more complex, you already have the tools in place to do that.
brien
+1  A: 

Jon's answers is good - I would also recommend ILMerge as a tool to simplify your deployment by allowing you to merge your executable with all its dependencies. This would allow you to have Foo.exe which would contain all your dll's as well.

Andrew Hare
A: 

Create a setup project in VS08 and add the primary output of the console app project to it, this resolves the dependencies and packages them in a .msi

SpaceghostAli
+1  A: 

OR you could use a self-extracting ZIP file. Package all the normal files up - .exe, .dll, .config, and anything else - into a zip file. Extract into a temp directory and set the run-on-extract program to be the actual console exe.

Cheeso
+4  A: 

Another option could be to use Windows Installer Xml (http://wix.sourceforge.net/). We use it at work and it has loads more features for complex installations when compared to the standard Visual Studio deployment projects.

Kane