Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Interops & Install Packages

12 views
Skip to first unread message

CapCity

unread,
Feb 15, 2008, 2:24:25 PM2/15/08
to
Hopefully I can explain this well enough, and apologize if this is a trivial
matter. I've searched and couldn't find anything.

I needed to make some changes to a dot net application (framework 2.0). The
project has references set to some DLLs that reside in a subfolder (obj) of
the project. If it matters, these DLLs allow the application to execute SAS
programs. These DLLs are all named Interop.<name>.dll, leading me to believe
that they are wrapped com objects. Anyway, worked fine, both running from
the IDE and also using the exe file in the Release folder.

The properties for these are Aliases=global; File Type=Assembly;
Resolved=true; Specific Version=false; Strong Name=false;

I re-built the associated install project and tested it on my machine.
Installed OK, but the application errors when it tries to execute the SAS
file. The message is "Retrieving the COM class factory for component with
CLSID {6964D000-4E64-11D2-B94D-00C04F81BC00} failed due to the following
error: 80040154." Googling shows this to be "class not registered."

When I now try to run it from the IDE, I get the same error. I've tried
another application, with references set to the same DLLs but in a different
location, and get this error. So it seems to be more than just this
application.

I uninstalled the application and ran from the IDE - same error.

I wasn't expecting these DLLs to get registered, but I tried (from the
command line) to unregister them. I get a message saying that the DLL was
loaded but the DLLUnregisterServer entry point was not found. I'm guessing
it means they weren't registered, which is what I would expect.

I've even removed the references from the project and re-added them, but no
luck.

I'm not sure what happens when the installer does it's magic. In the
installer project these are listed in detected dependancies.
PackageAs=vsdpaDefault, Register=vsdraDoNotRegister.

Does anyone have any insight on what I can do to rectify this? It seems to
me that the install wrecked things.

Thanks in Advance


Ralph

unread,
Feb 16, 2008, 3:03:16 PM2/16/08
to

"CapCity" <sgomori at yahoo dot com> wrote in message
news:ON5UkhAc...@TK2MSFTNGP06.phx.gbl...
<snipped>

Not sure what is happening with the install and without more information it
is difficult to provide specific help. (I'm a bit confused as to who is
what. <g>)

It may help to know that the above errors are NOT complaints about
'registration' but are telling you that the component delivered by the
Install package is not an ActiveX (COM) component. Which it isn't. This is
normal, as .Net can't create a COM component.

Somewhere in the mix you should have a COM Callable Wrapper (CCW). It is the
wrapper a COM client connects to to gain access to the .Net dll. Or vice
versa, a .Net component must supply a wrapper. It appears the development
box has it, the target doesn't.

IIRC, the SAS site contains numerious examples. You might want to look
there.

-ralph


CapCity

unread,
Feb 21, 2008, 12:47:06 PM2/21/08
to

"Ralph" <nt_cons...@yahoo.com> wrote in message
news:e1hu5cNc...@TK2MSFTNGP04.phx.gbl...

It's the same box. We tested the install on the development box, and now the
application (or any other application) can no longer use these DLLs as they
once did.

>
> IIRC, the SAS site contains numerious examples. You might want to look
> there.
>

The site contains examples on their use, in code. We've used the DLLs in
code w no problems for some time now. It's just that since we used an
install containing these DLLs that nothing no longer works.

> -ralph
>
>


Ralph

unread,
Feb 22, 2008, 7:54:12 PM2/22/08
to

"CapCity" <sgomori at yahoo dot com> wrote in message
news:OSClHHLd...@TK2MSFTNGP03.phx.gbl...
>
<snipped>

> >
> > Somewhere in the mix you should have a COM Callable Wrapper (CCW). It is
> > the
> > wrapper a COM client connects to to gain access to the .Net dll. Or vice
> > versa, a .Net component must supply a wrapper. It appears the
development
> > box has it, the target doesn't.
>
> It's the same box. We tested the install on the development box, and now
the
> application (or any other application) can no longer use these DLLs as
they
> once did.
>
> >
> > IIRC, the SAS site contains numerious examples. You might want to look
> > there.
> >
>
> The site contains examples on their use, in code. We've used the DLLs in
> code w no problems for some time now. It's just that since we used an
> install containing these DLLs that nothing no longer works.
>

That makes a bit more sense. (I couldn't understand how you would have a
compoent without a 'wrapper'.)

Something obviously got corrupted. (Duh! <g>)
See if this article helps. Its all I found that discusses Install problems.
http://www.simple-talk.com/dotnet/visual-studio/build-and-deploy-a-.net-com-assembly/

-ralph


0 new messages