The dll in question that could not be loaded is the unmanaged MgPortable SWIG glue dll, not a .net assembly.
I swore bitness mismatches yielded a more specialized error message than what I am getting. Nevertheless, it's an angle I should check. Thanks. - Jackie On Thu, 14 Aug 2025 at 19:45, Crispin Hoult (TrueViewVisuals) < cris...@trueviewvisuals.com> wrote: > 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 <mapguide-users-boun...@lists.osgeo.org> on behalf > of Pierre Cardinal via mapguide-users <mapguide-users@lists.osgeo.org> > *Sent:* Wednesday, August 13, 2025 7:26:33 PM > *To:* MapGuide Users Mail List <mapguide-users@lists.osgeo.org> > *Cc:* Pierre Cardinal <pierre.cardi...@sympatico.ca>; Jackie Ng < > jumpinjac...@gmail.com> > *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 <mapguide-users-boun...@lists.osgeo.org> de la part > de Jackie Ng via mapguide-users <mapguide-users@lists.osgeo.org> > *Envoyé :* mercredi, août 13, 2025 7:57:13 a.m. > *À :* MapGuide Users Mail List <mapguide-users@lists.osgeo.org> > *Cc :* Jackie Ng <jumpinjac...@gmail.com> > *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 <+441413742741> > Web: TrueViewVisuals.com <https://trueviewvisuals.com/> and > RoadsOnline.co.uk <https://www.roadsonline.co.uk/> > [image: 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. > -- http://themapguyde.blogspot.com
_______________________________________________ mapguide-users mailing list mapguide-users@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/mapguide-users
