DLL Export conflicts with Fody in Visual Studio 2015 #17
Comments
OzzyL
changed the title
|
Update: Unfortunately this is not an option I can use as I need the .pdb files. |
|
Hi again Oscar, This not from DllExport. It also reproduced and for me when Fody is installed even without DllExport. You see this problem from DllExport because our library tried to compile already incorrect IL code. Sample Debug info: Full or pdb only: namespace Sample1
{
internal class ClassA
{
public bool m1()
{
int a, b, c;
return true;
}
}
}this works, but note the .method public hidebysig instance bool
'm1'() cil managed
{
// Code size 7 (0x7)
.maxstack 1
.locals init ([0] int32 'a',
[1] int32 'b',
[2] int32 'c',
[3] bool ) <<<<<<<
.line 6,6 : 9,10 'D:\\tmp\\Sample1\\ClassA.cs'
IL_0000: nop
.line 9,9 : 13,25 ''
IL_0001: ldc.i4.1
IL_0002: stloc.3 <<<<<<< ok
IL_0003: br.s IL_0005
.line 10,10 : 9,10 ''
IL_0005: ldloc.3 <<<<<<< ok
IL_0006: ret
}
Now, when failed (by short forms - 0x13 and 0x11): just define new var int a, b, c, d; // >>> d because:
.method public hidebysig instance bool
'm1'() cil managed
{
// Code size 9 (0x9)
.maxstack 1
.locals init ([0] int32 'a',
[1] int32 'b',
[2] int32 'c',
[3] int32 'd',
[4] bool ) <<<<<<
.line 6,6 : 9,10 'D:\\tmp\\Sample1\\ClassA.cs'
IL_0000: nop
.line 9,9 : 13,25 ''
IL_0001: ldc.i4.1
IL_0002: stloc.s <<<<<< incorrect*
IL_0004: br.s IL_0006
.line 10,10 : 9,10 ''
IL_0006: ldloc.s <<<<<< also here
IL_0008: ret
}
another interesting without debug info (as you already noticed) it generated correctly: .locals init (int32 V_0,
int32 V_1,
int32 V_2,
int32 V_3,
bool V_4) <<<<<
IL_0000: nop
IL_0001: ldc.i4.1
IL_0002: stloc.s V_4 <<<<<
IL_0004: br.s IL_0006
IL_0006: ldloc.s V_4 <<<<<
IL_0008: ret
}Therefore, you need to report about this bug there https://github.com/Fody |
|
Thanks for your detailed analyze! |
|
I think we need to provide own ILDasm / ILAsm anyway (to try) probably v4.5.22220 works fine, but in general the ILDasm / ILAsm it's only wrapper (i.e. front-end to coreclr.dll and its dependencies ...) TODO: to look temporarily, try with version 4.5.22220 |
|
I uploaded latest binaries here: 3F/coreclr#1 |
…#17 GUI Configurator + MSBuild property: DllExportOurILAsm
|
ce2536e - should fix this problem
via MSBuild Properties: <DllExportOurILAsm>true</DllExportOurILAsm> |
|
I can confirm that ce2536e solves the issue. |
I recommend to wait public release, because I'm not sure about solution above for this problem: maybe you know ? what's license for cvtres.exe (Windows Resource To Object Converter) ? or free alternative to compile .res -> obj COFF-format (that will be placed in .rsrc section (PE)) ? |
```
* FIXED: Fixed using of cvtres (.res -> obj COFF-format) in mscorpe.
Possible crash: #2
Related Issue: 3F/DllExport#17
* NEW: Implemented additional searching of the converters of resources:
Environment PATH, local directory, and other additional from user path.
Now it also can be wrapped like ` mytool.cmd -> cvtres.exe %* ` etc.
* NEW: Added new /CVRES (/CVR) key to ilasm.exe
`/CVRES=<path_to_file> Set path to cvtres tool: /CVR=cvtres.exe /CVR=tool\cvtres.cmd /CVR=D:\tool\`
* NOTE: based on 4.5.22220.0 / coreclr 1.0.4
^ ^ ^ ^
| | | |-- VER_FILEVERSIONREVISION
| | |------- VER_FILEVERSIONBUILD
| |---------- VER_FILEVERSIONMINOR
|------------ VER_MAJORVERSION
```
…h cvtres #17 Related Issue for coreclr: 3F/coreclr#2
|
I released new version of coreclr for DllExport project: and already updated logic for this issue (more correct now). You can test this from - 5203d82 |
* FIXED: Fixed problem with white-space chars in path: `Cannot find path '<any full path with spaces>' because it does not exist ...`
* FIXED: Fixed typo with fullseq (ddNS) - incorrect `0x30 0x30` ~0x007A7-0x007A8 /details in #14
* FIXED: Possible problem with NullReferenceException when removing package.
* FIXED: Fixed problem with old NS data when we try to install package for project A, then for project B
* NEW: Implemented 'Generate .exp + .lib via MS Library Manager' #9
GUI Configurator + MSBuild property: `DllExportGenExpLib`
* NEW: Added support of unmanaged-export for Executable Modules (.exe) #18
* NEW: Cecil variant for ddNS features /#14, #2
* NEW: Added our custom IL Assembler as option to fix incorrect 0x13 / 0x11 opcodes. #17
GUI Configurator + MSBuild property: `DllExportOurILAsm`
It should help for users of Fody projects, etc.
Fody/Fody#271
IlAsm 4.5.1 https://github.com/3F/coreclr
based on 4.5.22220.0 / coreclr 1.0.4
changelog of our coreclr for this release: https://github.com/3F/coreclr/blob/master/changelog.txt
* CHANGED: Updated scripts of installing/removing package for more correct loading of our assemblies.
|
@3F any plans to merge back your changes to CoreCLR upstream or you plan to keep your own version? |
|
@denfromufa probably yes, later. Because part of my changes should be useful even for main CoreCLR, but mainly it was specially for DllExport so I will look into later. I've also plan to reconsider PE modifications at all, because ILAsm version on coreclr have a lot of limitations instead of full native version. However ! old ILDasm v4.5.22220.0 initially does not contain this problem as it described above. And anyway, this changes should not affect on full version of ILDasm/ILAsm. my new illustration of this problem here (please note, as I see, this is not related for DllExport project at all): Fody/Fody#271 (comment) ...
**1304** & **1104** are correct instructions ...
/* 0x000002A1 17 */ IL_0001: ldc.i4.1
/* 0x000002A2 1304 */ IL_0002: stloc.s 4
/* 0x000002A4 2B00 */ IL_0004: br.s IL_0006
/* 0x000002A6 1104 */ IL_0006: ldloc.s 4
full body: `133001000900000002000011 -> 001713042B0011042A`
/* 0x00000495 17 */ IL_0001: ldc.i4.1
/* 0x00000496 1304 */ IL_0002: stloc.s V_4
/* 0x00000498 2B00 */ IL_0004: br.s IL_0006
/* 0x0000049A 1104 */ IL_0006: ldloc.s V_4
full body: `133001000900000003000011 -> 001713042B0011042A`
i.e. the main difference - .locals def
...Unfortunately I have no access to source code of full version ILDasm so it's hard for my time to say what's going on, but in general, anyone else should look Fody project in this chain as I said before. |
|
As I am right, that custom CoreCLR build required only at build time, but at runtime we can use genuine CoreCLR 2.0 ? |
|
We're using this only for PE-modification of final modules (.exe/.dll), i.e. as an post-processing of build through reassembling IL code. Also the using of custom ILAsm\ILDAsm (on coreclr) should be only when option |
|
|
1 & 2: It depends on coreclr implementation that should finally process the requests from unmanaged layer, read this: #45 (comment) - i.e. note again, clr environment is a core handler of this mechanism, while the final part of our modifications will be processed through mscorpe that will not to do anything except headers. 3: I have not yet considered coreclr for DllExport and have no plan to try support this at least in the next few months. It should be possible anyway, but seems not with current coreclr implementation. |
I recently upgraded from Visual Studio 2013 to 2015 and my projects where I used both DLL Export and Fody (More specifically ModuleInit.Fody) stopped working.
I have tried the same project on different computers with different versions of Visual Studio 2015. Same issue on all computers.
It seem as i can't use DLL Export together with Fody (e.g. ModuleInit). Both tools works great separately, but when both is included in a project the build fails.
The build error I get:
Using detailed buildlog I can see the following errors:
I have tried both DLLExport v.1.2.7 and 1.4.0. Same issue with both.
I have also tried multiple versions of Fody. No difference.
A snippet from the generated .il file:
The source code of the function that fails looks like this:
The failing line is "return true;" if I read the output correctly.
Best Regards
Oscar
The text was updated successfully, but these errors were encountered: