ILSpy is ideal for actually checking DLL not found (or version mismatch with e.g. System.Memory but you probably did this
But Bitness is the likely culprit... I spent days troubleshooting one application that had some x64 and some AnyCPU that didn't play nice together best regards, Crispin Founder / CEO :: Linknode Ltd, trading as TrueViewVisuals ________________________________ From: mapguide-users <[email protected]> on behalf of Pierre Cardinal via mapguide-users <[email protected]> Sent: Wednesday, August 13, 2025 7:26:33 PM To: MapGuide Users Mail List <[email protected]> Cc: Pierre Cardinal <[email protected]>; Jackie Ng <[email protected]> Subject: Re: [mapguide-users] What is left before MGOS 4.0 RC1 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. Régards Pierre ________________________________ De : mapguide-users <[email protected]> de la part de Jackie Ng via mapguide-users <[email protected]> Envoyé : mercredi, août 13, 2025 7:57:13 a.m. À : MapGuide Users Mail List <[email protected]> Cc : Jackie Ng <[email protected]> Objet : [mapguide-users] What is left before MGOS 4.0 RC1 Hi All, Just to provide some transparency on what is left before RC1 releases. I am currently working on getting MapGuide Portable (formerly known as mg-desktop) bindings working under our new way of generating language bindings. I am having some difficulty getting the new package to work due to cryptic missing dll errors that are cryptic because: a) I have no idea how to even debug a DllNotFoundException in this new .net world. In the past when everything was still legacy .net Framework 4.x we could run fuslogvw.exe and turn on assembly binding errors and that would tell us straight away what the missing dlls are. In this new .net world, fuslogvw.exe doesn't seem to work anymore and I don't know what the new "modern .net" way to diagnose assembly binding failures is. Thanks to Microsoft's excellent track record in naming their products and technologies, any attempts to search for this topic naturally returns decade-old articles and blog posts that are no longer relevant to modern .net! b) The dll files .net is complaining about not being able to find *are there*, some part of the .net runtime just doesn't want to look in the folders I've placed these dll files in (as evidenced by monitoring the consuming application under Process Monitor) This is not a crucial component of MapGuide (merely a supplemental part), so I am giving myself the rest of the week to try to solve this problem. If I can't come up with a solution, I'll park this sub-project until after the 4.0 release. I am also working on finishing up the new API documentation experience where instead of our current approach of documenting a C++ API and sprinkling .net/Java/PHP sample fragments in various class/method comments in the hopes you'll understand how to use such a C++ class or method in a .net/Java/PHP context, we try to provide the MapGuide API docs for every target language in that language's natively preferred API documentation tool of choice. - For .net, this is docfx (https://dotnet.github.io/docfx/) - For Java, this is the built-in javadoc - For PHP, unfortunately we'll have to put a landing page that tells you how to re-interpret the .net or Java API docs in a PHP context. PHP unfortunately does not support overloaded methods and our PHP binding just smushes all of these overloads into a single method whose parameters vary based on the overload set of parameters you're trying to use. This makes it really hard to translate C++ API documentation across, unlike .net or Java where everything translates 1:1. Until we can find a solution to this problem, our C++ API docs are not translatable for PHP API documentation generation. I'll also be doing yet another sweep of our web tier components and will be bundling updated versions of Apache, PHP and Tomcat where required. On the FDO front, the PostgreSQL materialized view fix is in. Nothing else of a show-stopping nature seems to be blocking us there, so that's all ready to go. I will formally open a FDO 4.2 svn branch before or after this RC1 release (haven't decided yet) - Jackie -- http://themapguyde.blogspot.com Tel: +44 141 374 2741<tel:+441413742741> Web: TrueViewVisuals.com<https://trueviewvisuals.com/> and RoadsOnline.co.uk<https://www.roadsonline.co.uk/> [TVV and LCRIG - RoadsOnline] This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.
_______________________________________________ mapguide-users mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/mapguide-users
