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.
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...
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.
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.