5

I am setting up an installer project for a C# solution and I encounter a dependency problem:

In my solution, I have 4 independent project outputs – one windows service and three executables, who all share between them some references.

I need the installer to install all four of them in order for the solution to work.

I've set up an installation folder for each project output under "Application folder" in the "File system on target machine" dialog, added the project output of the windows service successfully in its folder. But when I continue to try and add the executables' project outputs in their folders the assemblies already carried into the windows service folder are not carried into the executable folder, and following the installation the executables won't run as they are missing dependencies.

I can manually add the missing assemblies to the executables' folders, but it seems that this is not how it should be done and there's something I'm missing.

Any ideas?

Mr Mush
  • 1,538
  • 3
  • 25
  • 38
Eliaz
  • 61
  • 2

2 Answers2

1

I was having what I think is the problem that was originally described. I have a Winform app and a console application as two separate projects, but a single setup project handles both.

Both the Winform app and the console app use the same two external assemblies: one not part of the solution (reference to a file in a folder), and the other from a C# class project (reference to the project).

What I have found is that the installer assumes that the project output is all combined into a single folder on the installation machine. Therefore, all of the common assemblies will also co-reside with the executables that need them. So if you add the project output from the first executable into the folder, that is why you see all its dependencies appear, and then when the second project output is added, only the assemblies not already added will appear.

It doesn't matter if you create subfolders under the Application folder, Visual Studio appears to treat the Application Folder as a whole unit... as far as Project Output (exe, dll and res) are concerned.

There are two ways to solve this. The first is to create a separate installation project for each executable. In a large project, this could be a lot of setup projects.

If you want to keep everything in a single installation, a better option is to use the GAC for the shared assemblies, which is described in another Stack Overflow article here: Use Visual Studio Setup Project to automatically register and GAC a COM Interop DLL

MSI can get the job done. Right-click "File System on Target Machine", Add, GAC. Right-click that added folder, Add, Project Output. That ensures the assembly is gac-ed.

The GAC is the better solution in my mind, because your assemblies are managed by the .NET layer if you later make changes and enhancements to them. One of the benefits of .NET is to eliminate the old "DLL hell" issues that were in Win 98 and previous versions of Windows. I highly recommend using it for your common code.

Community
  • 1
  • 1
John J Schultz
  • 11
  • 4
1

Well you should create a new project in the solution, and set the "installer" to be the output of your main application (or main applications) it should solve the dependencies itself.

squelos
  • 1,189
  • 6
  • 16
  • I'm sorry, but I didn't understand anything of the above. What new project should I create in the solution, and for what purpose? what do you mean by setting the installer to be the output of the main application(s)? please try to elaborate. Thanks. – Eliaz Mar 11 '12 at 07:42
  • Yes, the setup should have the output set to whatever application you want to deploy. The references should be solved by themselves, and in the properties, you should be able to define in what way the assemblies are deployed. But im really not sure if we are talking about the same thing. – squelos Mar 11 '12 at 09:44