Unable to create registration information for file named X.dll
Aleksey Tkachenko
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.
Phil Wilson
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.
--
Phil Wilson
[MVP Windows Installer]
"Aleksey Tkachenko" <no_...@no.ru> wrote in message
news:eVqgA5FK...@TK2MSFTNGP09.phx.gbl...
Aleksey Tkachenko
> 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.
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.
Phil Wilson
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).
--
Phil Wilson [MVP Windows Installer]
Aleksey Tkachenko
"Phil Wilson" <Phil....@unisys.spamcom> wrote in message
news:OQCSBoYK...@TK2MSFTNGP10.phx.gbl...
> 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.