Opened 9 years ago

Closed 9 years ago

#1015 closed defect (fixed)

2.1 beta default install results in errors - missing dlls

Reported by: andrewd Owned by:
Priority: medium Milestone: 2.1
Component: General Version: 2.1.0
Severity: critical Keywords:
Cc: External ID:

Description

This is a minor bug, but if it's not fixed it will result in most users getting an error, right out of the box.

Using a default install, you get an error when trying to edit layers - the error says it's missing libpq.dll and oci.dll. The fix for this is to simply comment out the PostGIS and KingOracle? FDOs in providers.xml...but would it not make more sense to comment those out by default, since most people will be getting these errors every time they try to edit a layer?

Change History (7)

comment:1 Changed 9 years ago by zspitzer

not quite sure what the previous behaviour was exactly, but I thought unless you specifically called a provider it wouldn't be loaded?

comment:2 Changed 9 years ago by ksgeograf

When MapGuide loads FDO, FDO loads the providers, and queries them (for supported parameters I think).

Since the OCI and libpq libraries are not delay loaded, the windows dll loader gives an error.

The previous version of MapGuide also had this problem, but was missing many providers in the install, including the two in question. If you add them the server will lock up when loading FDO, and if you run MapGuide in interactive mode, it will display the windows error dialogs responsible for the lockup.

comment:3 Changed 9 years ago by andrewd

For the end user, this bug is new - even though the underlying cause of it may not be. There were no missing dll errors out of the box with any previous version. Would it not be relatively simple to just make the installer modify the providers.xml, based on whether or not the user is missing these dlls in there path?

comment:4 Changed 9 years ago by jbirch

Nope, not easy at all because the provider sections in config.xml are not uniquely identified (so can't be easily added/removed), and because actually testing the dependencies would require a custom action. Feel free to apply some resources to the problem if you can think of a way of doing it :)

The only interim workaround that I can think of is to comment out the providers with external dependencies, or possibly remove them to a second file (providers_disabled.xml or something like that) so users can manually enable these when they have the dependencies?

comment:5 Changed 9 years ago by andrewd

Ah - that's too bad! Your interim workaround would do the trick, for sure. It seems to me that it's better to have people have to enable those providers, since leaving them in causes those errors. Could you do something like have 2/3 providers.xml files in the installer package (one with and one without those external ones) and then have it use the correct one based on some question asked of the user (with a warning of some sort)?

comment:6 Changed 9 years ago by jng

I'm working on adding support for fine-grained FDO provider installation (#889) that will more or less resolve this issue.

comment:7 Changed 9 years ago by jng

Resolution: fixed
Status: newclosed

Fixed by changes made to the installer to support FDO provider components (#889).

There is still an issue of initially disabling ArcSDE, Oracle, MySQL and PostGIS providers when the installer is launched. But the problem at hand is effectively fixed.

Note: See TracTickets for help on using tickets.