2

I've built against the release profile and this creates an executable build within the release directory in my project.

How do I best distribute to clients from this executable? There are a lot of files within this folder which don't appear when installed through the installer, such as the mainifest and one called application.exe.xml (which is confusing when Windows hides the extension in Windows Explorer).

Are these all necessary? Can I just send the executable? Or will I need to send with all the files? Is there a way to build without all these files?

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Thomas Clayson
  • 29,657
  • 26
  • 147
  • 224
  • 1
    Before anything else, if not using an installer, you need to ensure that the client has the correct version of .NET installed. – Oded Nov 24 '11 at 15:20
  • i think you want one file to install the project/solution. My suggestion is to use HM NIS editor. use this and select all the .exe and .dll files. when running the HM NIS Programm an Setup will be made – Moonlight Nov 24 '11 at 15:22
  • hi oded... thats definitely ensured! :p – Thomas Clayson Nov 24 '11 at 16:19
  • moonlight - our client cannot install programs onto their machines. – Thomas Clayson Nov 24 '11 at 16:21
  • Related: *[Best way to deploy Visual Studio application that can run without installing](https://stackoverflow.com/questions/16946173)* – Peter Mortensen Sep 13 '19 at 10:56

4 Answers4

3

You must send the EXE file and any DLL file that you reference locally. If you use COM references and the like, you need to register them during the installation. The same thing for the GAC I think, but I haven't used that for stand-alone applications myself.

The application.exe.config file contains the application settings (a copy of app.config). If you don't use settings or the user doesn't typically care about them, you can omit the file, and it will use the default values you built the application with.

The vshost files are not needed (if you have them). They are used by Visual Studio's debugger. The .pdb files contain debug data used to facilitate DLL file to source matching. Unless you plan on attaching a debugger to the application, there is no point sending those.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Kevin Coulombe
  • 1,517
  • 1
  • 17
  • 35
  • Hi Kevin, you seem very knowledgeable on the subject. The only external framework my application references is the OpenXML framework (I believe). Will I need to package this DLL in the folder with the executable? I have added it to the referenced libraries folder in the project. – Thomas Clayson Nov 24 '11 at 16:25
  • Good answer, really helped, really concise and easy to understand. Just to clarify "you must send the exe and any dll you reference locally" -> what worked for me was literally putting the dll files into the `release` directory. – Thomas Clayson Nov 24 '11 at 16:50
  • Click on the reference in the solution explorer, then hit F4 to open the properties. Set the "Copy local" property to true and the build process will copy that dll for you. – Kevin Coulombe Nov 24 '11 at 21:10
  • Thank you very much for your answers and comments, its very helpful. Just one more thing, if I do this and create an installer will I need to undo it at all? What I'm really asking is would it be the best idea to ALWAYS set external DLLs to "Copy local" (for testing and such), and will this impact on the ability to create an installer? – Thomas Clayson Nov 25 '11 at 16:29
  • When you create your installer, you will send everything from the release folder except for pdbs and vshost files. Local references and "Content" files that you set "Copy to output directory" will get picked up automatically by the installer. You won't have to edit your installer project when you change dependencies for example and everything is checked at compilation. I find it makes the job of creating an installer much simpler. – Kevin Coulombe Nov 25 '11 at 16:51
1

Usually, in an XCopy deployment you have to deploy (literally copy all files deployment with no setup/installer program) the content of the output folder (like debug or release) without:

  • *.pdb - debug symbols
  • *.xml - xml documentation
  • ?vshost? - Visual Studio hosting files

In fact, it anyway also depends on your specific application. As a developer, you need to know what you are producing; in case you are using an xml file which is not the result of the .NET documentation compiler, but a static file copied in the output folder, then do not forget to deploy it.

A last note: developers usually disable the option to hide file extensions in Windows Explorer ;-)

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Davide Piras
  • 43,984
  • 10
  • 98
  • 147
  • Hi Davide. My extensions are not hidden, but I was thinking about my client who may not have extensions visible. Anyway, this is what I've done so we shall see if I need to include any dlls or similar very soon! :p – Thomas Clayson Nov 24 '11 at 16:29
  • well you are supposed to test before deploying to the clients, just place the files you want to distribute in another machine with no Visual Studio, a machine similar to the one the client will use, and test your application there :) – Davide Piras Nov 24 '11 at 16:32
  • Yes, this is what I'm currently doing. :) Turns out I need the OpenXML dll. – Thomas Clayson Nov 24 '11 at 16:42
  • Good answer, thanks a lot, very helpful. Didn't mention to include dlls, which turned out to be an issue, so I gave kevin the tick. – Thomas Clayson Nov 24 '11 at 16:53
  • I said to deploy the content of the output folder without... I was meaning all should be given except... so of course dlls and exes and exe.config were included... ;-) – Davide Piras Nov 24 '11 at 16:55
0

You need to understand what an installer does or why an installer is important.

An installer takes care of the basic environment. The installer can carry dependent assemblies/modules along with the application. It can also check if you need something before you run, like .NET on the target machine. It can also create the shortcuts on the desktop or start menu. Plus it also provides adequate options on the target machine to uninstall it.

If you wish to ship the executable alone, you might miss out some assemblies that the executable depends on. The target machine may or may not have the correct .NET version installed.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Kangkan
  • 15,267
  • 10
  • 70
  • 113
  • Hi, thanks for the info, but unfortunately the client's computers don't have the correct level of authority to install programs that are not on an allowed software list so we have to ship the executable itself. – Thomas Clayson Nov 24 '11 at 16:23
  • So you are breaking the policy? Its even more serious and dangerous. You are shipping something that might not be in the safe list and you are bypassing the installation policy! – Kangkan Nov 25 '11 at 08:47
  • We are not breaking a policy. We are creating a program that doesn't need to access system files, the registry, protected directories etc. This is within the remit of the policy as provided by the company, and we are working closely with the company and their IT department to ensure that we have found the easiest and most secure way of delivering an executable program for use on their systems. – Thomas Clayson Nov 25 '11 at 16:25
0

Use the program: HM NIS EDIT from HM Soft.

  • Build your project
  • Run NIS EDIT
  • Make a new script from the wizard (Ctrl + W)
  • Run all the steps
  • Select all the .dll and .exe files
  • Build a setup file
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Moonlight
  • 708
  • 1
  • 7
  • 18