0

I developed a new label control and compiled it into a DLL which I am using in one of my other apps. The problem is, the app fails to launch in the target environment if I don't include the label control's DLL with the setup and install it in the same directory as the app.

I am trying to understand why this is. I thought with VB.NET we no longer have to include individual DLLs if we reference and build the app with it. I tried looking for answers elsewhere but the information is patchy to me.

Any help would be highly appreciated.

AntikM
  • 636
  • 4
  • 13
  • 28
  • Hard to guess where you got that idea. Maybe the "Embed interop types" feature, available since .NET 4.0 and useful for legacy ActiveX controls. Big difference is that interop assemblies only contain declarations, not code. You need that code you wrote, it is not going to teleport. – Hans Passant Apr 30 '17 at 13:16
  • 1
    "I thought with VB.NET we no longer have to include individual DLLs if we reference and build the app with it" Nope. When you build a deployment project, all the dll's are included in the .msi file, and they end up in the program files folder along with your .exe – peterG Apr 30 '17 at 13:18
  • Thanks for the response. So that means every external DLL I use in my project must be included and installed in the app folder? – AntikM Apr 30 '17 at 13:20
  • 1
    Have a look at [Costura](https://github.com/Fody/Costura) which is available as NuGet Package. It is able to embed resources like DLLs to your executable. – Alex B. Apr 30 '17 at 13:20
  • 1
    In the conventional case, yes, the dll's go in the app folder. Perhaps you're thinking of the 'dll hell' in the days of COM, and the registering etc that went along with all that. With .net, you can just copy the dll's into the app folder, and the app will find them. You can also install your dll's into the GAC, if you wish, but that's something I've never needed to look into. – peterG Apr 30 '17 at 14:54

0 Answers0