DllExport icon indicating copy to clipboard operation
DllExport copied to clipboard

How to chain link C# Dlls?

Open mea05pb opened this issue 2 years ago • 5 comments

. . .

The question is related to:

  • DllExport -version: 1.74
  • Copy-paste from Data tab: Installed: True; 1.7.4+c1cc52f; invoked: 1.7.4 Project type: Cs 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: ILMerge, DebugInfo, IgnoreErr PreProc.Cmd: PostProc.Type: None PostProc.ProcEnv: $(SolutionPath);$(MSBuildThisFileFullPath) PostProc.Cmd: SignAssembly: Identifier: A5E7C3C1-3624-4EA1-8407-19E38D27B525 Instance: C:\Program Files\Microsoft Visual Studio\2022\Professional\MSBuild\Current\Bin\amd64\MSBuild.exe Project path: C:\Users\z003e9wr\source\repos\C To Managed Call\ManagedCSharp\ManagedCSharp.csproj Action: Configure PlatformTarget: x64 TargetFramework: TargetFrameworks: TargetFrameworkVersion: v4.8 RootNamespace: ManagedCSharp AssemblyName: ManagedCSharp MgrArgs: MetaLib: tools\raw\lib\net20\DllExport.dll MetaCor: tools\raw\lib\netstd\DllExport.dll Proxy: StoragePath: .net.dllexport.targets ddNS: ManagedCSharp ddNS max buffer: 500 UseCecil: True intermediateFiles: False timeout: 30000 Options: None RootPath: C:\Users\z003e9wr\source\repos\C To Managed Call
    PkgPath: C:\Users\z003e9wr\source\repos\C To Managed Call\packages\DllExport.1.7.4
    SlnFile: SlnDir: C:\Users\z003e9wr\source\repos\C To Managed Call
    DxpTarget: tools\net.r_eg.DllExport.targets MsgGuiLevel: -1 LockIfError:

Maybe a silly question, sorry I am still learning

When trying to access C# DLLs from native C++ I always get : EEFileLoadException at memory location when the C# assembly (decorated with [Dllexport]) is using other references. I have tried putting all the required Dlls into the folder with the C++ exe but this doesn't help.
So in other words I am accessing C# assembly A from C++ and assembly A is using assemblies B,C,D etc and C++ seems to not be able to resolve these links. (I am using ILmerge in pre-processing tab)

mea05pb avatar Aug 30 '23 12:08 mea05pb

Hello,

Did you list all mentioned dependencies in that field of merging modules?

It's hard to say without inspecting. I recommend isolating the problem using AssemblyResolve to check the generated module after ILMerge

3F avatar Sep 20 '23 21:09 3F

I'm facing the same problem . Calling the c# dll from rust.

sidpara47 avatar Jun 19 '24 12:06 sidpara47

@sidpara47 Have you tried tracking attempts to load requested modules into the active domain? Are you using module merging somehow in your projects? What about applied resolution of an assembly fails in your code? What DllExport configuration? Can you prepare a minimal reproducible example to understand the issue? I need some details. Thanks.

3F avatar Jun 19 '24 15:06 3F

@3F https://stackoverflow.com/questions/78636084/i-want-to-call-a-c-sharp-dll-file-from-rust-code follow this link , you will find everything you need.

sidpara47 avatar Jun 25 '24 12:06 sidpara47

@sidpara47

https://stackoverflow.com/questions/78636084/i-want-to-call-a-c-sharp-dll-file-from-rust-code follow this link , you will find everything you need.

I don't see anything I requested. I'm not even sure you're using this DllExport project. What version? What configuration?

Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'NAudio.Wasapi, Version=2.2.1.0, Culture=neutral, PublicKeyToken=e279aa5131008a41' or one of its dependencies. The system cannot find the file specified

I've verified that NAudio.Wasapi is referenced correctly in the C# project and is available in the same directory as the DLL.

Custom assembly resolving may still be required for your module MicMonitorDllNetFramework.dll because CLR is initialized for this module by the module (host) written in Rust in that case and valid paths for that modified module can point to the different (host) directories and system path of course. Btw, you can quickly verify this by temporarily moving NAudio.Wasapi and all its dependencies into system32 directory, should help.

Additional Details: I am primarily a C# developer

So please backtrace all module loading in your domain. You can additionally check Debug - Windows - Modules (VS IDE) etc. Also you can try any custom pre-loading at the very first call (important, as you know) of a type from NAudio.Wasapi module and so on.

And again, what version and configuration please. Thanks.

3F avatar Jun 25 '24 18:06 3F