Can ActiveX interop require minimum version of the control?

[Steve Alpert]

With JScript in html, the object codebase can be given a version number which
will do a pull from the server if the user has an earlier version.

Is there a comparable setup inside an interop wrapper? The generated wrapper
seems to have no such ability out of the box.

thanks,
/steveA

[Alvin Bruney [MVP]]

It shouldn't matter. The wrapper doesn't implement methods. In the case
where you have added a new method, you would need to rebuild the wrapper and
the pull would always be for the latest. Are you wanting to run legacy and
updated on the same machine?

--
Regards,
Alvin Bruney
------------------------------------------------------
Shameless author plug
Excel Services for .NET - MS Press
Professional VSTO 2005 - Wrox/Wiley
OWC Black Book www.lulu.com/owc

"Steve Alpert" <sr*@newsgroups.nospamwrote in message
news:%2****************@TK2MSFTNGP03.phx.gbl...

With JScript in html, the object codebase can be given a version number
which will do a pull from the server if the user has an earlier version.

Is there a comparable setup inside an interop wrapper? The generated
wrapper seems to have no such ability out of the box.

thanks,
/steveA

[Steve Alpert]

The problem is that as bugs are fixed in the control, we've been incrementing an
internal version but not a control version. If we have a .Net based product
running inside a browser, a newer instance of the control is not loaded from the
server, the user continues to use the old one. I don't want the legacy control
to be used. I don't want to update the ActiveX "CurVer" for each bugfix. The
interface hasn't changed.

In HTML/JScript, the version tag at least asks the user to download a new version.

/steveA

Alvin Bruney [MVP] wrote:

It shouldn't matter. The wrapper doesn't implement methods. In the case
where you have added a new method, you would need to rebuild the wrapper and
the pull would always be for the latest. Are you wanting to run legacy and
updated on the same machine?

--
Steve Alpert
my email fgrir.nycreg @ tr.pbz is encrypted with ROT13 (www.rot13.org) and spaces

[Alvin Bruney [MVP]]

I see. How are you loading the control? If you are running embedded in a
browser, then the object tag written to the browser contains the codebase
attribute that you can set appropriately. Is that not working for you?

If you have already tried that approach and failed, can you write a short
but complete program that demonstrates the problem? I'd like to take a much
closer look at this issue. I assume this only fails for a legacy component
since a .NET assembly doesn't require a wrapper.

--
Regards,
Alvin Bruney
------------------------------------------------------
Shameless author plug
Excel Services for .NET - MS Press
Professional VSTO 2005 - Wrox/Wiley
OWC Black Book www.lulu.com/owc

"Steve Alpert" <sr*@newsgroups.nospamwrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl...

The problem is that as bugs are fixed in the control, we've been
incrementing an internal version but not a control version. If we have a
.Net based product running inside a browser, a newer instance of the
control is not loaded from the server, the user continues to use the old
one. I don't want the legacy control to be used. I don't want to update
the ActiveX "CurVer" for each bugfix. The interface hasn't changed.

In HTML/JScript, the version tag at least asks the user to download a new
version.

/steveA

Alvin Bruney [MVP] wrote:

>It shouldn't matter. The wrapper doesn't implement methods. In the case
where you have added a new method, you would need to rebuild the wrapper
and the pull would always be for the latest. Are you wanting to run
legacy and updated on the same machine?

--
Steve Alpert
my email fgrir.nycreg @ tr.pbz is encrypted with ROT13 (www.rot13.org) and
spaces

[Steve Alpert]

We have two flavors of "clients." One set uses push technology with locked-down
desktops and the other uses a pull technology. For those with pull, the
solution is to include a "virtual" product that has the old html object tags and
that at least nags them. The problem is that if they say NO, the system
continues and the .Net interop just starts up with the prior installed controls.
When all use of the object was based on html tags, it wouldn't start unless
they had at least the described version.

I don't know if I can cobble together and example that easily illustrates this.

/steveA

Alvin Bruney [MVP] wrote:

I see. How are you loading the control? If you are running embedded in a
browser, then the object tag written to the browser contains the codebase
attribute that you can set appropriately. Is that not working for you?

If you have already tried that approach and failed, can you write a short
but complete program that demonstrates the problem? I'd like to take a much
closer look at this issue. I assume this only fails for a legacy component
since a .NET assembly doesn't require a wrapper.