[fdo-users] Delay loading dlls ? [SOLVED]

[Oyvind Idland]

Well, it will work just fine until somebody places a different/wrong/bad
version of the dependent dll's
somewhere in the search-order :)

On the other hand, we checked the settings on the FDO projects, and it turns
out that this setting is
already there.

The problem is; ASP seems so pre-load recursively native dll's in the
bin-folder aswell, so we will try
to solve this by adding a parallel folder to the bin-folder..  fingers
crossed.


-- Oyvind




On Tue, Dec 14, 2010 at 3:45 PM, Mark Branscum <mbranscum at agvance.net>wrote:

> 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>
> 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] *On Behalf Of *Oyvind Idland
> *Sent:* Monday, December 13, 2010 9:18 AM
> *To:* 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
> http://lists.osgeo.org/mailman/listinfo/fdo-users
>
>
>
> _______________________________________________
> fdo-users mailing list
> 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/9e044993/attachment-0001.html