You should provide a different IID definitely as its a new
version - this will negate the possibility of new clients running
against old DLLs and causing access violations
and its a much cleaner solution too

CLSID reuse is probably ok if ur not going to split the
implementation of the old and new versions into diff
dlls -

As for providing only IDispatch - well if it can be guaranteed
u will be ok in which case of course u need not be worrying abt
IID's at all

arun

----- Original Message -----
From: "Phil Reynolds" <preynoldsRIDGEWAYSYSTEMS.COM>
To: <DCOMDISCUSS.MICROSOFT.COM>
Sent: Wednesday, March 13, 2002 3:03 PM
Subject: Re: COM Design Question: Reusing the coclass clsid + inter face
IIDs

> see inline...
>
> > -----Original Message-----
> > From: Sathia Thirumal [mailto:sathiatMICROSOFT.COM]
> > Sent: 13 March 2002 05:17
> > To: DCOMDISCUSS.MICROSOFT.COM
> > Subject: [DCOM] COM Design Question: Reusing the coclass clsid +
> > interface IIDs
> >
> >
> > Hi
> >
> > I have 2 activex controls one is v1 and another is v2. I
> > havent released v2
> > yet, but I am working on making sure it is fully backward
> > compatible with
> > v1 object model. The problem Im facing now is that I have 2
> > controls (once
> > I release v2) that I have to maintain now. But I dont want to
> > break any of
> > my clients' solutions that depend on my already-released v1
> > object. So my
> > plan was to make the CLSID of the coclass of v2 object the SAME as the
> > CLSID of the v1 coclass. This, in my view, would achieve the
> > following:
> >
> > 1. When the new control (v2) is dropped on the user's machine and
> > registered it would overwrite the v1 info for the coclass in
> > the registry.
> > This would result in all the existing v1 solutions to start
> > using v2 object.
> >
> > My questions are:
> >
> > 1. Am I violating any COM rules by reusing the coclass CLSID?
> Technically no. COMs immutability rules apply to interfaces not coclasses.
> In practice if you change the number and nature of the set of interfaces
you
> implement then you could break some clients.
>
> > 2. My primary IDispatch interface (which is an
> > [oleautomation] interface)
> > exposed on v2 has been extended to include more props, methods - all
> > existing ones are intact. Will it cause a problem if I reuse
> > this interface
> > IID without changing it between v1 and v2? Will the client
> > solutions that
> > were written (in script, c++, etc) around this interface fail?
>
> Yes, sod's law being what it is, you will encounter the case where a
client
> expecting a new v2 server gets hold of an old v1 one, and can't tell the
> difference until the world goes bang.
>
> > 3. If the answer for (2) is that the clients will fail, then
> > can I change
> > the IIDs - but leave the coclass CLSID alone between v1 and
> > v2? Will that
> > fix it? My thinking is that since the clients will be querying for
> > IDispatch, they wont bother about the IIDs?
>
> If you can guarantee that all your clients use "late binding" then you
might
> be lucky. In general you cant make any such assumptions, and your only
real
> solution is to support both old and new interfaces.
>
> >
> > Thanks
> > Sathia.
> >
>
> ---------------------------------------------------------
> Phil Reynolds
> Ridgeway Systems and Software
> Tel: +44 118 938 1211
> Fax: +44 118 935 4444
> mailto:preynoldsridgewaysystems.com
> http://www.ridgewaysystems.com
>
> ----------------------------------------------------------------
> Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
> contains important info. Save time, search the archives at
> http://discuss.microsoft.com/archives/index.html .
> To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM
>

----------------------------------------------------------------
Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
contains important info. Save time, search the archives at
http://discuss.microsoft.com/archives/index.html .
To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]