search

3F / DllExport

.NET DllExport with .NET Core support (aka 3F/DllExport aka DllExport.bat)
MIT License
937 stars 131 forks source link

How to figure out why the symbol is not visible #224

Open viraptor opened 1 year ago

viraptor commented 1 year ago

I've got projects in VS 2022 which try to export a single function through:

        [DllExport("VirtualChannelEntry", CallingConvention.StdCall)]
        public static bool VirtualChannelEntry(ref ChannelEntryPoints entry)

(type in the signature from https://www.codeproject.com/Articles/16374/How-to-Write-a-Terminal-Services-Add-in-in-Pure-C)

I can load up and successfully build the example "DotNetCoreLibrary3" project and the function is exported as expected (checked with dumpbin /exports)

I compared the options I'm using to the example project and set exactly the same options in mine. (checked in the xml configs too)

I'm failing to see the exported symbol in my DLL though. I've tried new/clean core 6, standard 2 and framework 4.7 projects and none of them create the export. Tried with both debug and release builds. Each one goes through the configuration correctly and compiles successfully with the [DllExport...] attribute resolving and compiling.

How can I figure out what I'm missing here?

The question is related to:

framework project:

Installed: True; 1.7.4+c1cc52f; invoked: 1.7.4
Project type: Cs
Storage: TargetsFile
Compiler.Platform: Auto
Compiler.ordinalsBase: 1
Compiler.rSysObj: True
Compiler.ourILAsm: True
Compiler.customILAsm: 
Compiler.genExpLib: False
Compiler.peCheck: PeIl
Compiler.patches: InfToken
PreProc.Type: None
PreProc.Cmd: 
PostProc.Type: None
PostProc.ProcEnv: $(SolutionPath);$(MSBuildThisFileFullPath)
PostProc.Cmd: 
SignAssembly: 
Identifier: A23570A4-FABA-4276-8A46-CD6C084CA478
Instance: C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Current\Bin\amd64\MSBuild.exe
Project path: C:\Users\vi\source\repos\StreamDeckTransport\StreamDeckTransportClientCsFram\StreamDeckTransportClientCsFram.csproj
Action: Configure
PlatformTarget: 
TargetFramework: 
TargetFrameworks: 
TargetFrameworkVersion: v4.7.2
RootNamespace: StreamDeckTransportClientCsFram
AssemblyName: StreamDeckTransportClientCsFram
MgrArgs: 
MetaLib: tools\raw\lib\net20\DllExport.dll
MetaCor: tools\raw\lib\netstd\DllExport.dll
Proxy: 
StoragePath: .net.dllexport.targets
ddNS: StreamDeckTransportClientCsFram
ddNS max buffer: 500
UseCecil: True
intermediateFiles: False
timeout: 30000
Options: None
RootPath: C:\Users\vi\source\repos\StreamDeckTransport\
PkgPath: C:\Users\vi\source\repos\StreamDeckTransport\packages\\DllExport.1.7.4\
SlnFile: 
SlnDir: C:\Users\vi\source\repos\StreamDeckTransport\
DxpTarget: tools\net.r_eg.DllExport.targets
MsgGuiLevel: -1
LockIfError:
viraptor commented 1 year ago

Hope this helps: If I leave the intermediate objects, I see in Before:

  .method public hidebysig static bool  'VirtualChannelEntry'(valuetype 'Win32.WtsApi32'.'ChannelEntryPoints'& 'entry') cil managed
  {
    .custom instance void ['DllExport']'StreamDeckTransportClientCs'.'DllExportAttribute'::.ctor(string,
                                                                                                 valuetype ['System.Runtime.InteropServices']'System.Runtime.InteropServices'.'CallingConvention') = ( 01 00 13 56 69 72 74 75 61 6C 43 68 61 6E 6E 65   // ...VirtualChanne

And in after:

.method public hidebysig static bool modopt(['mscorlib']'System.Runtime.CompilerServices.CallConvStdcall')  'VirtualChannelEntry'(valuetype 'Win32.WtsApi32'.'ChannelEntryPoints'& 'entry')
  {
    .export [1] as 'VirtualChannelEntry'
    .maxstack  11

So it seems like the method was actually processed... But it's still not visible in the result.

3F commented 1 year ago

Hello,

Make sure you are looking at a modified dll, not original. For your settings it should be inside x64 and x86 folders $(TargetDir)/x64/*.dll

If not, please attach the build log. Thanks.

viraptor commented 1 year ago

🤦 Yes, the x64 directory does contain a file with the correct export. Is there any way I can include that in the published directory as well? It seems that publishing to folder uses the library without the exports in place.

3F commented 1 year ago

Better to reconfigure it for x64 if you only need x64. After that, the modified version will be automatically in $(TargetDir) replacing the original which Publish providers use by default.

But if you need both x86 and x64, for example, add the following before line in .csproj:

<ItemGroup>
   <DllExport86X64 
Include="$(TargetDir)x86\$(TargetFileName);$(TargetDir)x64\$(TargetFileName)" 
PlatformDir="$([System.IO.Directory]::GetParent(%(DllExport86X64.Directory)).Name)\"/>
   <ResolvedFileToPublish Include="@(DllExport86X64)" 
RelativePath="%(PlatformDir)%(Filename)%(Extension)"/>
</ItemGroup>

On 12.05.2023 5:37, Stanisław Pitucha wrote:

🤦 Yes, the x64 directory does contain a file with the correct export. Is there any way I can include that in the published directory as well? It seems that publishing to folder uses the library without the exports in place.

viraptor commented 1 year ago

Awesome, thank you!