C++/CLI COM component deployment

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Volker Hetzer - 25 Jan 2007 15:19 GMT

Hi!
I've done my first little COM component (using the clr) and after signing,
regasm and gacutil I can call it from vbscript.
set X = createobject("ComComponent.Class1")
msgBox X.Testfunktion(2)

But the problem we're facing is that for a real development of several
components (currently existing as scripting components) we need to be able
to call them by their path names. The situation is this:
We want to use those components to extend a PCB CAD tool.
At any time several users work with several projects, each CAD-Tool session
works with one project only. We typically release our components first for one
project/user combination only and after this "beta" test for all projects.
So, we have the following directory structure:
...\BETA.ComponentName.PCBName.Username
...\FINAL.ComponentName.ALL.ALL
Those directories sit in a shared network drive and we really can't afford
to register and "install" each component on each client PC. We will release
very often, on average daily.

I'm looking for a way that lets me instantiate a component in VBScript
like this:
Dirname = figurOutDirName(ComponentName, PCBName,Username)
set X = createobject(Dirname&"\whatever.something")
X.myMethod(...)

Is this possible?

Lots of Greetings!
Volker

Signature

For email replies, please substitute the obvious.

Reply to this Message

Brian Muth - 26 Jan 2007 02:00 GMT

> Hi!
> I've done my first little COM component (using the clr) and after signing,
> regasm and gacutil I can call it from vbscript.
> set X = createobject("ComComponent.Class1")
> msgBox X.Testfunktion(2)

Well, you haven't really created a COM object. What you have done is create
a .NET object and wrapped it inside a COM interop. (Maybe I'm nitpicking).

> But the problem we're facing is that for a real development of several
> components (currently existing as scripting components) we need to be able
[quoted text clipped - 18 lines]
> set X = createobject(Dirname&"\whatever.something")
> X.myMethod(...)

Why not do it this way. Create two "COM objects", one that is beta and one
that is final. Each have different ProgID's and different GUID's

Then...

ProgId = figureOutProgId(ComponentName, PCBName, Username)
Set X = CreateObject (ProgId)

Reply to this Message

Volker Hetzer - 26 Jan 2007 09:40 GMT

Brian Muth schrieb:

>> Hi!
>> I've done my first little COM component (using the clr) and after signing,
[quoted text clipped - 4 lines]
> Well, you haven't really created a COM object. What you have done is create
> a .NET object and wrapped it inside a COM interop. (Maybe I'm nitpicking).

I know, but you re correct nevertheless. :-)

>> But the problem we're facing is that for a real development of several
>> components (currently existing as scripting components) we need to be able
[quoted text clipped - 26 lines]
> ProgId = figureOutProgId(ComponentName, PCBName, Username)
> Set X = CreateObject (ProgId)

And in the directory structure I find a description file with the correct ProgID?
Sounds good.
Now there remain two issues.
1) Do I have to "install" the assemblies on each client machine? I'd very much
like to avoid this.
2) Can I utilize the manifest or config file and record some properties
("ForProjectOnly=PCBName") there? And can then the "figureOutProgId" function
or component somehow browse the available shared assemblies?

Lots of Greetings and Thanks!
Volker

Signature

For email replies, please substitute the obvious.

Reply to this Message

Brian Muth - 26 Jan 2007 20:00 GMT

To be honest, I like Ben's solution better than mine because it gets around
the registration problem. In other words, it is easier to deploy and
register an "object factory" once. Subsequent .NET objects can be simply
copied.

Brian

Reply to this Message

Ben Voigt - 26 Jan 2007 14:16 GMT

> Hi!
> I've done my first little COM component (using the clr) and after signing,
[quoted text clipped - 26 lines]
>
> Is this possible?

No it's not, but you can get the same effect.

Create a factory class in .NET which is exposed via COM, and contains a
CreateComponent(ComponentName, PcbName, UserName) method. Then your VB will
do:

> set X = createobject(factoryClsid).CreateComponent(ComponentName,
> PCBName,Username)
> X.myMethod(...)

Your Factory object will use Assembly.Load(fileName) and Activator class,
which does not require any additional registration. If you're using early
binding, then the COM interfaces used by the consumer will need to be in a
registered typelib, however.

> Lots of Greetings!
> Volker

Reply to this Message

Volker Hetzer - 29 Jan 2007 12:54 GMT

Ben Voigt schrieb:

>> Hi!
>> I've done my first little COM component (using the clr) and after signing,
[quoted text clipped - 41 lines]
> binding, then the COM interfaces used by the consumer will need to be in a
> registered typelib, however.

Sounds perfect!

Thanks a lot!
Volker

Signature

For email replies, please substitute the obvious.

Reply to this Message

Rate this thread:

C++/CLI COM component deployment

Free Magazines