Build successful but methods are not exported

[bbartels]

How to reproduce

Open Solution in VS and build.

Build is successful and build log indicates that the Exported methods are assembled correctly, though when using dumpbin they do not show up.

Code repository: https://github.com/bbartels/K8055Simulator/tree/DLLExportIssues

What version and selected configuration ?

DLLExport.1.5.2

Can you provide detailed log of your build ?

https://pastebin.com/gUBpwPVv

I am in the middle of porting my project from R.Giesecke's UnmanagedExports to DLLExport.1.5.2, didn't have an issue with UnmanagedExports. (Except not being able to find ILdasm at times, which is the reason why I am porting)

[3F]

Did you try latest v1.6-RC ? 29.11.2017 3:28, Benjamin Bartels пишет:

…

How to reproduce Open Solution in VS and build. Build is successful and build log indicates that the Exported methods are assembled correctly, though when using dumpbin they do not show up. Code repository: https://github.com/bbartels/K8055Simulator/tree/DLLExportIssues What version and selected configuration ? DLLExport.1.5.2 Can you provide detailed log of your build ? https://pastebin.com/gUBpwPVv — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#59>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADGJ_RSeRt4yV9qP3gD8TOJy20J8_KtRks5s7KUygaJpZM4QuPHW>.

[Genteure]

From the log, it seems some methods got successful exported.
Which reminds me of about a month ago, I had a similar problem.

I have a project that has two source file contains methods need to export.
One of them successful export every time I build, the other one doesn't get exported every time.
I checked build result using dnSpy, the DllExport Attribute didn't get removed.

I was able to find a kind simple solution: just change the order of Compile ItemGroup in the csproj file so the compiler compiles source files in a different order. which somehow magically solved the problem.

Not sure if is the same problem, but you can give a try.

[3F]

1.6-RC also provides PE-checking via $(DllExportPeCheck) - #55 (comment)

• 0x01 bit - Will check count of all planned exports from final PE32/PE32+ module.
• 0x02 bit - Will check existence of all planned exports (IL code) in actual PE32/PE32+ module.

just change the order of Compile ItemGroup in the csproj file so the compiler compiles source files in a different order.

@Genteure can you try to reproduce this problem for RC + our IL Asm ? I will look into later if it still...

[bbartels]

@3F I have tried the 1.6 Beta but haven't tried the RC yet. Will do so as soon as I can.

[Genteure]

@3F You can check out my repository, I pushed 3 new branches with build log and result binary.

dllexport-16b2

Current working example, everything works fine.

dllexport-16b2-bug

Default build order, methods in Main.cs doesn't get exported.

dllexport-16rc

Default build order with DllExport 1.6.0-RC, methods in Main.cs doesn't get exported.

[3F]

@Genteure Thanks for the detailed info ! I will look this as soon as possible.

By the way, what your system locale ? it seems you have incorrect layout :( a little bit, but...

[Genteure]

My system locale is zh_CN Simplified Chinese, on Windows 10.
I changed my Visual Studio's language to English so msbuild log is in English.

[3F]

@Genteure Good, I'll try your locale in VM :)

Wizard here if you want to help: https://github.com/3F/DllExport/tree/master/Wizard

[3F]

@Genteure

well, yes 1.6-RC indicates 2 errors when PE-checking is used (your branch dllexport-16rc):

RunIlAsm: Something went wrong. We can't find '2' exports from PE32/PE32+ module '\com.genteure.cqp.whatanime\bin\Debug\com.genteure.cqp.whatanime.dll': _eventEnable ; _eventGroupMsg	com.genteure.cqp.whatanime	\packages\DllExport.1.6.0-RC\tools\net.r_eg.DllExport.targets		
RunIlAsm: The number (2) of exports from PE32/PE32+ module '\com.genteure.cqp.whatanime\bin\Debug\com.genteure.cqp.whatanime.dll' is not equal to number (4) from IL code.	com.genteure.cqp.whatanime	\packages\DllExport.1.6.0-RC\tools\net.r_eg.DllExport.targets		

And I've found the following problem from your code. The problem mainly because of another decompiled view of extern methods (where DllImport attr) from your NativeMethods static class:

  .class abstract auto ansi sealed nested private beforefieldinit 'NativeMethods'
         extends ['mscorlib']'System'.'Object'
  {
    ...
    .method public hidebysig static pinvokeimpl("CQP.DLL" winapi) 
            string  'CQ_getRecord'(int32 'AuthCode',
                                   string 'File',
                                   string 'Format') cil managed preservesig
    {
    }
    ...

In general, we have incorrect nesting level of subclasses because of our current logic via stack-based levels.

Well, need to think...

While I'm thinking, you can also try https://github.com/3F/Conari that generates binding at runtime, and moreover...

[3F]

@bbartels I've also checked your bbartels/K8055Simulator@2cbbe82 and for v1.6-RC I have no problems:

x64:

00000001	0003EB9E	0000	0004022A	OpenDevice
00000002	0003EBAA	0001	0004021E	CloseDevice
00000003	0003EBB6	0002	00040276	ReadAnalogChannel
00000004	0003EBC2	0003	00040259	ReadAllAnalog
00000005	0003EBCE	0004	000401F7	ClearAnalogChannel
00000006	0003EBDA	0005	000401D8	ClearAllAnalog
00000007	0003EBE6	0006	00040245	OutputAnalogChannel
00000008	0003EBF2	0007	00040235	OutputAllAnalog
00000009	0003EBFE	0008	00040300	SetAnalogChannel
0000000A	0003EC0A	0009	000402E5	SetAllAnalog
0000000B	0003EC16	000A	000401E7	ClearAllDigital
0000000C	0003EC22	000B	0004020A	ClearDigitalChannel
0000000D	0003EC2E	000C	000402F2	SetAllDigital
0000000E	0003EC3A	000D	0004033E	SetDigitalChannel
0000000F	0003EC46	000E	00040367	WriteAllDigital
00000010	0003EC52	000F	000402AC	ReadDigitalChannel
00000011	0003EC5E	0010	00040267	ReadAllDigital
00000012	0003EC6A	0011	000402A0	ReadCounter
00000013	0003EC76	0012	000402D8	ResetCounter
00000014	0003EC82	0013	00040327	SetCounterDebounceTime
00000015	0003EC8E	0014	00040350	SetDigitalInputChannel
00000016	0003EC9A	0015	000402BF	ReadDigitalOutputChannel
00000017	0003ECA6	0016	00040311	SetAnalogInputChannel
00000018	0003ECB2	0017	00040288	ReadAnalogOutputChannel

[3F]

Ok, I've plan to view this problem later, after planned v1.6 (should be released for this month).

For today, anyone else may also try to use https://github.com/3F/Conari to avoid similar @Genteure's problem.

[3F]

Fixed and included in planned v1.6.1

Use CI-Build-92 for tests.