Deploying .NET Apps

Jacques Bourgeois of Devx.com says:

.NET files do not need to be registered, unless you want to call them from a COM (VB6) application.

The possibility of deploying a project only by copying the file is possible in .NET, but it depend on the dlls used by the project. This is called XCOPY deployment, because of the XCOPY command that was used in DOS to copy a batch of files.

Here are a few basics to guide you, but it is surely not complete. Every situation is different, because every application uses its own set of dlls.

The first thing is to make sure that the users have the proper version of the framework. An application developed on the framework 2.0 should work with the framework 3.0, but not the reverse.

If the application uses only dlls from the framework and the user has the proper version of the framework, no problem.

If the compiler copied dlls in the compilation directory, then those should also be copied and put in the same directory as the application on the user machine as was suggested by many.

The main problem with such a deployment, when it works, is that the user has to start the application from Windows Explorer or manually create the necessary shortcuts.

Everything is not always so simple however.

In the following situations, you will probably have to resort to a Setup program, or at least a simple .bat or .vbs file to correct some of the problems associated with a straight copy.

In some compilations, needed files from outside the framework are not copied in the application directory upon compilation. This is most often due to third party dlls that do not install correctly in your development computer (Crystal Report is a good example) and do not instruct the compiler to copy them when they are referenced.

If you encounter that problem, you might try to change the CopyLocal property of the reference to True. However, it is not always that simple, because some of the dlls your application need might not show in the references (Crystal Report again).

If you reference a COM / ActiveX / VB6 dll in your application, it won't be copied in the compilation directory. You mostly end up instead with a dll that has the word "interop" somewhere in its name. This interop is a only bridge between .NET and the COM dll. In such a case, the interop must be distributed with the application, and the COM dll must already be installed on the user machine for the application to be able to use it through the interop.

Some applications such as Microsoft Office for example, can be installed with special interops called Primary Interop Assemblies (PIA). If you have the PIAs installed on your development computer, the compiler does not say anything and assumes that they are also installed on your clients computers, which might not be the case.

These are the situations that are encountered the most often. Depending on the dlls you use in your applications, you might find other situations that prevents you from simply copying the files on the user computer.

If users will use the application from the network (click on the .exe file located on a server), remember that security rules are not the same when the application is installed locally and when it runs from somewhere else, so be sure to check and test the application in an environment that is similar to the one in which it will work.

ClickOnce is also an alternative. It is a lot simpler to prepare a ClickOnce installation than to do so with a standard Setup package. It also tremendously simplify updates to the application. You might however be aware that this could also come with it own security limitations.

Simple tutorial for ClickOnce:
http://www.kirupa.com/net/clickOnce3.htm