tlb file problem "Active X component can't create object" when used in vba routine

[Keith G Hicks]

This was originally in "microsoft.public.dotnet.languages.vb" but I'm not
getting any answers ther so I thought I'd try it here.


I created a dll for com (in vb.net 2005) so that I could access it's
functions from an ms access app. I created the tlb file successfully. On my
dev machine I referenced it in my access app and wrote the code that uses
one of the functions. Everything ran just fine. No hiccups. The code
performed the calculation as expected. Today I went to install this on a
client workstation. I copied the tlb file into the same folder that the
access adp file sits in. I was able to set the reference without any
trouble. I was also able to use intellisense to redo some of the code taht
uses one fo the functions. But when I ran the code I got error 429 "Active
X component can't create object"

Dim dHeight As Double
Dim oHeight As New DlnpFntCalcsForCom.DlnpFntCalcsForCom

Me.NoticeTextHeight = oHeight.NoticeTextHeight(Me.FullNoticeText,
sClipFontName, dClipFontSize, dClipWidth)
Me.FolioCount = Ceiling(Me.NoticeTextHeight / 1.5) 'Ceiling is a UDF in
my app

The error occurs on line 3 in the code above.

I tried solving the problem by copying all the files in my bin/release
folder of my (dll, tlb, xml, ppb) but that didn't work either.

I read something about not having to register tlb files on the local machine
so I have not done that and found little that suggested I should or even
how. I also read something about being sure that the office app that
references the tlb file should be the same version as the one on the dev
machine. Both are running office 03 so that should not be a problem. And
lastly I found some notes from someone that suggested that the .net
framework needs to be on the workstation but followups implied that was not
necessary and it seems like nonsense to me anyway.

Does anyone have any ideas on this. I'm a bit under a crunch with this now
and need to get it working in the next 18 hours. I sure hope someone has
seen this before and knows what I need to do.


Thanks,

Keith

 

[ErezM via AccessMonster.com]

hi keith
as nonsense as it may (?) sound, you most certainly need the dot.net
framework 2 to be installed on a computer that is supposed to run a dotnet
framework 2 dll (it's a managed code dll, someone needs to manage it!)
having that done (it's a free download from microsoft), i found, in contrast
to some sources, that you need to register the assembly on the client
computer. use start -> run... and write:
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\RegAsm.exe
YourDllFullPathAndFileName /tlb
(make sure this path is the same on the client computer AFTER installing
DotNet2)
i must admit that my error messages were different when i tried to use a self
created .net dll, so i hope it'll still workout for you

good luck

 

[Keith G Hicks]

Thanks very much for your input. I have a follow up question.

The .net 2.0 framework is on the server where I originally had the tlb file.
But I'm referencing that tlb file in an Access app that is on a workstation.
Does the workstation think it needs the framework to reference the tlb file
on the server? Or do you think it would be sufficient to register the tlb
file on the server? We want to avoid as much as possible having to install
anything else on all of the workstations.

Keith

 

[ErezM via AccessMonster.com]

hi
the actual file storage place is less important (you can register a network
dll file)
but the dll is activated and used on the client's machine, therefore as long
as i know, the client's machine needs to be able to run the managed code in
the dll, meaning - you do need .net2 on the local machine running the access
file that needs the dll

Thanks very much for your input. I have a follow up question.

The .net 2.0 framework is on the server where I originally had the tlb file.
But I'm referencing that tlb file in an Access app that is on a workstation.
Does the workstation think it needs the framework to reference the tlb file
on the server? Or do you think it would be sufficient to register the tlb
file on the server? We want to avoid as much as possible having to install
anything else on all of the workstations.

Keith

hi keith
as nonsense as it may (?) sound, you most certainly need the dot.net

[quoted text clipped - 61 lines]

 

[ErezM via AccessMonster.com]

and another thing:
if it's cricial not to install anything on the client, consider using Web-
services
you can reference them from access, and then use them as any other functions,
but the code to operate them sits somewhere on a web server,

hi
the actual file storage place is less important (you can register a network
dll file)
but the dll is activated and used on the client's machine, therefore as long
as i know, the client's machine needs to be able to run the managed code in
the dll, meaning - you do need .net2 on the local machine running the access
file that needs the dll

Thanks very much for your input. I have a follow up question.

[quoted text clipped - 12 lines]

 

[Keith G Hicks]

From the limited info I find online, I need to install SOAP on client
machines to reference a webservice. I'm also finding that SOAP is depricated
due to .net framework which implies to me that I'd still need .net framework
on the workstations if not using SOAP. I'm finding very little useful info
out there for someone like me that's not experienced with this. Can you
point me in the right direction? I started a new thread "calling webservice
from access" before I realzied that I may be heading in the wrong direction
but I'm not sure at all right now.

Keith

and another thing:
if it's cricial not to install anything on the client, consider using Web-
services
you can reference them from access, and then use them as any other functions,
but the code to operate them sits somewhere on a web server,

hi
the actual file storage place is less important (you can register a network
dll file)
but the dll is activated and used on the client's machine, therefore as long
as i know, the client's machine needs to be able to run the managed code in
the dll, meaning - you do need .net2 on the local machine running the access
file that needs the dll

Thanks very much for your input. I have a follow up question.

[quoted text clipped - 12 lines]

 

[ErezM via AccessMonster.com]

hi again
you do need to install web service toolkit. look for "Office XP Web Services
Toolkit 2.0" in microsoft downloads.
once you install this, you just add a reference (not understanding of soap is
needed)

From the limited info I find online, I need to install SOAP on client
machines to reference a webservice. I'm also finding that SOAP is depricated
due to .net framework which implies to me that I'd still need .net framework
on the workstations if not using SOAP. I'm finding very little useful info
out there for someone like me that's not experienced with this. Can you
point me in the right direction? I started a new thread "calling webservice
from access" before I realzied that I may be heading in the wrong direction
but I'm not sure at all right now.

Keith

and another thing:
if it's cricial not to install anything on the client, consider using Web-

[quoted text clipped - 14 lines]

[quoted text clipped - 12 lines]