Unable to create registration information for file named X.dll

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Aleksey Tkachenko - 22 Apr 2004 12:37 GMT

Hi All

X.dll is COM object linked to Y.dll, which is not COM object.
X.dll was successfully built, registered while build by regsvr32,
worked and added to deployment project.
Y.dll was added to deployment project too.

But while building deployment project marvelous regcap.exe
cannot load X.dll and create reg file for it
(possibly because quite strange current paths it uses)
producing the warning mentioned in subj.

If I put the Y.dll directly near the remarkable regcap.exe in outstanding

E:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Tools\Deployment

directory then this rubbish works perfectly well.

So what obvious option I forgot to tune in our blameless VS?

Aleksey.

Reply to this Message

Phil Wilson - 22 Apr 2004 16:58 GMT

This is nothing to do with VS.NET and everything to do with the way COM
registration works. All these tools calls DllRegisterServer in the DLL and
spy on the created registry entries. For your DLL to load, it requires to
load its dependent DLLs, your Y.DLL. You wouldn't expect an exe to run with
required DLLs missing, similarly a DLL can't run if it can't also load its
dependent DLLs.

Having said that, all you need to do is arrange for X.DLL to be able to find
Y.DLL when being registered. You don't need to do any of this regcap/regsvr
stuff in a VS setup project - just set the Register property on the DLL to
vsdr-Register, and the build of the setup will load the registration data
into the resulting MSI file. Note that this still requires your DLL to load
together with its dependent Y.DLL. The resulting MSI file writes the
registry entries and copies the DLL to the system without needing to load it
during the installation. MSI will also do the right thing if you do a
per-user install. Other registration schemes register for thew entire system
even if you're doing a per-user install.

Signature

Phil Wilson
[MVP Windows Installer]

>
> Hi All
[quoted text clipped - 18 lines]
>
> Aleksey.

Reply to this Message

Aleksey Tkachenko - 23 Apr 2004 05:47 GMT

> This is nothing to do with VS.NET and everything to do with the way COM
> registration works. All these tools calls DllRegisterServer in the DLL and
[quoted text clipped - 5 lines]
> Having said that, all you need to do is arrange for X.DLL to be able to find
> Y.DLL when being registered.

X.DLL and Y.DLL are in the same folder. What more can I do?

While usual building of deployment project with the property "Register"
set to "vsdrpCOM" for X.DLL I have the
"Unable to create registration information for file named X.dll" warning.

If I put the Y.DLL near regcap then it works.

Aleksey.

Reply to this Message

Phil Wilson - 24 Apr 2004 00:23 GMT

It's impossible to know the right answer with knowing something about how
X.DLL links to Y.DLL. Is it a static link or an explicit LoadLibrary? When
you say "quite strange current path it uses" in your first post, does "it"
mean that X.DLL is using a strange current path?
It seems to me that Y.DLL needs to be in the PATH of the current executable,
which is why it works in the regcap.exe folder. AFAIK this is a bit strange
because COM DLLs by default look for their dependencies in their same folder
(it would be a nightmare to expect client programs to know and install the
dependencies of all their COM servers in the same folder as their
executable).

Signature

Phil Wilson [MVP Windows Installer]
----

> > This is nothing to do with VS.NET and everything to do with the way COM
> > registration works. All these tools calls DllRegisterServer in the DLL and
[quoted text clipped - 17 lines]
>
> Aleksey.

Reply to this Message

Aleksey Tkachenko - 24 Apr 2004 09:39 GMT

> It's impossible to know the right answer with knowing something about how
> X.DLL links to Y.DLL. Is it a static link or an explicit LoadLibrary?

It is a static link.

>When
> you say "quite strange current path it uses" in your first post, does "it"
> mean that X.DLL is using a strange current path?

It means that regcap uses the different current paths, but not the path
to X.DLL. I spied this using the code inside the X.DLL. Also I checked
that X.DLL is loaded from its own folder where the Y.DLL is.

> It seems to me that Y.DLL needs to be in the PATH of the current executable,
> which is why it works in the regcap.exe folder.

>AFAIK this is a bit strange
> because COM DLLs by default look for their dependencies in their same folder
> (it would be a nightmare to expect client programs to know and install the
> dependencies of all their COM servers in the same folder as their
> executable).

I suppose that regcap uses something like LoadLibrary with the full path
to X.DLL, but I don't know what is going on then.

> > > This is nothing to do with VS.NET and everything to do with the way COM
> > > registration works. All these tools calls DllRegisterServer in the DLL
[quoted text clipped - 20 lines]
> >
> > Aleksey.

Reply to this Message

Rate this thread:

Unable to create registration information for file named X.dll

Free Magazines