Opened 16 years ago

Closed 15 years ago

#889 closed enhancement (fixed)

FDO Componentized install

Reported by: jng Owned by: jng
Priority: low Milestone: 2.2
Component: Installer Version:
Severity: trivial Keywords:
Cc: External ID:

Description

The FDO feature should be composed of provider sub-features. This way the user can choose which FDO providers they want to install as part of the MapGuide installation.

A custom action can be included to assemble the providers.xml based on the feature selection

Change History (7)

comment:1 by jbirch, 16 years ago

There was some discussion of this on the FDO list:

http://n2.nabble.com/Provider-registry-td2052045.html

It would be cool if this could be created as a commandline application where both the installer and end users could just pass the action (register/unregister) and the provider .dll, and it would automatically update the registry. Maybe too ambitious?

comment:2 by jng, 15 years ago

Too ambitious for me. I tried to write a utility to do this, but gave up trying to figure out why the Win32 LoadLibrary() API wouldn't load the provider dlls I was passing in.

So I'm going for the following approach:

  • Build the file list for FDO manually, since the file list is well defined and isn't going to change dramatically. Break that file list into a FDO "Core" feature and multiple provider features.
  • Have a templated providers.xml sourced from the FDO 3.4 SDK with BEGIN* and END* identifiers around each provider entry.
  • Have a custom action that interrogates the MSI feature state of each FDO provider, if it is set to not install, the BEGIN* and END* identifiers for that provider entry are replaced with XML comment markers (ie <!-- and -->) otherwise they are replaced with empty strings. In effect, we're commenting out providers we're not installing.

I don't know how good this approach is, but it is the simplest one that can be done.

comment:3 by jbirch, 15 years ago

I have concerns about how this approach will be dealt with when the install options are modified (via Change in add/remove programs).

If we can't get the api-based CA to work, I think I'd prefer to distribute the installer with all of the files but have the default providers.xml only include the providers without dependencies. We could include a second file (providers_extra.xml) with examples for the other providers...

comment:4 by jng, 15 years ago

Actually, I do now have a functioning FDO Provider registration utility, my last attempt tried to be too smart (I wanted to extract the provider information out of the actual dll itself instead of having to enter the parameters myself).

This one basically wraps IProivderRegistry::RegisterProvider and IProviderRegistry::UnregisterProvider

The problem now is that although I can invoke this utility from the command-line, I'm still figuring out why it won't invoke as a custom action, I'm now trying the CAQuietExec approach (like you did with the IIS7 custom actions), we'll see how this goes.

comment:5 by jng, 15 years ago

Changes added r4076

Tested both install and change (post-install) and this works great!

There are still some small things left to do:

  • Build and copy FdoRegUtil to the Server\FDO directory as part of the "prepare" step
  • Initially disable the ArcSDE, MySQL, King Oracle and PostGIS providers (since these require external libraries present). The xml fragment which I thought would work actually doesn't work.

comment:6 by zspitzer, 15 years ago

with the latest 2.1 beta, i found that if i had those <!-- and --> comments,in the provider xml file, it broke enumerate fdo providers in MapGuide. Oddly existing stuff still worked

comment:7 by jng, 15 years ago

Resolution: fixed
Status: newclosed

Fixed by the following changes:

trunk: r4076, r4081, r4090 2.1: r4084, r4089

Note: See TracTickets for help on using tickets.