Application fails to find DLL that is in the same directory
I've added a DLL reference to my project, which compiles just fine but when the application runs it fails to find this DLL even though it's in the same directory. How would I debug this?
53 Replies
Is this a .Net Framework app by chance?
No, it's .NET 8
I see! I didn't run into this error for ages. Back in .Net Framework, my go to tool for this used to be Fusion logging. However, I am not 100% sure it still works with net core / 8. What definitely should work is using something like
dotnet trace to collect assembly events
One sec, looking up the linkCollect detailed assembly loading information - .NET Core - .NET
Description of how to collect assembly loading information in .NET Core
It should provide you with some details on the probed paths
So you can inspect which paths were tried for resolving the dll
Cool, I'll give it a shot :)
Does this tool also work on Linux?
Nvm, the documentation says it should
Collection definitely works on linux yeah
It's only providing me with some process path information, is there a specific argument I need to pass?
I'm calling it like so:
dotnet-trace collect -- MAGE
This is the output:
is the box2d dll in the output directory (also its dependencies)
?
--providers Microsoft-Windows-DotNETRuntime:4I tried this earlier and the result was the same unfortunately
Yeah it is
dotnet-trace collect --providers Microsoft-Windows-DotNETRuntime:4 -p <pid> should do it usually
Is that the one you tried?I didn't use -p, I just had it start the executable because it throws an error before I can get the process ID
Trying that results in the same output
I see - Should be fine though, the assembly loading events should be part of the default profile which also includes the DotNETRuntime provider
Loader and binder runtime events - .NET
Learn about the .NET runtime events that collect diagnostic information specific to loader and binder ETW events, which collect information about the assembly loader and binder.
This is what should be included
Is this information stored in the output report file?
You should end up with a .nettrace file including the entire collected traces
Yeah
I do have those, I read that you can open them with PerfView
Yeah, PerfView or VS usually
VS has pretty good integration with a lot of the dotnet diagnostic tool outputs
I'll have to reboot into windows real quick, but hopefully it gives some useful information :)
https://learn.microsoft.com/en-us/dotnet/core/diagnostics/dotnet-trace#view-the-trace-captured-from-dotnet-trace There's a way to view this on linux as well
dotnet-trace diagnostic tool - .NET CLI - .NET
Learn how to install and use the dotnet-trace CLI tool to collect .NET traces of a running process without the native profiler, by using the .NET EventPipe.
It's just in the dotnet-trace docs though
But I'm not familiar with that route, since I'm on windows
Hmm
It's definitely worth a shot, it's good to know that I have multiple ways to do this if I need them
can you send the .deps.json file in your build output
instead of using dotnet trace i would first try
export COREHOST_TRACE=1 and then running the application
it should dump a bunch of stuff to the consoleThere's a lot to go through here, I'll upload a text file with the output
Or not, turns out it's a separate process that's dumping that stuff to the console
yeah, once you set it, you want to directly run your output program, not
dotnet run or whateverIt looks like
Box2DX.dll is in the output:
:/media/<uname>/1D8E170E787C927A/Programming/C#/MAGE/bin/Debug/net8.0/Box2DX.dll:Oh, right, I forgot about the corehost_trace flag. I think there's also one to output the traces to a file instead of console if it's inconvenient?
Sine my terminal has a maximum backtrace size, that would be preferred. I'll see if I can find that flag
COREHOST_TRACEFILE=path
I just found that here:
https://github.com/dotnet/runtime/blob/main/docs/design/features/host-tracing.md
GitHub
runtime/docs/design/features/host-tracing.md at main · dotnet/runtime
.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps. - dotnet/runtime
Here's the output of that:
I noticed that it skipped the file exists check, is that an issue?
can you send Box2DX.dll
rename the file extension
Please don't upload any potentially harmful files @Mazranel, your message has been removed
yeah
Ah
yeah, this is a terrible error message
the issuse is that the DLL is compiled to target x86
Ah, so I'll need to switch to x86
for whatever reason, this is the error message you get when you try and load a libary with the wrong architecture
you should just switch it to AnyCPU
Microsoft should really make some better error messages
i suspect Box2DX does not actually target x86 for any reason
I think it already is actually, at least in VS the debug mode was set to anycpu
you might have to edit it in the csproj file or the configuration editor
I'll double check, if it's not anycpu I'll change it
Nope, adding
<PlatformTarget>AnyCPU</PlatformTarget> didn't help
This is the CSPROJ
to be clear, i mean on the Box2DX project
Ah
The target framework for the Box2DX project is
netstandard2.0, I dunno if that'll cause issues or notthat is fine
you just need it to not make an x86 DLL
Awesome, it runs now!
I just need to make sure it's actually working
Does this server have a way to mark posts as solved?