Exported name mismatched #129
Comments
|
nice catch for 1h ago released version :) I can't even imagine where this broken part if cdecl ok. Is this reproducible for prev beta?
I'll look into later, just 3 AM on my watch. Thanks for the report!
**edited: removed ....email_token=AAYYT7NQFORCMBXZIENOFN3QY...
Why github brokes my mails sometimes?
|
|
Sorry, I made a mistake. It seems that the bug is related to [DllExport("test123")] // Correct
[DllExport("test123", CallingConvention.Cdecl)] // Incorrect
[DllExport("test123", CallingConvention = CallingConvention.Cdecl)] // IncorrectPrevious version is ok. |
3F
added a commit
that referenced
this issue
Dec 14, 2019
|
@Executor-Cheng, Please confirm fixes using the following CI build: https://ci.appveyor.com/project/3Fs/dllexport-ix27o/builds/29539703/artifacts I'll try to prepare new release ASAP. |
|
Great! The problem has been solved! Thank you for your quick fix :) |
3F
added a commit
that referenced
this issue
Dec 15, 2019
* FIXED: Mismatch of the name of the exported function with the specified value.
Issue #129.
* FIXED: Unchangeable cdecl convention. Part of Issue #129.
* FIXED: Fixed possible duplication of `DllExportSysObjRebase` during setup.
* NEW: Implemented "Single + Double Inf/-Inf token patching" option.
Related Issue #128.
* KNOWN: You can finally get another System.Object in modified assembly:
#90 (comment)
* NOTE: Please don't use beta releases in production!
* NOTE: Please report about something here: https://github.com/3F/DllExport/issues
|
Done. Please use Beta3 release. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Using v1.7-beta2, checked
Use our IL Assembler, TargetFramework=netcoreapp3.1, the following method will be exported as "Test", not "test123".But if I use
CallingConvention.Cdecl, the exported name will be "test123".The text was updated successfully, but these errors were encountered: