0

I have a VS solution with:

  1. native C++ DLL
  2. console test client using 1.
  3. C# wrapper for 1.
  4. C# client using 1. via 3.

In order to have VS copy all DLLs required by each client, of course I am aware I can manually set post-build actions. However I have found that simply adding project "references" works great automatically, at least within one single language. I'm having trouble making it work when the .NET client depends on the purely native C++ library (via the wrapper).

If I "add reference" project 1. to project 2. VS takes care of copying the DLL around without my needing to set any post-build actions. Also by adding 3. as reference to 4. However 4. needs of course also 1., but VS won't let me add a purely native C++ project as reference into a .NET project -- I assume that's the cause, or at least in this case it complains that "a reference could not be added."

Perhaps a solution could be to combine 1. and 3. into a mixed DLL, but that isn't acceptable for us. Even if this DLL could be compatible with native C++ clients, I need to separate the wrapper because the use of C# isn't even approved by my company's standards, the .NET client is just a quick prototype.

The difficulty seems to originate from an incompatible way of working regarding folders VS has in C++ and C#. When I debug C++ project 2., it runs from a folder directly within the solution folder instead of the folder of project 2. But when I debug C# project 4., it runs from a folder within the folder of project 4. The up-to-date DLL from project 3. is always found there thanks to the reference, but not the DLL from project 1. which is also needed. If the C# project were debugged from the solution folder instead, it would indeed happen to find an up-to-date DLL from project 1., but not this way.

Any solution provided by VS besides a custom post-build action? Thanks in advance.

J.P.
  • 350
  • 2
  • 11
  • 1
    MSBuild depends on the content of a managed assembly to find out what other managed assemblies it depends on. That cannot work for the native C++ DLL, it is not listed since it is not managed. It is therefore up to you to copy it. Sure, a post-build event works fine. – Hans Passant Feb 25 '16 at 16:30
  • Thanks for the extra clarification. I have however found another way, from this answer http://stackoverflow.com/a/13944692/3419420 It does work, and it shows in the solution explorer once the .csproj is edited manually and reloaded. One should add multiple ItemGroups with Condition attributes to handle path differences in Debug/Release/x64/x86 etc. – J.P. Feb 26 '16 at 09:38

0 Answers0