Why my WPF program cannot run without Visual Studio?

Question

I made a WPF program which uses SQLite. And by using Visual Studio 2012, it generates both Debug and Release version exe file. When I go to Debug or Release directory and run my exe file, e.g. MultiStart.exe, it can run normally.

But if I copy the MultiStart.exe to my Desktop and try to run it, it failed. By several tests, I found that I also need to copy files MultiStart.exe.config and System.Data.SQLite.dll to my Desktop. And then it can run now. But why? Do we have better solution so that I can make it run without additional files?

Answer 1

You can also use ILMerge to merge all dependencies into single .exe file to simplify distributiuon of your application.

More detaiils on ILMerge can be found here: ILMerge on CodeProject

Example of usage: ilmerge /target:winexe /out:YourDestinationApp.exe YourCurrentProgram.exe System.Data.SQLite.dll

Answer 2

Why my WPF program cannot run without Visual Studio?

The question title is not really accurate since it's not really related Visual Studio. MultiStart.exe is dependent on configuration (MultiStart.exe.config) as well as other assemblies (System.Data.SQLite.dll). Without these dependencies the application cannot run (because that is how .NET works).

WPF doesn't necessarily need a config file to run so the question is what is in your config file that the application needs. It might be possible to move this configuration information into the code (e.g. connection string) and remove the app.config but then the values will be hard coded in the application.

In terms of dependent assemblies, instead of deploying them it is possible to embed them as resources and then use the AppDomain.AssemblyResolve Event to read the assembly from a resource (see Embedding assemblies inside another assembly for an example).

Another approach instead of embedding assemblies as resources is to merge them into one assembly. ILMerge is a popular choice for merging assemblies but I read that it can have issues with WPF assemblies (not sure if that applies to you). See Merging dlls into a single .exe with wpf for some other ideas for merging assemblies with WPF.

Note that setting PATH variables does not work because .NET does not use the PATH for resolving assemblies -- see How the Runtime Locates Assemblies for the details.

Another, option instead of copying the MultiStart.exe to the desktop is to use a shortcut on the desktop that links to the appropriate directory. Perhaps that is a simpler solution

Answer 3

Because you're missing things from your PATH. Visual Studio is probably set to copy DLLs to the target directory on build.

You're almost certainly pulling in external libraries. Some of these are part of .NET, while others are packaged in libraries in specific folders. When you start your exe, it looks in your PATH and the current folder for everything (which includes all DLLs Visual Studio copied).

When you moved the exe to the desktop, suddenly it had no idea where those DLLs are. You haven't specifically added them to your PATH, and they are no longer in the current folder. This is why copying those DLLs to your desktop magically made them work.

Unless you stop use SQLite, there is not a way for you to not need that DLL (there are lots of ways to package/reference it though).

Answer 4

Better solution that i used to do with my windows form apps is, Copy the entire folder, which contains supporting files. place it where you want. then create a shortcut of your .exe on your desktop. That always worked for me.

Answer 5

Because you are missing some dependency. You can open your config file and set the dependency...but I wouldn't recommend you to change config file manually. You can also copy the dependent dll in system32 folder. ..but its only a trick because exe first search dlls in current folder than system 32 folder.