Jump to content


This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Photo

Installing COM+ Application in Developer 8?


3 replies to this topic

Superfreak3

Superfreak3
  • Full Members
  • 437 posts

Posted 02 February 2006 - 15:06

sad.gif I'm trying to install a COM+ Application via a parent install. The COM+ .msi, exported from an XP machine via Administrative Tools -> Component Services, is called from a Custom Action.

I've seen various articles indicating the sequence placement of the nested install Custom Action, ranging from before InstallInitialize and after CostFinalize (Q105534) to both before and after InstallFinalize. However, no matter where I place the CA in the Execute sequence, I get, what appears to be, the dreaded 1928 Error - Error registering COM+ application.

Through the various research I've conducted, it appears that the OS that generated the COM+ .msi may have something to do with it (certain settings may be needed for install on earlier OSs, etc.). Again, it was created on XP and I'm now trying to install on a Win 2K Professional OS.

Additionally, I'm wondering what is actually contained in the COM+ .msi. Are there actual conponents in there or are there just references to installed components?

The reason I ask this is because I have MyFile.dll in the parent install. When we create the COM+ App. manually on the XP system, we point to this file. Could there be a problem if the file is contained in both the parent install and the generated COM+ .msi?

From what I've read, this appears to be somewhat of a pain, at least on Developer 8 and previous releases of InstallShield. I've seen some vbScripts out there pertaining to this, but I don't know if I can go that route.

The alternative would be to instruct the user to create the COM+ application manually through the use of Administrative Tools, but I want to avoid that.

Any direction would be greatly appreciated!!!!!

As always, THANKS!!!!!!!!!!

lherz

lherz
  • Full Members
  • 11 posts

Posted 08 February 2006 - 17:02

You are correct that the OS used for creation of the COM+ application or proxy is your culprit. Windows XP uses COM+ v1.5 and windows 2000 used COM+ v1.0. By default a package created / exported in XP will be a COM+ v1.5 file unless you specifically set the COM+ v1.0 compatability option prior to expporting.

Glytzhkof

Glytzhkof
  • Moderators
  • 1,447 posts

Posted 09 February 2006 - 06:52

I believe the exported MSI contains the COM+ file along with a black box *.apl file. The latter apparently contains the property settings for the service registration.
Regards
-Stein Åsmul

Superfreak3

Superfreak3
  • Full Members
  • 437 posts

Posted 13 February 2006 - 17:23

After creating the .msi's for the appropriate OSs (1.5 and 1.0), I was able to get the COM+ application installed correctly. However, on upgrades, I was running into problems removing or updating the COM+ application.

I accomplished the desired task by automating the COM+ piece via a small .exe that I coded.

This automates the build update process of the COM+ application and frees me from creating .msi's for installation.

After my new or updated .dll is placed, my .exe first removes the components from the desired COM+ application if any exist, then deletes the application itself. I then rebuild the COM+ application and components by pointing to the newly installed or updated .dll.

I don't know if this is the best solution, but after seeing that it worked and reading that COM+ with .msi's appears to be a pain, this is the method I used.

I hope this helps someone out there.

Thanks!