4

On a .NET project, I have a couple of functions imported from native DLLs.

Currently to add the native DLLs to the project, they are copied to the root of the C# project and their property Build action is set to Copy to output directory.

Is there a better workflow for bundling native DLLs?

hemp
  • 5,602
  • 29
  • 43
aybe
  • 15,516
  • 9
  • 57
  • 105
  • I think, you need create setup, which will place and register (if needed) your native Dlls. If they work just by placing them into your bin, then you can deploy your app even using Zip. Deployment is up to you. You can create professional deployment, use setup program and digitally sign it. So, when users start to install, they don't get warnings. Or you can place your files on FTP share and tell users - go get it here and run application.exe. There is no BEST way – T.S. Jan 22 '14 at 16:57
  • 1
    Having the build system copy the DLLs for you automatically is of course very convenient and keeps you out of trouble. It isn't clear why you'd want to change it. You can use a post-build event to copy them yourself out of another directory with XCOPY so they are not visible in the project, if that's your hang-up. Otherwise a good way to have your build break a year from now because you forgot to check-in those DLLs and have lost them. – Hans Passant Jan 22 '14 at 18:56
  • @HansPassant Perhaps the OP wants all in one file for ease of deployment. – ispiro Jan 22 '14 at 19:10
  • @HansPassant That's exactly what I thought, one just needs to ensure to not lose these DLLs. – aybe Jan 22 '14 at 20:06

1 Answers1

1

One option, which is particularly useful if you want single exe deployment, is to embed the DLL(s) into your manifest as Resources. This is a similar approach to what is often used to create "universal binaries" which can run on either X86 or X64 platforms from a single file. In that case you embed the 64-bit version inside the 32-bit version and extract it at runtime when needed. You can see that in action with the Sysinternals binaries.

In your case, you would embed a native binary within the managed executable, then either load it as an IO stream at runtime or extract it and reference it from the extracted path. In either case, you never have to worry about "losing" the resource because it's part of your project.

If you decide to go that route, the answer to how to do it has been provided several times over. Here's one such question: Embedding unmanaged dll into a managed C# dll

Community
  • 1
  • 1
hemp
  • 5,602
  • 29
  • 43
  • I'm marking it as the answer as you really answer the question, however I've opted for @Hans Passant solution as it's simpler and less messy in the end. Having DLLs on another folder and not having to do some DLL loading is a good deal IMO. – aybe Jan 25 '14 at 00:09
  • Yep, nothing wrong with that approach - it's tried and true, as is using an installer to deploy and/or register the DLLs at installation time. – hemp Jan 25 '14 at 09:38