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

Jackie Ng jumpinjackie at gmail.com
Mon Aug 18 07:00:15 PDT 2025


Hi All,

An update on the MapGuide Portable front.

The issue was indeed a missing dll, it just wasn't the dll that I thought
was the missing one.

The missing dll was actually gd.dll (required by
OSGeo.MapGuide.Portable.dll > PortableUnmanagedApi.dll > MgPortable.dll >
MgRenderers.dll > gd.dll) that I forgot to bundle into the nuget package.

This was most apparent when looking under Process Monitor in more detail.
It clearly got lost in the noise when I looked at this problem the first
time round.

Amazing what stepping away from a problem from a few days can do, the
solution sometimes decides to show itself =D

After I added the missing gd.dll, a series of smaller fixable problems
cropped up. These problems were dealt with in short order and now we're
back!

[image: 2025-08-18 23_34_37-MapGuide Portable Viewer.png]

Now that this hurdle's cleared, I'll extend my time allotment on this item
by a few extra days to fix up the rest of the existing code samples before
moving on to the rest of the items I said I'll be taking care of before RC1
will finally drop.

Thank you all for the assistance!

- Jackie


On Thu, 14 Aug 2025 at 20:04, Jackie Ng <jumpinjackie at gmail.com> wrote:

> 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
>


-- 
http://themapguyde.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapguide-users/attachments/20250819/9ff7418e/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2025-08-18 23_34_37-MapGuide Portable Viewer.png
Type: image/png
Size: 354769 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/mapguide-users/attachments/20250819/9ff7418e/attachment.png>


More information about the mapguide-users mailing list