28

We have a (pure native C++) .DLL that is build by VS. As clients we have some native C++ applications and a .Net-Wrapper around this DLL written in C++/CLI. Finally there are some client applications for the .Net-Wrapper written in C#.

My problem is that the native.dll must be distributed in a different way than the .Net world works and the VS does not keeps track of that DLL. So to let all my C# Apps work correctly I have to copy it to each executable directory or put it somwhere in %PATH% (which I would avoid on developer computers since they may want to start different apps with different versions of the DLL). Even bigger problems occur if there are UserControls that reference the Wrapper-DLL: You have to copy the DLL to VS's directory or again to %PATH%. But the worst case occurs with our Translator tool. This tool keeps track of .Net-Assemblies and packs them into Translator-packages that can be send to an external translator. As far as I know there is no way to put the native .DLL into that package!

So I plan to link the native DLL statically into the .Net-Wrapper which would solve my problems. But for our Native applications this native DLL must still be a DLL.

So I have two options:

  • Make two projects of that (one that generates a static library; and one that creates a dynamic one => I try to avoid this)
  • Find a solution to link DLLs statically
  • Find a way to let VS generate two outputs from one project
mmmmmmmm
  • 15,269
  • 2
  • 30
  • 55
  • I may be a bit daft here, but I don't understand why your native apps cannot use the native dll, and your .net apps use the c++/cli-wrapped dll. – Niklas Jan 08 '09 at 12:16
  • They can both. But the Wrapper-DLL references the native DLL and so my C# apps need both. Which is OK for the wrapper but is pain in the ass for the native DLL. – mmmmmmmm Jan 08 '09 at 12:50
  • Why not just build a lib for the dll? You said you build the dll using VS, no? – Henry B Jan 08 '09 at 12:52
  • How would this be done in Visual Studio 2019? https://stackoverflow.com/questions/67097557/how-do-i-build-a-statically-linked-dll-with-visual-studio-community-2019 –  Apr 14 '21 at 19:50

4 Answers4

7

In the C++ project file for the dll, create two configurations, one that generates a DLL and one that generates a .lib. Two projects are not necessary, since any .NET/C++ project can support multiple build configurations (this is how Release and Debug versions build differently).

BmanInHouston
  • 71
  • 1
  • 1
  • 1
    But there is no way to build two configurations of the same project in one go, is there? Normally you can select one project configuration/platform in the configuration manager for a solution configuration/platform. – mmmmmmmm Nov 05 '09 at 21:52
  • 1
    You can copy the project, and have a second one configured different in that solution. don't forget to set different intermediate directory's – thewhiteambit Mar 04 '16 at 20:02
6

Another option is to have two projects, one project will output a .lib which can be statically linked, and a second project which will output a .dll and will have your .lib as dependency, you should add .def to your .dll with the symbols that you are planning to export, or else it will be empty.

Ismael
  • 2,995
  • 29
  • 45
  • Sounds good. I will give it a try. At the moment I solved the problem by adding the obj-Files as additional input to the linker in the Wrapper-DLL (../NativeLib/$(PlatformName)/$(ConfigurationName)/*.obj). But this is kind of crude and your options sounds better! – mmmmmmmm Jan 14 '09 at 19:26
  • Could anyone explain how .lib and .dll are getting differentiated in this context? – Iqra. Aug 08 '17 at 07:46
  • In Visual Studio you have two differente application types 'Static Library' and 'DLL'. The 'Static Library' option creates a '.lib' file but it is not directly executable, the object code is put all together without processing. The 'DLL' option will create a '.dll' that is executable (ie you can use it through LoadLibrary), the object code is processed to resolve function calls, optimized. – Ismael Aug 08 '17 at 19:11
5

Pick up a copy of DLL to Lib (Edit: If you can't find a cheaper option)

SmacL
  • 22,555
  • 12
  • 95
  • 149
  • 8
    A bit expensive, isn't it? – mmmmmmmm Jan 08 '09 at 12:28
  • 2
    It's especially expensive given that you already have the source for the DLL. You can simple recompile it as a static lib file. But .Net won't use it since .Net doesn't do lib files. That also means DLL To Lib won't help you. – Rob Kennedy Jan 08 '09 at 12:37
  • Whoaa, that has gone up by about a factor of 10 since I bought it a couple of years back. Ouch! – SmacL Jan 08 '09 at 12:41
  • 1
    Yup just checked, I'm running 1.42, which cost $99 in 2003 which was an ok price at the time. – SmacL Jan 08 '09 at 12:45
  • @Rob: .Net shouldn't create a LIB. I like to link a LIB statically into a C++/CLI project emitting a (mixed) .NET assmebly. That works and so DLL To Lib would help...if it wasn't that expensive! (@smacl: $99 would be OK, but $999...) – mmmmmmmm Jan 08 '09 at 12:48
  • 2
    If you have the source for the dll just build a lib and use that to link statically? Or do you not have the source for the dll? – Henry B Jan 08 '09 at 12:53
  • Try emailing them, they will probably sell it to you for much less. Or you can ask to buy their old version for 99. – Brian R. Bondy Jan 08 '09 at 12:54
  • @PintSizedCat: I have the source but I have to build a DLL for our native Apps and a LIB for the .NET-Wrapper. – mmmmmmmm Jan 08 '09 at 14:01
  • 1
    IF DLL To Lib would work, then you don't need it. VS is perfectly capable of creating a lib file from your code already. If you can link a .lib file to your .Net project, then do that. My impression, though, was that .Net assemblies cannot be linked to native .lib files. – Rob Kennedy Jan 08 '09 at 15:00
  • "DLL to Lib can work on Window NT 3.1 or later for NT series and Windows 95 or later for Windows 9x series." – tstenner May 10 '11 at 17:06
1

You can generate a dll and export the entry point to a lib using dllexport, this is explained here

http://msdn.microsoft.com/en-us/library/3y1sfaz2.aspx

kiriloff
  • 25,609
  • 37
  • 148
  • 229