5

I am working on a C# .NET project in Visual Studio 2010. I am integrating a hardware peripheral that has a DLL. I reference the DLL file in my project and the code compiles/builds without any errors. When I run my application I get a runtime error saying that it is looking for another DLL file. It appears that the DLL I reference in my project has 42 other DLLs that it depends on. When I place these 42 DLLs in the output directory (bin/debug) the application runs just fine.

My questions is this: what is the best way to manage these extra DLL files when Visual Studio doesn't recognize them as dependent libraries?

user2022535
  • 53
  • 4
  • sounds like you will need to copy those .dll's over every time or you can GAC the .DLL's or you can set the .dll properties to copy local when you compile or deploy.. not sure if adding the .dll's as a resource would work for you either but you may want to try that as well.. – MethodMan Jan 29 '13 at 17:39
  • You can try add post build action to project. look at: http://stackoverflow.com/questions/12384628/msbuild-copy-file-after-build – gabba Jan 29 '13 at 17:51
  • Did you check with whoever provided the libraries on what is the right approach? They may already have recommendations or even strict requirement on how to do so - i.e. if there are technical reason (i.e. registry key/configuration) or legal (can't copy files separately). – Alexei Levenkov Jan 29 '13 at 18:26

4 Answers4

6

This scenario does resemble a lot to deploying SQL Server Compact files. In that context it's called Private File–Based Deployment.
It also requires some external (unmanaged) DLLs that the application will depend on.

What it boils down to is to include the DLLs in your project and set their Copy to Output Directory properties to Copy if newer. They will then be copied to the destination folder after a successful build.

EDIT:
Based on your comment, it seems to you are having problems at install time of you application (something you completely fail to mention in your question), and you have written a Custom Action for your installer to copy these 42 DLLs to your target.
There's no need for a CA to do that. Simply right click on your installer project -> View ->File System. Select the Application Folder, in the right hand side right click and select Add File and add your 42 DLLs.

Magnus Johansson
  • 28,010
  • 19
  • 106
  • 164
2

If you mean to manage these files at compile-time you can add a post-build event to the project to copy all of the necessary files over to the output directory. Add flags to xcopy here to only copy over if changed.

If you mean at run-time an installer would be your best solution.

user704772
  • 309
  • 2
  • 11
  • I created a custom action installer that would copy all necessary DLL files into the root of my installation directory. This solved my issue. – user2022535 Feb 01 '13 at 21:04
  • If you are using the built in Installer project in Visual Studio 2010, there's is no need to write custom action for this kind of operations. See my updated answer. – Magnus Johansson Feb 02 '13 at 07:54
1

Or you could combine them using something like ILMerge to combine the assemblies. And you just add a reference to the resulting assembly.

How to merge multiple assemblies into one?

Community
  • 1
  • 1
Petrutiu Mihai
  • 565
  • 4
  • 14
  • I tried using ILMerge but I couldn't get it to work with the DLL files I was using because they were all unmanaged. – user2022535 Feb 01 '13 at 21:02
0

You should work on creating an Installer package, almost all Installers will bring in all of the dependencies of referenced dll's if the projects outputs are configured as needed for the installer. It is the only way I can think of to dynamically have your non-referenced dependencies be automatically brought in.

Alex
  • 12,749
  • 3
  • 31
  • 45