Should I drop Library activated Serviced Component from COM+ when the interface changes?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I would like to understand better what happens when a public interface of a serviced component changes

Suppose that I have a library activated serviced component. Suppose that I lock its version number ([assembly: AssemblyVersion("1.0.0")]) and installed the component into COM+ catalog (via regsvcs or just by running a client that uses it)

Now, suppose that I change the existing method or add a new method in the component

It appears that everything continues to run fine afer the change

I am not sure, though, if this is the way to do it. I always drop the component from COM+ catalog when the interface changes

Question is, do I need to? Is it really necessary

What exactly is going on with component when the interface changes

Thanks

-Sta
 
Hi Stan,

Thanks for posting in the community.

First of all, I would like to confirm my understanding of your issue.
From your description, I understand that you wants to know when you break
down an interface, i.e. change the one method definition or add a new
method, if it is necessary to re-register it in to COM+.
Have I fully understood you? If there is anything I misunderstood, please
feel free to let me know.
Now, suppose that I change the existing method or add a new method in the component.
It appears that everything continues to run fine afer the change.
Click to expand...

This may be work, when you call the COM component by using IDispatch
interface(i.e. LateBinding), when you changed the interface, but can not
guarantee if it will
always work.

Based on my experience,

When you call an .NET exported COM object using Latebinding, the COM client
will call the method by QueryInterface, afterward the MSCoree.dll will be
run and using Reflection to call the managed method in the Assembly. If you
change the Method name, I think the call will not true.

Another possible situaltion is that you have register the Assembly in the
GAC, and you compile your .NET assembly but did not register it into the
GAC, so you are calling the original file.

So, to avoid the unexpected behavior, I recommned you unregister and
re-register the COM+ component (using Regsvcs tool).

When you change the method of the .NET serviced component and register it
as an COM interop, the typelibrary( the tlb file) will be changed
accordingly. Then the tlb will be registered into registry for COM client
using.

Here are links about Regitering an Assembly,

Dynamically Registering an Assembly
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/htm
l/cpcondynamicallyregisteringassembly.asp
Manually Registering an Assembly
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/htm
l/cpconmanuallyregisteringassembly.asp

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Hi Peter

I know that re-registering the assembly is a safe way to deal with it. I was just hoping for an answer from somebody at MS saying that this is a way of do it or not.. It seems contradict XCOPY deployment idea because after copying the assembly with changed interface, it is requried to drop it from COM+ catalog and run REGSVCS

What also strange, and I don't understan why it happens, is that even I don't re-register the assembly, it still works fine. At least for .NET clients

Thanks

-Sta
 
Hi Stan,

Thanks for your quickly reply!

Based on my knowledge, XCOPY deployment will not apply to all kinds of .NET
project. In order to make the serviced component runs properly on the
machine, registering serviced component is necessary, so that the COM
client can access it.

From Deploying .NET Applications Lifecycle Guide.

Side-by-Side Issues with Serviced Components
As you update your serviced components, or if you have a scenario where
multiple
versions of the same component are on the same computer, you can encounter
several issues caused by having these components installed side by side. To
help you
maintain your serviced components, you should adhere to the following
advice:
 Do not use globally unique identifiers (GUIDs) as the GuidAttribute class
or
ApplicationIDAttribute. Instead use the ApplicationNameAttribute. If you do
use a GUID, you need to hard code the GUID into the assembly, which requires
you to manually change this GUID if you update your component and have it
run alongside the original version; otherwise, the COM+ installation
overwrites
the settings for the earlier version.
 Remember that assembly versioning applies only to the assemblies
themselves,
not the COM+ application. There is no automatic way to version the
application
itself. If the newer version of a serviced component requires changes at the
COM+ application level that will break previous versions of the component,
then
you need to use the application name to indicate versioning by installing
the
newer version of the serviced component into its own COM+ application.

For detailed information, you may download the file referring to the link
below.

Deploying .NET Framework-Based Applications
http://www.microsoft.com/downloads/details.aspx?FamilyId=5B7C6E2D-D03F-4B19-
9025-6B87E6AE0DA6&displaylang=en


Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Hi Stan,

Did my suggestion help you?
If you still have any concern on this issue, please post here.

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Back
Top