C++/CLI COM component deployment

[Volker Hetzer]

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

 

[Brian Muth]

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
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(...)

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)

 

[Volker Hetzer]

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.

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)

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

 

[Ben Voigt]

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?

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.

 

[Brian Muth]

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

 

[Volker Hetzer]

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:


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.

Sounds perfect!

Thanks a lot!
Volker