Creating COM Objects in VB.NET

[Wilbur Slice]

I need to write some VB.NET objects that can be called from another
environment (a Progress app, specifically). I'm having some
difficulty getting this to work.

My first assumption was that I should write a COM object. Is this a
good approach? Or is there a better one?

I wrote the new VB.NET object and included a COM Class object. All is
fine and the system creates a TLB file and everything. It all works
great on my development machine. But when I try to deploy it to the
target (XP-PRO) machine and write a test subroutine in Word using VBA
to access the object, I fail. It works in VBA on my development
machine, but not on the machine I'm deploying to.

First, I can't see my COM object when I try to add a reference in VBA.
So I use regasm.exe to register the COM object DLL - it reports
success. But my COM object still doesn't show up in Word VBA's list
of COM objects that I can reference. But when I do a "browse", I can
see it, and the TLB file. I can't reference the DLL, but I *can*
reference the TLB.

And then VBA knows about my COM object and I can add it to my VBA code
(intellisense works and everything). But then when I run the VBA
subroutine, when it tries to run a function from my VBA object I get
an error saying "File or assembly name MKRCOM, or one of its
dependencies, was not found."
Does anybody know what I need to do? Or can anyone point me to a
resource that describes how to develop COM objects under VB.NET that
can be called by non -.NET programs?
Thanks in advance...

[Ross Presser]

On Fri, 28 Oct 2005 14:06:00 -0500, Wilbur Slice wrote:

Does anybody know what I need to do? Or can anyone point me to a
resource that describes how to develop COM objects under VB.NET that
can be called by non -.NET programs?

Just a guess, but have you ruled out .NET permission issues?

I haven't done what you're doing specifically, but I do have a situation
where my .NET program invokes a COM object and passes it .NET objects,
which then the COM object calls methods on. This works fine.
Specifically, the COM object is the Microsoft Script Control, and the .NET
object is a specialized collection class.

[Wilbur Slice]

On Fri, 28 Oct 2005 15:25:32 -0400, Ross Presser
<rp******@NOSPAMgmail.com.invalid> wrote:

On Fri, 28 Oct 2005 14:06:00 -0500, Wilbur Slice wrote:

Does anybody know what I need to do? Or can anyone point me to a
resource that describes how to develop COM objects under VB.NET that
can be called by non -.NET programs?
Just a guess, but have you ruled out .NET permission issues?

I don't know what you mean by that - could you elaborate?

I think it has something to do with registering the objects somehow,
because apparently Visual Studio does it for me automatically during
development - I have none of these problems on my development machine.
But on the machine I'm deploying to, which does not have Visual Studio
on it, it doesn't work.


I haven't done what you're doing specifically, but I do have a situation
where my .NET program invokes a COM object and passes it .NET objects,
which then the COM object calls methods on. This works fine.
Specifically, the COM object is the Microsoft Script Control, and the .NET
object is a specialized collection class.

[TrtnJohn]

Make sure you have Register fo COM Interop checked in the project properties
for the DLL before you build it.
It is in Configuration Properties->Build options
"Wilbur Slice" wrote:

I need to write some VB.NET objects that can be called from another
environment (a Progress app, specifically). I'm having some
difficulty getting this to work.

My first assumption was that I should write a COM object. Is this a
good approach? Or is there a better one?

I wrote the new VB.NET object and included a COM Class object. All is
fine and the system creates a TLB file and everything. It all works
great on my development machine. But when I try to deploy it to the
target (XP-PRO) machine and write a test subroutine in Word using VBA
to access the object, I fail. It works in VBA on my development
machine, but not on the machine I'm deploying to.

First, I can't see my COM object when I try to add a reference in VBA.
So I use regasm.exe to register the COM object DLL - it reports
success. But my COM object still doesn't show up in Word VBA's list
of COM objects that I can reference. But when I do a "browse", I can
see it, and the TLB file. I can't reference the DLL, but I *can*
reference the TLB.

And then VBA knows about my COM object and I can add it to my VBA code
(intellisense works and everything). But then when I run the VBA
subroutine, when it tries to run a function from my VBA object I get
an error saying "File or assembly name MKRCOM, or one of its
dependencies, was not found."
Does anybody know what I need to do? Or can anyone point me to a
resource that describes how to develop COM objects under VB.NET that
can be called by non -.NET programs?
Thanks in advance...

[Wilbur Slice]

On Fri, 28 Oct 2005 16:45:01 -0700, "TrtnJohn"
<Tr******@discussions.microsoft.com> wrote:

Make sure you have Register fo COM Interop checked in the project properties
for the DLL before you build it.
It is in Configuration Properties->Build options

I did. Didn't make any difference.

But here's what I found: I figured that if Visual Studio was doing
all the necessary things (my objects work fine on the development
machine), then maybe I should create a Deployment project for my COM
objects and install them on the target machine that way, instead of
just trying to take the DLL and TLB files over and manually installing
them.

And sure enough, that worked. Whatever it is that Visual Studio is
doing, the deployment install procedure is doing as well, and my
objects now work on the target machine. I still don't know what
exactly it was that was missing or was being done wrong, but this way
works, so I think I'm good to go now.

[TrtnJohn]

You can also use Regasm to register the dll pn the target machine.

"Wilbur Slice" wrote:

On Fri, 28 Oct 2005 16:45:01 -0700, "TrtnJohn"
<Tr******@discussions.microsoft.com> wrote:

Make sure you have Register fo COM Interop checked in the project properties
for the DLL before you build it.
It is in Configuration Properties->Build options

I did. Didn't make any difference.

But here's what I found: I figured that if Visual Studio was doing
all the necessary things (my objects work fine on the development
machine), then maybe I should create a Deployment project for my COM
objects and install them on the target machine that way, instead of
just trying to take the DLL and TLB files over and manually installing
them.

And sure enough, that worked. Whatever it is that Visual Studio is
doing, the deployment install procedure is doing as well, and my
objects now work on the target machine. I still don't know what
exactly it was that was missing or was being done wrong, but this way
works, so I think I'm good to go now.

[Wilbur Slice]

On Mon, 31 Oct 2005 11:57:17 -0800, "TrtnJohn"
<Tr******@discussions.microsoft.com> wrote:

You can also use Regasm to register the dll pn the target machine.
No, as I said earlier, I tried that and it didn't work.

"Wilbur Slice" wrote:

On Fri, 28 Oct 2005 16:45:01 -0700, "TrtnJohn"
<Tr******@discussions.microsoft.com> wrote:

>Make sure you have Register fo COM Interop checked in the project properties
>for the DLL before you build it.
>
>
>It is in Configuration Properties->Build options

I did. Didn't make any difference.

But here's what I found: I figured that if Visual Studio was doing
all the necessary things (my objects work fine on the development
machine), then maybe I should create a Deployment project for my COM
objects and install them on the target machine that way, instead of
just trying to take the DLL and TLB files over and manually installing
them.

And sure enough, that worked. Whatever it is that Visual Studio is
doing, the deployment install procedure is doing as well, and my
objects now work on the target machine. I still don't know what
exactly it was that was missing or was being done wrong, but this way
works, so I think I'm good to go now.

[DanP]

I am having the exact same problem! However, it is happening to me on the
development system too, but I am using Visual Basic Express Edition. What is
even stranger is that the exact same assembly taken to a machine that has the
full version of Visual Studio on it will work. Also strange is that on the
machine with only Visual Basic Express I can access the object perfectly from
VB6, but not from VBA in Office XP or Office 2003.

While the deployment workaround may help (I will try it), I am still very
uncomfortable not knowing what the problem is. I am going to make a separate
post for this issue too.
"Wilbur Slice" wrote:

On Fri, 28 Oct 2005 16:45:01 -0700, "TrtnJohn"
<Tr******@discussions.microsoft.com> wrote:

Make sure you have Register fo COM Interop checked in the project properties
for the DLL before you build it.
It is in Configuration Properties->Build options

I did. Didn't make any difference.

But here's what I found: I figured that if Visual Studio was doing
all the necessary things (my objects work fine on the development
machine), then maybe I should create a Deployment project for my COM
objects and install them on the target machine that way, instead of
just trying to take the DLL and TLB files over and manually installing
them.

And sure enough, that worked. Whatever it is that Visual Studio is
doing, the deployment install procedure is doing as well, and my
objects now work on the target machine. I still don't know what
exactly it was that was missing or was being done wrong, but this way
works, so I think I'm good to go now.

[DanP]

I was able to find the explanation and solution in another post:

This looked like a bug on Microsoft's part. I found a work around by
first creating a Excel.exe.config file with these entries:

<?xml version="1.0" encoding="Windows-1252"?>
<configuration>
<startup>
<supportedRuntime version="v2.0.50727" />
<supportedRuntime version="v2.0.50110" />
<supportedRuntime version="v1.1.4322" />
<supportedRuntime version="v1.0.3705" />
<requiredRuntime version="v1.0.3705" />
</startup>
</configuration>

Then, when I searched further on the net, found this update fix from
Microsoft which fixed the problem even without the config file above:
http://www.microsoft.com/downloads/d...displaylang=en

hope this helps.
thanks

"DanP" wrote:

I am having the exact same problem! However, it is happening to me on the
development system too, but I am using Visual Basic Express Edition. What is
even stranger is that the exact same assembly taken to a machine that has the
full version of Visual Studio on it will work. Also strange is that on the
machine with only Visual Basic Express I can access the object perfectly from
VB6, but not from VBA in Office XP or Office 2003.

While the deployment workaround may help (I will try it), I am still very
uncomfortable not knowing what the problem is. I am going to make a separate
post for this issue too.
"Wilbur Slice" wrote:

On Fri, 28 Oct 2005 16:45:01 -0700, "TrtnJohn"
<Tr******@discussions.microsoft.com> wrote:

Make sure you have Register fo COM Interop checked in the project properties
for the DLL before you build it.
It is in Configuration Properties->Build options

I did. Didn't make any difference.

But here's what I found: I figured that if Visual Studio was doing
all the necessary things (my objects work fine on the development
machine), then maybe I should create a Deployment project for my COM
objects and install them on the target machine that way, instead of
just trying to take the DLL and TLB files over and manually installing
them.

And sure enough, that worked. Whatever it is that Visual Studio is
doing, the deployment install procedure is doing as well, and my
objects now work on the target machine. I still don't know what
exactly it was that was missing or was being done wrong, but this way
works, so I think I'm good to go now.