>I have a .NET assembly, containing two Serviced Component classes, which
>are added to an existing COM+ application to extend its functionality.
>
> The .NET assembly is installed by calling regasm, followed by regsvcs to
> add it to the application, then added to the GAC. This works with no
> problems on a number of development and test machines.
>
> We recently updated the assembly on one test server, using a installation
> package to automate the registration of the components. Since then, when
> the hosting COM+ application starts, the following error appears in the
> application event log:
>
> The following component is configured for Construction, and either the
> IObjectConstruct::Construct() method failed, or the component does not
> support IObjectConstruct. Activation failed for object:
> {8E574D71-9868-30DD-91C0-764BE20068D4}
> Server Application ID: {C4E0FA00-475D-11D4-85D6-00105AD8842F}
> Server Application Name: Metastorm e-Work Engine
> Error Code = 0x80004002 : No such interface supported
> COM+ Services Internals Information:
> File: .\ctoract.cpp, Line: 130
>
> This same version of the assembly works with no problems on all of the
> other machines, and removing it and replacing the previous working version
> on the problem machine doesn't solve the problem - the same error still
> appears.
>
> I have tried removing the parent application, which owns the COM+
> application and reinstalling it, but still no success.
>
> I am looking for guidance as to what could have gone wrong with
> configuration, as I am concerned this could happen on a customer system in
> the future. I don't believe the error message, because it suggests the
> problem is within the component, but the component works everywhere else,
> and in previous versions worked on the this system too.

Tomas Restrepo (MVP) wrote:
> Ian,
>
>
>
>>Thank you Tomas. I didn't realise that regsvcs duplicates what regasm
>>does, we'll remove that from the installation.
>>
>>Interesting what you say about not explicitly specifying GUIDs - we aren't
>>at the moment - sounds almost like VB6 COM components with a new GUID on
>>every build.
>
>
> That can and *will* happen if you let the compiler change the assembly
> version on each build.
>
>
>>I assume it is accepted good practice to specify GUID, and ProgID for each
>>COM Visible class in an assembly.
>
>
> Not quite.
>
> The best guide I've seen on this is still Clemen's Vasters "Staying Sane in
> a Hybrid World: Using Enterprise Services":
> http://radio.weblogs.com/0108971/2002/07/20.html#a18
>

> Thank you Tomas. I didn't realise that regsvcs duplicates what regasm
> does, we'll remove that from the installation.
>
> Interesting what you say about not explicitly specifying GUIDs - we aren't
> at the moment - sounds almost like VB6 COM components with a new GUID on
> every build.

> I assume it is accepted good practice to specify GUID, and ProgID for each
> COM Visible class in an assembly.

Tomas Restrepo (MVP) wrote:
> Sounds like a problem with your registration/update. First of all, I'd
> suggest not running regasm on the assemblies (Besides, regsvcs does that,
> anyway).
>
> The second point is, you don't seem to be "unregistering" your assemblies
> before updating them. If you are not explicitly stating your
> component/interface guids on code, and you change the assembly version/class
> information, then reregistering the component will cause .NET to register
> the component using new guids. Sounds like this happened on at least one
> machine, and now you have multiple registry keys with different guids for
> the component, some of them leftover from previous installations. One of
> those might be hosing you up.
>
> I'd suggest "cleaning" the problematic's machine registry, by searching for
> you component's name / class names in the registry and deleting any COM
> registration keys (under HKEY_CLASSES_ROOT) that reference your component
> and re-registering it again.