How to debug?

[CoenraadS]

Hello

Apologies for yet another issue, I did search first but didn't see this one yet.
Closest I found was #164 but it's not my problem
Maybe related to 3F/coreclr#3?
. . .

The question is related to:

• DllExport -version:1.7.4
• Copy-paste from Data tab:

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: 9CDCCAD3-44FB-4AB5-89DD-73FF014FFD47
Instance: C:\Program Files\Microsoft Visual Studio\2022\Preview\MSBuild\Current\Bin\amd64\MSBuild.exe
Project path: C:\Users\asdf\Documents\Projects\asdf\asdf\Installer\Dotnet\Dotnet\Dotnet.csproj
Action: Configure
PlatformTarget: x86
TargetFramework: net472
TargetFrameworks: 
TargetFrameworkVersion: 
RootNamespace: Installer.Dotnet
AssemblyName: 
MgrArgs: 
MetaLib: tools\raw\lib\net20\DllExport.dll
MetaCor: tools\raw\lib\netstd\DllExport.dll
Proxy: 
StoragePath: .net.dllexport.targets
ddNS: Installer.Dotnet
ddNS max buffer: 500
UseCecil: True
intermediateFiles: True
timeout: 30000
Options: None
RootPath: C:\Users\asdf\Documents\Projects\asdf\asdf\Installer\Dotnet\
PkgPath: C:\Users\asdfDocuments\Projects\asdf\asdf\Installer\Dotnet\packages\\DllExport.1.7.4\
SlnFile: 
SlnDir: C:\Users\asdfDocuments\Projects\asdf\asdf\Installer\Dotnet\
DxpTarget: tools\net.r_eg.DllExport.targets
MsgGuiLevel: -1
LockIfError: 

---

Hi

When I try to debug my project with DLLExport function from a unit-test, Visual Studio asks me to locate the {projectName}.il file?

Any idea how I can resolve this?

[3F]

Compiler.rSysObj: False
Compiler.ourILAsm: False
Compiler.customILAsm: 
...
TargetFramework: net472

No, this is not related to 3F/coreclr#3

Did you try to set debugger type at least to Mixed? You can also note this in my old screencasts on youtube

Also make sure .pdb is located near final/modified assembly. That is, same to $(TargetDir) because of selected x86 but $(TargetDir)\x86 for x86+x64

[CoenraadS]

Hi, when I remove the nuget package it debugs normally hence I think it's related. Dll and pdb are in same folder, but the error isn't that it can't find the pdb. Not really sure what else I can try to debug this issues

…

On Sun, Feb 20, 2022, 6:18 PM Denis Kuzmin ***@***.***> wrote: Compiler.rSysObj: False Compiler.ourILAsm: False Compiler.customILAsm: ... TargetFramework: net472 No, this is not related to 3F/coreclr#3 <3F/coreclr#3> Did you try to set debugger type at least to Mixed? You can also note this in my old screencasts on youtube Also make sure .pdb is located near final/modified assembly. That is, same to $(TargetDir) because of selected *x86* but $(TargetDir)\x86 for *x86+x64* — Reply to this email directly, view it on GitHub <#204 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABKVVYM5YJZITMTG4EJO2YTU4EO6FANCNFSM5O4SB74A> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[3F]

Hi, @CoenraadS

Can you clarify the following,

1. Where is entry point for both cases? From unmanaged/native side?
2. What actual value for debugger type?
3. Can you also reproduce this behavior from scratch in empty project?
4. Please attach build log if possible

Thanks

[CoenraadS]

Hi, so I have enabled mixed-mode debugged on both my project and the unit test project, to no avail. Tried both VS2019 & 2022

1. EntryPoint is from managed unit-test, then calling (still managed), a function with [DLLExport] defined. When I try to step into the function is asks for this .il file.

2. This is no value? I did not manage to step into the function

3. I attached empty project, just try to step into the function from the test project
   ClassLibrary1.zip

I noticed it also happens to functions without [DllExport] attribute, as long as it's present on at least one function, all functions become undebuggable

[3F]

Looks like a bug for x86 and individual x64 configurations.

Meanwhile this works well for "x86+x64". Check this out.

This is no value?

My mistake, my thoughts were about C++ projects ~ e.g. available debugger types to use:

[CoenraadS]

Do you mean change PlatformTarget from x86 to AnyCPU?

Unfortunately I am interfacing with a 32 bit application and then the bindings break.

[3F]

No. It will just produce both x86 and x64 modules in individual folders (i.e. $(TargetDir)\x86 and $(TargetDir)\x64).
There is nothing incompatible for your task. You need only select "x86+x64" when configuring, then Apply. It should help until fix.

[CoenraadS]

Thanks for your patience, it is working now, at least from the unit test.

I tried a remote-debug situation, but then received {projectName}.x86.il not found. However I could continue with Decompile source code which while not perfect, is already much better then having nothing.

[3F]

at least from the unit test

Can you describe steps for a "remote-debug situation" because "x86+x64" should work for other cases too, like manual attaching to process (just checked it) for debugger or other entering from some executable modules.

[CoenraadS]

InnoSetupExample.zip

ClassLibrary1\bin\Debug\net472\win-x86\x86\CodeDll.iss

Hi, I think the easiest way to reproduce is to run it from InnoSetup

I made a minimal example, just run the script from InnoSetup and it will automatically launch the debugger and give the .il error

[3F]

Although the issue was closed, but for clarity: this is not a bug (the label I changed in the past)
If we're not talking about the Publish target for single x86 and x64 that was fixed along with #235

For the current issue you need set DebugType=full (or pdbonly that's almost the same). That's all.

n. x86 or x64 or x86+x64
For example,

• Your ClassLibrary1.zip is debuggable at runtime for all cases and platforms, from unit-test host, from other modules (managed and unmanaged calls)
• Your InnoSetupExample.zip, same, just don't use a portable pdb;

I checked both of your projects; The same old version 1.7.4, nothing changed. Works well.

Thanks for the demo projects you prepared! it helped me check the issue for a few minutes, although this whole check took almost 3 years, well...