Hi Jackie,
Perhaps there is some solutions for you from this Gemini answer.
Based on your description, this is a classic and very frustrating problem in modern .NET when dealing with native libraries (DLLs). The good news is that there are well-established debugging strategies for this scenario. The developer is right—fuslogvw.exe is no longer the tool for the job.
Here is a proposed solution path, broken down into key steps:
1. The Core Problem: The DLL has Missing Dependencies
The most likely cause of a DllNotFoundException when the DLL file is present is that one of its own native dependencies is missing. The .NET runtime tries to load your DLL, but the operating system's loader (not the .NET runtime itself) fails because a required dependency is not found. The resulting exception message from .NET points to your DLL, but the root cause is elsewhere. This is the "cryptic" part.
For MapGuide Portable, this is a very common issue because it relies on a whole chain of native C++ libraries for things like FDO, GDAL, and various other components.
2. Modern Debugging Tools and Techniques
The developer correctly observed that Process Monitor shows the file is present. The next step is to use tools that can inspect the dependencies of a native DLL.
a) Use a Dependency Inspection Tool
This is the most critical step. Forget fuslogvw.exe and Process Monitor for a moment and focus on the DLL itself.
* "Dependencies" Tool: This is the modern successor to the old Dependency Walker. It's a free, open-source tool available on GitHub. It's specifically designed to analyze the dependencies of native DLLs, including identifying architecture mismatches (32-bit vs. 64-bit) and showing which DLLs in the dependency tree are missing. Run this tool on the core MapGuide DLL that your .NET code is trying to load. It will likely show a list of other DLLs, some of which may be marked as not found.
b) Inspect the Process with a Debugger
While not as direct as a dependency tool, a debugger can also provide clues.
* Visual Studio Modules Window: While debugging your .NET application in Visual Studio, open the Modules window (Debug > Windows > Modules). This window lists all the DLLs that have been loaded by your application. When the DllNotFoundException occurs, you can check which native DLLs were loaded successfully and which were not. The last native DLL that failed to load (just before the exception) is your primary suspect.
3. Solution and Mitigation Strategies
Once you have identified the missing dependency, you can take action.
a) Resolve Missing Dependencies
* Find and Copy the Missing DLLs: The most straightforward solution is to find the missing native DLLs (e.g., from the MapGuide installation folder or a separate dependency package like GDAL) and copy them into the same directory as your application's executable. This ensures the operating system's loader can find them.
* Install the Correct Visual C++ Redistributable: Many C++-based libraries like MapGuide depend on the Microsoft Visual C++ Redistributable packages. If the correct version (e.g., 2015-2022) is not installed on the target machine, core C++ runtime DLLs will be missing, leading to the cryptic DllNotFoundException.
* Check the "Bitness": Make sure there is no mismatch. If your .NET application is compiled for x64, all native DLLs must also be x64. An x86 DLL will fail to load in an x64 process, and vice-versa.
b) Address Path-Related Issues
The user mentioned that the files are "there," but the runtime doesn't "want to look in the folders." This is a key insight. Modern .NET doesn't automatically add subdirectories to the native library search path.
* Explicitly Set the Search Path: You can programmatically set the search path for native libraries using the NativeLibrary.SetDllImportResolver method in .NET 5+ or by adding the native libraries' folder to the PATH environment variable of the process before loading them.
* Post-Build Events: A robust solution for a project is to use a post-build event in your .csproj file to automatically copy all necessary native DLLs and their dependencies into the build output directory (e.g., bin\Debug). This ensures that the DLLs are always in the correct location for the application to run.
Summary of the Recommended Solution Path
* Stop using Process Monitor to look for the file directly. Instead, use a tool that inspects the dependencies of that file. The "Dependencies" tool is the best choice here.
* Run "Dependencies" on the main MapGuide DLL that your .NET code is trying to load.
* Identify the exact native DLL(s) that are reported as missing.
* Find the missing DLLs (often in the main MapGuide installation or in a separate dependency folder) and copy them into your application's output directory.
* Confirm the "bitness" (x86 vs. x64) of your application and all native DLLs is consistent.
* Ensure the correct Visual C++ Redistributable is installed.
* If the problem persists, consider a programmatic approach to set the native DLL search path or use post-build events to ensure all dependencies are copied to the correct location.
_______________________________________________ mapguide-users mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/mapguide-users
