`DllExportOurILAsm` causes project to always appear dirty and require build

[nitz]

Steps to reproduce:

• Download attached solution, extract, open.
• Issue build solution command to get fresh builds of all projects.
• Issue build solution command again, observe behavior.

• DllExport -version: v1.7.4.29858+c1cc52f
• Used Visual Studio / MSBuild: MSVS 17.1.0 / MSBuild 15.9.21+g9802d43bc3

Information from Data tab for LibFoo:

Installed: True; 1.7.4+c1cc52f; invoked: 1.7.4
Project type: CsSdk
Storage: ProjectFiles
Compiler.Platform: Auto
Compiler.ordinalsBase: 1
Compiler.rSysObj: False
Compiler.ourILAsm: True
Compiler.customILAsm: 
Compiler.genExpLib: False
Compiler.peCheck: PeIl
Compiler.patches: None
PreProc.Type: None
PreProc.Cmd: 
PostProc.Type: None
PostProc.ProcEnv: $(SolutionPath);$(MSBuildThisFileFullPath)
PostProc.Cmd: 
SignAssembly: 
Identifier: B2B68504-BE59-4B4A-8CEA-9C3E3A6C51F6
Instance: C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\amd64\MSBuild.exe
Project path: C:\Users\cmd\source\repos\AlwaysDirtyIssue\LibFoo\LibFoo.csproj
Action: Configure
PlatformTarget: x64
TargetFramework: netstandard2.0
TargetFrameworks: 
TargetFrameworkVersion: 
RootNamespace: 
AssemblyName: 
MgrArgs: 
MetaLib: tools\raw\lib\net20\DllExport.dll
MetaCor: tools\raw\lib\netstd\DllExport.dll
Proxy: 
StoragePath: .net.dllexport.targets
ddNS: LibFoo
ddNS max buffer: 500
UseCecil: True
intermediateFiles: False
timeout: 30000
Options: None
RootPath: C:\Users\cmd\source\repos\AlwaysDirtyIssue\
PkgPath: C:\Users\cmd\source\repos\AlwaysDirtyIssue\packages\\DllExport.1.7.4\
SlnFile: 
SlnDir: C:\Users\cmd\source\repos\AlwaysDirtyIssue\
DxpTarget: tools\net.r_eg.DllExport.targets
MsgGuiLevel: -1
LockIfError: 

Information from Data tab for LibBar:

Installed: True; 1.7.4+c1cc52f; invoked: 1.7.4
Project type: CsSdk
Storage: ProjectFiles
Compiler.Platform: Auto
Compiler.ordinalsBase: 1
Compiler.rSysObj: False
Compiler.ourILAsm: False
Compiler.customILAsm: 
Compiler.genExpLib: False
Compiler.peCheck: PeIl
Compiler.patches: None
PreProc.Type: None
PreProc.Cmd: 
PostProc.Type: None
PostProc.ProcEnv: $(SolutionPath);$(MSBuildThisFileFullPath)
PostProc.Cmd: 
SignAssembly: 
Identifier: D0933B3C-5336-4CFD-B255-303678C9FCE1
Instance: C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\amd64\MSBuild.exe
Project path: C:\Users\cmd\source\repos\AlwaysDirtyIssue\LibBar\LibBar.csproj
Action: Configure
PlatformTarget: 
TargetFramework: netstandard2.0
TargetFrameworks: 
TargetFrameworkVersion: 
RootNamespace: 
AssemblyName: 
MgrArgs: 
MetaLib: tools\raw\lib\net20\DllExport.dll
MetaCor: tools\raw\lib\netstd\DllExport.dll
Proxy: 
StoragePath: .net.dllexport.targets
ddNS: LibBar
ddNS max buffer: 500
UseCecil: True
intermediateFiles: False
timeout: 30000
Options: None
RootPath: C:\Users\cmd\source\repos\AlwaysDirtyIssue\
PkgPath: C:\Users\cmd\source\repos\AlwaysDirtyIssue\packages\\DllExport.1.7.4\
SlnFile: 
SlnDir: C:\Users\cmd\source\repos\AlwaysDirtyIssue\
DxpTarget: tools\net.r_eg.DllExport.targets
MsgGuiLevel: -1
LockIfError: 

Project Sample

AlwaysDirtyIssue.zip - Reproduction solution w/3 projects:

• LibMain: A class library that references the other two libraries. (To show that dirty rebuilds causes cascades.)
• LibFoo: A class library with DllExports using "ourILAsm".
• LibBar: A class library with DllExports not using "ourILAsm".

Details

The only difference between LibFoo and LibBar should be the setting of DllExportOurILAsm. When issuing "build solution", LibBar behaves as expected, only building & running build events when changes are made. By comparison, LibFoo invokes a portion of the build process (including post build events, DllExport, etc.) every time.

Comparing the output from msbuild between the two projects, LibFoo's output has only a single line of output that LibBar's doesn't:

Copying file from "<sln dir>\LibFoo\obj\x64\Debug\netstandard2.0\LibFoo.pdb" to "<sln dir>\AlwaysDirtyIssue\LibFoo\bin\x64\Debug\netstandard2.0\LibFoo.pdb".

My guess is that, because DllExport deletes the PDB when using "Our IL Asm" since it isn't valid, msbuild thinks the project needs to build because the expected output file is missing.

If one day "Our IL Asm" ever does re-gain the feature of being able to produce PDBs, this issue would be solved. In the meantime, perhaps there's someway to indicate to msbuild that it shouldn't expect to find the PDB?

Cheers!

[3F]

Thanks for the detailed report!

My guess is that, because DllExport deletes the PDB when using "Our IL Asm"

Yes, I remember this logic programmed due to possible incorrect ISymUnmanagedWriter for non-modified asm.
And more like, yes, this can really invalidate some nodes in msbuild -_-

Good catch! Need to check it but I literally don't even know how to live in the coming months at all, thus no ETA. Sorry.

[nitz]

I literally don't even know how to live in the coming months at all, thus no ETA. Sorry.

No worries; this is just something I wanted to get on the books with details before I forgot, and more than that it's a totally non blocking issue! Life always takes priority. Please take care of yourself!

[crusader-mike]

@3F Any progress/luck wrt this issue? I just came across it... In fact, for some unknown reason, .pdb file gets deleted in Release build regardless of DllExportOurILAsm value.

[3F]

@crusader-mike

Any progress/luck wrt this issue?

My luck is gone when my opensource activities was stopped/paused. Yet no opportunity to review the issue somehow, later or not I don't know either. Sorry. But who cares.

for some unknown reason

Above,

Stub was programmed due to ISymUnmanagedWriter because it produces incompatible format anyway
https://github.com/3F/coreclr/blob/05afa4f81fdf671429b54467c64d65cde6b5fadc/src/debug/ildbsymlib/symwrite.cpp#L308
while adding a bunch of other problems together with modified modules at runtime, as far as I remember.

[3F]

So, I finally looked into this issue.

My guess is that, because DllExport deletes the PDB when using "Our IL Asm" since it isn't valid

No. MSBuild invalidates the target module because it is literally not relevant to the intermediate (obj); because it was modified (DllExport) because you decided to do it. And here is very important point,

Today's DllExport provides 4 possible options to configure target platform for your projects:
1. x86
2. x64
3. x86+x64
4. Auto - relies on user configuration

While x86+x64 option generates final modified modules inside separate subfolders (x86 and x64 respectively), x86 and x64 replaces the original; yes, that's it.

After that, take a look closer CoreCompile target:

• LibFoo: Skipping target "CoreCompile" because all output files are up-to-date with respect to the input files.
• LibBar: Skipping target "CoreCompile" because all output files are up-to-date with respect to the input files.
• LibMain:
  • Building target "CoreCompile" completely. Input file "<...>\LibFoo.dll" is newer than output file "obj<...>\LibMain.dll".
  • (or*) Building target "CoreCompile" completely. Input file "<...>\LibBar.dll" is newer than output file "obj<...>\LibMain.dll".
    *depending on build priorities and/or configurations since one of the invalidation is enough to run related targets.

Well, I added a new option to refresh intermediate module (obj) using modified, i.e. vice versa. That is, in future versions you will be able to configure it like:

Check this out using related CI build until public release.

But here it is also important to understand that we are validating this vice versa, as I noted above. That's why I recommend x86+x64 (moreover, it should work in in current versions) in order to get the most well known behavior.

Let me know if the problem is still not solved.