[mapguide-users] What is left before MGOS 4.0 RC1

[Jackie Ng]

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) <
crispin at 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-bounces at lists.osgeo.org> on behalf
> of Pierre Cardinal via mapguide-users <mapguide-users at lists.osgeo.org>
> *Sent:* Wednesday, August 13, 2025 7:26:33 PM
> *To:* MapGuide Users Mail List <mapguide-users at lists.osgeo.org>
> *Cc:* Pierre Cardinal <pierre.cardinal at sympatico.ca>; Jackie Ng <
> jumpinjackie at 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-bounces at lists.osgeo.org> de la part
> de Jackie Ng via mapguide-users <mapguide-users at lists.osgeo.org>
> *Envoyé :* mercredi, août 13, 2025 7:57:13 a.m.
> *À :* MapGuide Users Mail List <mapguide-users at lists.osgeo.org>
> *Cc :* Jackie Ng <jumpinjackie at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapguide-users/attachments/20250814/338c315d/attachment.htm>