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 , 16 years ago
comment:2 by , 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 , 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 , 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 , 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 , 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
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?