1

I'm writing a DLL using C# which will be accessed from a Delphi windows app, and have hit the issue re exporting the classes/methods. No matter what I try nothing appears to be getting exported.

I've created a test DLL using the documented method presented by Hans Passant in this question re UnmangedExports.

I've created a C# class library project with the following code:

namespace ExportTestCS
{
  public class ExpTest
  {
    public static void Test()
    {
      Console.WriteLine("Hi!");
    }
  }
}

and a C++ 'wrapper' to do the export:

extern "C" __declspec(dllexport)

void  __stdcall Test()
{
    ExportTestCS::ExpTest::Test();
}

The C++ project references the C# project and it all builds OK, but when I run dumpbin /exports on the DLL there is nothing exported:

dumpbin /exports C:\Temp\ExportTest\ExportTestCS\Release\ExportTest.dll

Dump of file C:\Temp\ExportTest\ExportTestCS\Release\ExportTest.dll

File Type: DLL

  Summary

        2000 .reloc
        2000 .rsrc
        2000 .text

C:\Program Files (x86)\Microsoft Visual Studio 14.0>

I've run dumpbin against all the dll's produced by the build for both debug and release and they all give the same result.

My question therefore is - what am I doing wrong? I've spent ages trawling round similar questions but they all seem to be resolved using the C++ wrapper or UnmangedExports.

Both projects are building for x86/win32 and have the same target framework (4.5.2). I've tried various combinations of static classes, no classes, __clrcall/__stdcall etc., etc. but to no avail.

I also previously tried the UnmanagedExports NuGet package without success (that's how I found Hans' answer).

Thanks in advance for any help!

Following all the comments (thanks!) I've confirmed that it's a dynamic library project and I've created a new folder in the C++ project and set that as the output folder. The build now puts the .lib, .exp, .pdb, .dll and .dll.metagen files into that folder, and that is the reported folder in the output tab when building. But still no joy, the output from dumpbin is the same as ever!!

When I run dumpbin against the .lib file in the new output folder I get this:

Dump of file C:\Temp\ExportTest\ExportTestCPP\ExportTest\Output\exporttest.lib

File Type: LIBRARY

     Exports

       ordinal    name

                  _Test@0

  Summary

          CC .debug$S
          14 .idata$2
          14 .idata$3
           4 .idata$4
           4 .idata$5
          10 .idata$6

C:\Program Files (x86)\Microsoft Visual Studio 14.0>

So it looks like the .lib is exporting the Test method but it is not in the final DLL?

Community
  • 1
  • 1
Mick
  • 141
  • 9
  • 1
    Surely you are running Dumpbin.exe on the wrong DLL, given that it is inside the ExportTestCS directory. You have to run it on the DLL that's generated by your C++ project. You will also have to make sure that *both* DLLs can be found by your test project. – Hans Passant Jun 16 '16 at 16:44
  • Long shot - have you set [assembly: ComVisible(true)] from [assembly: ComVisible(false)] in the AssemblyInfo? – Murray Foxcroft Jun 16 '16 at 16:46
  • I searched the project folders for all .dll files and they only exist in the C# project? I'll try the AssemblyInfo setting and see if that makes a difference. – Mick Jun 16 '16 at 17:30
  • OK - I found the AssemblyInfo settings (I'm a complete newby to C++!) and changed the ComVisible to true (it was false) - but it made no difference. I'm wondering if it's some other config setting that is preventing the C++ project from generating a DLL? – Mick Jun 16 '16 at 17:45
  • @Hans @Murray Not sure if this will help - here's the contents of ExportTest.log from the C++ build: `Stdafx.cpp AssemblyInfo.cpp ExportTest.cpp Generating Code... .NETFramework,Version=v4.5.2.AssemblyAttributes.cpp Creating library C:\Temp\ExportTest\ExportTestCS\Release\ExportTest.lib and object C:\Temp\ExportTest\ExportTestCS\Release\ExportTest.exp ExportTest.vcxproj -> C:\Temp\ExportTest\ExportTestCS\Release\ExportTest.dll ExportTest.vcxproj -> C:\Temp\ExportTest\ExportTestCS\Release\ExportTest.pdb (Full PDB)` – Mick Jun 16 '16 at 17:52

2 Answers2

1

I just tried your example and it worked for me when I ran dumpbin on the C++ dll, but gave the same result as yours when I ran it against the C# dll.

Dump of file C:\Temp\ExportTest\ExportTestCS\Release\ExportTest.dll

Is that your C# assembly?

leetibbett
  • 843
  • 4
  • 16
  • Yes it is my C# assembly - there is no .dll file in the C++ directories? – Mick Jun 16 '16 at 17:29
  • You can see the output folder for your C++ DLL in the output window right after you build. That folder should contain both the C# assembly and the C++ DLL. – leetibbett Jun 16 '16 at 21:13
  • Perhaps you selected static library instead of dynamic? – leetibbett Jun 16 '16 at 21:23
  • See above re output directories/dlls. There are three dll's produced each time I build and they are in the ...\release ...bin\release ...obj\release folders in the C# project. There are no DLL's anywhere else across all of the project folders. How can the C# assembly and the C++ DLL be in the same folder? They would have the same name wouldn't they? – Mick Jun 17 '16 at 07:10
  • I just checked and it's definitley a 'dynamic' library project. I think it must be a project setting though because the code appears to work for everyone else! – Mick Jun 17 '16 at 07:12
  • They should not have the same name, that would not work in a real project. The C++ project builds into a folder where the solution is located, not the project folder. Try looking for a Release folder next to your .sln file. – leetibbett Jun 17 '16 at 21:12
0

The problem must have been in the way I'd set the projects up. I started again from scratch and it all worked ok.

When I set the original ExportTest projects up I unintentionally created a Windows Universal class library for the C# project, and although I realised and changed it to a standard windows class library project (deleted the original and created a new one) I believe it must have left something behind in the solution configuration that prevented the DLL from exporting.

Many thanks to all who answered/commented!

Mick
  • 141
  • 9