How to load specific GDIPLUS.DLL ?

[Pierre Arnaud]

I have downloaded OFFICE 11 BETA 2 and now I would like to test my
application (written using .NET) against the newer GDI+ I just got.

The standard GDIPLUS.DLL versions are located in Windows WinSXS
folder, which allow side-by-side cohabitation of several different
versions. However, Office has a GDIPLUS.DLL in its own application
folder.

After copying the DLL to my application folder and creating an empty
Test.exe.local file (which should tell Test.exe to prefer the local
DLLs rather than those provided by the system/by the fusion mechanism),
I expected that .NET would load the new GDI+. But no... it still loads
the one from the system WinSXS folder.

Trying to LoadLibrary GDIPLUS.DLL with an explicit path at the very
beginning of my application loads the local GDI+, but then, as soon
as the System.Drawing DLL gets active, it loads its own, older GDI+
version.

So I am stuck with the 1.0.10.0 version of GDI+ ? I would love to
test 1.1.0.0, since I have been told that it fixes the bugs which
annoy me most.

Any idea on how to make .NET load and use the local GDI+ DLL ?

Pierre

[vipin]

The current directory.
Windows XP: If
HKLM\System\CurrentControlSet\Control\SessionManager\SafeDl
lSearchMode is 1, the current directory is the last
directory searched. The default value is 0.

>.
>

[Pierre Arnaud]

> The current directory.
> Windows XP: If
> HKLM\System\CurrentControlSet\Control\SessionManager\SafeDl
> lSearchMode is 1, the current directory is the last
> directory searched. The default value is 0.

Putting a .EXE.LOCAL file in the application folder should to the
trick, too. Whatever I do, .NET insists on loading the 1.0.x version
of the DLL.

Any other ideas ?

[vipin]

search for gdiplus.dll.
I searched the registry and see that there is a most
recently used dll list. see if deleting the gdiplus dll
entry there helps, because it might point to the older one.

thats all I know but I am curious of the answer to problem
you face because I also require something like that if not
today but tommorow.

vipin

>.
>

[Pierre Arnaud]

> search for gdiplus.dll.
> I searched the registry and see that there is a most
> recently used dll list. see if deleting the gdiplus dll
> entry there helps, because it might point to the older one.

I have found it in the HKLM\..\CurrentVersion\SideBySide\..
part of the registry, where I would like to register Office11
GDI+. I just don't know how.

This is of no help, alas...

[vipin]

usually I try out everything before replying but am busy
to try but want to be involved.

Does adding to the beginning of the path variable make a
difference, I guess it doesn't?
or will linking to new dlls library make a difference?

If gdiplus.dll is delay loading, I think they may be
checking in the startup code and then loading a specific
version of dll.

One think to look is, is it delay loading?

vipin

>.
>

[vipin]

verified, no delay loading and it is loading my local
directory dll here on win2k sp2.

vipin

>.
>

[Pierre Arnaud]

> verified, no delay loading and it is loading my local
> directory dll here on win2k sp2.

No delay loading indeed. And in Win2k it works just fine with
the local version. It is under Windows XP that things don't
work at all.

I tried following things:

- Load library GDIPLUS.DLL with an explicit call to LoadLibrary
before my DLL gets loaded. But again, it loads 1.0.10.0

- Implement delay loading for GDIPLUS.DLL from my own DLL, so I
can load the new GDIPLUS myself. .NET System.Drawing still
loads the old GDIPLUS DLL, then I get my DLL loaded and it
tries to load its own GDIPLUS DLL; this way, I can load the
new DLL, but somehow, there is a conflict between the two,
because after doing so, my application crashes when it tries
to paint using GDI+.

So no solution yet...

[John Hornick [MS]]

Hi,

I understand you may be doing this for your own edification, but
I have to point out that what you are attempting is not supported.
One of the reasons apps install GDI+ into their own directory is
specifically to avoid having a newer version stomp on the "known
good" version they were built against.

If you want to see how the .NET Framework works with a newer
version of GDI+, get a newer version of the .NET Framework
which was designed to use the newer version of GDI+. I think
there's a beta of the latest .NET Framework available on the
Microsoft web site.

Thanks,
- John
Microsoft Developer Support
This posting is provided "AS IS" with no warranties, and confers no rights.
Visit http://www.microsoft.com/security for current information on security.

[Pierre Arnaud]

> If you want to see how the .NET Framework works with a newer
> version of GDI+, get a newer version of the .NET Framework
> which was designed to use the newer version of GDI+. I think
> there's a beta of the latest .NET Framework available on the
> Microsoft web site.

The 1.1 beta does not come with the latest GDI+. Nothing has
changed with respect to the graphic bug in the region handling
in the GDI+ version used by .NET 1.1 final beta.

However, I was able to check that the Office 11 GDI+ version
works properly with .NET 1.0 on W2k where I could bypass the
side-by-side DLL loading mechanism.

Thanks anyway.

Pierre

[mosta...@rocketmail.com]

After 17 years, I've the same problem except I want to use old version of GdiPlus.dll rather than new one.

I've a WinForms app works fine on windows 7/8.1 and an old build of Windows 10 but crashes on the latest builds of Windows 10 at function graphics.FillRectangle with HatchBruch as parameter

Is there any way to force System.Drawing.dll to load specific version of GdiPlus.dll?