[fdo-users] Delay loading dlls ?

[Mark Branscum]

Hi Øyvind,

Uh oh...  Hearing you say that the approach we are using works in some cases and not others gives me cause for concern now.  I think we will be testing and researching this further.  If the SetDllDirectory approach works then I would agree that adding the delay load to FDO would be very valuable for ASP deployment.

Thanks for the information,
Mark

From: fdo-users-bounces at lists.osgeo.org [mailto:fdo-users-bounces at lists.osgeo.org] On Behalf Of Oyvind Idland
Sent: Tuesday, December 14, 2010 3:50 AM
To: FDO Users Mail List
Subject: Re: [fdo-users] Delay loading dlls ?

Hi Mark,

we tried that approach earlier. It worked ok in some cases, in others not.

For example, the GDAL dll is dependent on libeay.dll. Before $PATH, the windows
and windows/system32 folders is searched. It found a libeay.dll there and loaded it. The
app and then halted since that dll lacked a function (older version).

Debuging such thing on a customers  machine can sometimes be pain, and windows is
quite economical when it comes to providing useful error messages on these issues....

By using delay load, such unpredictable behaviour can be avoided.

The only alternative we can see right now is to compile FDO from scratch and add that option.



- Øyvind


On Mon, Dec 13, 2010 at 6:36 PM, Mark Branscum <mbranscum at agvance.net<mailto:mbranscum at agvance.net>> wrote:
Øyvind,

It sounds like you may be running into the same issue I ran into a while back while deploying FDO in ASP.  Are you saying that you had to add your FDO ASP app's bin folder to the $PATH in order to get the native DLLs loaded?

That is what we initially had to do.  However, if I remember correctly I think we eventually put the FDO DLLs in their own directory and then added only that directory to the system path.  That way we didn't have to add the ASP app's bin folder to the system path and risk the side effects you are describing.  However, that approach has the side effect that all ASP applications on the server will need to use the same FDO DLLs and you would not be able to run multiple versions of FDO.  But that was not an issue for us.

Mark Branscum

From: fdo-users-bounces at lists.osgeo.org<mailto:fdo-users-bounces at lists.osgeo.org> [mailto:fdo-users-bounces at lists.osgeo.org<mailto:fdo-users-bounces at lists.osgeo.org>] On Behalf Of Oyvind Idland
Sent: Monday, December 13, 2010 9:18 AM
To: fdo-users at lists.osgeo.org<mailto:fdo-users at lists.osgeo.org>
Subject: [fdo-users] Delay loading dlls ?

Hello,

we have an issue with dll loading when using them in an Asp.NET application.

The server pre-loads assemblies before executing the app. While doing this, it will also attempt to load
native dependencies. Deployment and loading works somewhat different in an Asp application, so
its starts looking for the dll's all over the place. In some cases it may load dll's from another app's
bin-folder, if it is set in $PATH.. which causes unpredictable consequences in some cases.

If delay load is set on the topmost dependencies, the Asp-app can specify the dll using SetDllDirectory()
before the dependencies is loaded.

Is it possible to have this feature added in FDO 3.5 and above ?


-- Øyvind Idland

_______________________________________________
fdo-users mailing list
fdo-users at lists.osgeo.org<mailto:fdo-users at lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/fdo-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/fdo-users/attachments/20101214/21a67dcb/attachment.html