ARRRRRGGGG!! Visual Studio 2005 Install Builder Not Finding DLL Entry Point
Le Chaud Lapin
a good review on first use. I always get nervous doing that, but I
was in a good mood and figured I would take a chance.
I regret doing that.
I have a file call TDD.DLL. It exports DllUnregisterServer. I have
been registering and unregistering this DLL for nearly a decade using
regsvr32, so I know that the function name is exported correctly.
Today I tried to add this DLL as a custom action using Visual Studio
2005 Professional Edition Windows Install builder. Here is the
message I get when I try to build the .MSI package:
ERROR: Entry point 'DllUnregisterServer' not found in module 'C:
\WINDOWS\system32\TDD.DLL' for custom action 'TDD.DLL'.
Build process cancelled
========== Build: 0 succeeded, 1 failed, 9 up-to-date, 0 skipped
==========
I used Depends to make sure that DllUnregisterServer is exported. I
checked and double-checked the name of the function. There is no name
decoration. The file is not in use.
I am an experienced software engineer.
MICROSOFT!!!! WTF !!!???
Will someone please tell me what is going on?
-Le Chaud Lapin-
![Richard [Microsoft Windows Installer MVP]'s profile photo](https://lh3.googleusercontent.com/a/default-user=s40-c)
Richard [Microsoft Windows Installer MVP]
"Le Chaud Lapin" <jaibu...@gmail.com> spake the secret code
<1175662343.6...@n59g2000hsh.googlegroups.com> thusly:
>Will someone please tell me what is going on?
Just because a symbol is exported doesn't mean that you should use it
as a custom action. VS.NET is probably special-casing out the well
known entry points DllRegisterServer and DllUnregisterServer to keep
you from making a mistake.
Besides, you don't need to use a custom action to register COM
objects. Just use the Registry.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://blogs.xmission.com/legalize/>
Le Chaud Lapin
[Microsoft Windows Installer MVP]) wrote:
> Just because a symbol is exported doesn't mean that you should use it
> as a custom action. VS.NET is probably special-casing out the well
> known entry points DllRegisterServer and DllUnregisterServer to keep
> you from making a mistake.
>
> Besides, you don't need to use a custom action to register COM
> objects. Just use the Registry.
> --
Well, it is nice to see an MVP responding to my post. I was expecting
the worst this morning (no replies at all), so I really appreciate the
response.
Yesterday was my first attempt at using Microsoft's Installer, and
without thinking, I actually wrote some extra functions inside my
DLL's (I have 3) called Install, and Uninstall. I used Depends to
check and recheck that they were being exported, and that the
spellings were correct with no decoration. It did not work. I only
noticed while reading the documentation that one could change name of
the entry point, so I changed it to what I have been using with
REGSVR32.EXE.
I did think about using the Registry to do it the "simple" way, until
I realized that one of the DLL does non-trivial registry value parsing
in both DllRegisterServer and DllUnregisterServer.
Also, being an engineer, if someone (especially Microsoft) says that
something should work a certain way, and it does not, my very first
inclination is to find out where fault lies:
(1) with what is being stated
(2) with my interpretation of what is being stated
The reason I do this is that, invariably, someone with whom I work
will come across the same problem, and look to me to provide the
answer since I had "experience" with it, and I would much rather have
an answer than shrug my shoulders. I would also like to save the
members of my team from wasting their time trying to make sense out of
something that might be broken.
-Le Chaud Lapin-
Richard [Microsoft Windows Installer MVP]
"Le Chaud Lapin" <jaibu...@gmail.com> spake the secret code
<1175700594.9...@w1g2000hsg.googlegroups.com> thusly:
>Yesterday was my first attempt at using Microsoft's Installer, and
>without thinking, I actually wrote some extra functions inside my
>DLL's (I have 3) called Install, and Uninstall. [...]
So far you haven't said what it is you want these custom actions to
do, so its hard to say whether or not a custom action is the right
thing in this case. Many times I've seen people get frustrated with
trying to do something in a custom action that is supported by a
standard action.
Regardless, I've used the C++ DLL entry point custom action in VS.NET
many times and never had a problem with it. Its hard to give more
specific advice without more specific information about your problem.
Stefan Krueger [MVP]
action must match a specific format:
UINT __stdcall CustomAction(MSIHANDLE hInstall)
(see http://msdn2.microsoft.com/en-us/library/aa368338.aspx)
I guess your DllUnregisterServer doesn't match this prototype.
--
Stefan Krueger
Microsoft Windows Installer MVP
Please post your questions in the newsgroup or vist one of these web sites:
Windows Installer FAQ
http://www.msifaq.com - http://www.msifaq.de
InstallSite - Resources for Setup Developers
http://www.installsite.org
http://www.installsite.de (GERMAN)
"Richard [Microsoft Windows Installer MVP]"
<legaliz...@mail.xmission.com> schrieb im Newsbeitrag
news:OPhFaFtd...@TK2MSFTNGP03.phx.gbl...
Le Chaud Lapin
<skrue...@newsgroups.nospam> wrote:
> I believe that the entry point function for a Windows Installer custom
> action must match a specific format:
>
> UINT __stdcall CustomAction(MSIHANDLE hInstall)
>
>
> I guess your DllUnregisterServer doesn't match this prototype.
>
Thanks Richard and Stefan.
I don't have my code with me now, but this explanation sounds
reasonable, though technically, as far as the parts that matter, my
DllUnregisterServer does match.
What Microsoft should have done, in addition to giving this prototype,
is to specify the decoration, because that would be the cause of the
problem. Note for example, just changing the file to end in .cpp
instead of .c would break what they wrote.
If this turns out to be the problem, then all I would have to do is
make sure my DllUnregisterServer appears in the DLL as
_DllUnregisterServer@4, which is probably what the Visual Studio
expects to see.
Incidentally, anyone who has any custom installer could check this
right now by simply looking at the name of the exported function. If
it has an @ symbol in it, then this is my problem.
-Le Chaud Lapin-
Phil Wilson
exports the DllRegisterServer function *as expected by COM* then you can
just mark the Dll as vsrdfCOM in the file's properties in the setup
projects's IDE. Or mark it as vsrdfCOMSelfReg. --
--
Phil Wilson
[MVP Windows Installer]
"Le Chaud Lapin" <jaibu...@gmail.com> wrote in message
news:1175715525.0...@l77g2000hsb.googlegroups.com...
Le Chaud Lapin
<phil.wil...@wonderware.something.com> wrote:
> If your custom action is just intended to register a COM server and it
> exports the DllRegisterServer function *as expected by COM* then you can
> just mark the Dll as vsrdfCOM in the file's properties in the setup
> projects's IDE. Or mark it as vsrdfCOMSelfReg. --
Very interesting indeed. Looking forward to trying this. However, one
other question:
Let's say that my COM dll's fail registration midway. Then what? Who
is responsible for rollback to proper state?
Also, there is Visual Studio, and a tool that we all use to make .MSI
file that is part of Visual Studio. What should I be calling this
tool? Right now mind is blank, as I know I cannot call it the
"Installer Maker".
-Le Chaud Lapin-
Richard [Microsoft Windows Installer MVP]
"Le Chaud Lapin" <jaibu...@gmail.com> spake the secret code
<1175718748.8...@d57g2000hsg.googlegroups.com> thusly:
>Let's say that my COM dll's fail registration midway. Then what? Who
>is responsible for rollback to proper state?
Its your responsibility to undo anything that you had partially done
in your DllRegisterServer. DllRegisterServer is not the recommended
way of doing things for like 8 years.
Le Chaud Lapin
[Microsoft Windows Installer MVP]) wrote:
>
> <1175718748.872754.129...@d57g2000hsg.googlegroups.com> thusly:
>
> >Let's say that my COM dll's fail registration midway. Then what? Who
> >is responsible for rollback to proper state?
>
> Its your responsibility to undo anything that you had partially done
> in your DllRegisterServer. DllRegisterServer is not the recommended
> way of doing things for like 8 years.
Well the, I shall answer you original question. :)
During registration, I must examine a registry key, parse it, see if a
particular substring is in it, and if not, add it. I have to take it
out during registration if it is there. The substring is embedded in
a larger string.
This is what I meant by non-trivial.
That said, what would you recommend?
-Le Chaud Lapin-
Richard [Microsoft Windows Installer MVP]
"Le Chaud Lapin" <jaibu...@gmail.com> spake the secret code
<1175726421.6...@e65g2000hsc.googlegroups.com> thusly:
>During registration, I must examine a registry key, parse it, see if a
>particular substring is in it, and if not, add it. I have to take it
>out during registration if it is there. The substring is embedded in
>a larger string.
All of that seems to have nothing to do with COM registration,
however.
I would use AppSearch to scrape out the registry value into a
property.
I would write a custom action that modifies the string, probably in
script or as a simple C++ DLL custom action.
I would conditionalize the custom action by searching for the
necessary substring in the property populated from the registry value.
Le Chaud Lapin
> exports the DllRegisterServer function *as expected by COM* then you can
> just mark the Dll as vsrdfCOM in the file's properties in the setup
> projects's IDE. Or mark it as vsrdfCOMSelfReg. --
How would I do that. I took me 10 minutes of staring at the
properties window trying to figure out what you were talking about. I
Googled and found nothing. Finally in desperation, I started clicking
randomly, and upon clicking on the output "file", the list of
properties was *doubled* in size. Why Microsoft does this is beyond
me.
Anyhow I tried all of the different "registration" types listed, and I
keep getting this error:
WARNING: Unable to create registration information for file named
'TDD.dll'
Again, I have been registering these DLL using REGSVR32.EXE for nearly
a decade with no problems. All of them contain DllRegisterServer/
UnregisterServer.
Thanks,
-Le Chaud Lapin-
Phil Wilson
typically the result of a missing dependency. There's nothing magic going
on - these tools do the same as regsvr32.exe. If you mark the Dll's Register
property as vsdrfCOMSelfReg then DllRegisterServer gets called automatically
at install time and uninstall and rollback are also done. This works exactly
the same as regsvr32. This can fail if the Dll has dependencies that aren't
installed yet (even if they're in the same MSI file) because you can't
guarantee the order of installation of files. If you mark the Dll as
vsdrfCOM then the build will extract the registration data into the MSI
file, so installing the file just copies the file and creates the registry
entries, and the Dll doesn't need to run, and uninstall and rollback are
also handled. I believe internallly part of what happens is that VS calls
RegCap.exe and uses the resulting .reg file.
--
Phil Wilson
[Microsoft MVP Windows Installer]
"Le Chaud Lapin" <jaibu...@gmail.com> wrote in message
news:1175730084....@o5g2000hsb.googlegroups.com...
Richard [Microsoft Windows Installer MVP]
"Phil Wilson" <phil....@wonderware.something.com> spake the secret code
<OeaK506...@TK2MSFTNGP05.phx.gbl> thusly:
>[...] This can fail if the Dll has dependencies that aren't
>installed yet (even if they're in the same MSI file) because you can't
>guarantee the order of installation of files.
But all the files are installed before the self registration happens,
so it should be fine. Just sequence InstallFiles before
SelfRegModules and you should be fine.
>If you mark the Dll as
>vsdrfCOM then the build will extract the registration data into the MSI
>file,
I've had problems with VS.NET 2003 not extracting all the COM
registration data properly. I don't know if this still happens in
2005. Its better to just inspect what your code needs and use the
Registry table to do it IMO.
Le Chaud Lapin
> so it should be fine. Just sequence InstallFiles before
> SelfRegModules and you should be fine.
Uh....trying to contain my frustration. I am not frustrated wiith any
of you, but with the fact that the only thing I have been able to get
to work so far is putting files in the application directory during
installation. COM self-registration does not work. Installing the
services does not work. Installing the device driver does not work.
I need a win, so let us try something difference. I would like to
focus on something that is most likely going to work.
I have a windows service, and EXE, that takes -install from command
line to install itself.
I inferred from paper that I read on InstallSite that there is a way
to let VS create an MSI file where table contains the same information
that would be supplied to CreateFile.
Now here is the really critical point:
I would like for you to assume that my I.Q. is 85 (should not be hard
to do given all trouble I'm having), and hand-hold me for a bit.
Install a service "externally", using Visual Studio 2005. What should
I do?
Please, by all means, make me feel like an idiot and spell it out. :)
Best Regards,
-Le Chaud Lapin-
Le Chaud Lapin
> I inferred from paper that I read on InstallSite that there is a way
> to let VS create an MSI file where table contains the same information
> that would be supplied to CreateFile.
Of course I meant CreateService, not CreateFile.
Not thinking straight. I am so frustrated right now, I have to sit 1
meter away from my desk to keep the steam from my nose from condensing
on the monitor.
TIA,
-Le Chaud Lapin-
Phil Wilson
other tool uses the built-in Windows Installer ServiceInstall and
ServiceControl tables. There are walkthoughs for installer classes. With the
other tools you use the IDE to describe the service and the tool populates
the ServiceInstall and ServiceControl tables.
The tool I added at InstallSite.org is a way for VS people to avoid
installer classes, your choice or not. The reason is that running code
during the setup is unreliable and most people don't deal properly with
rollback or uninstall. Getting the data intro MSI tables relieves everyone
of running code, regsvr32, installutil, regasm, DllRegisterServer, etc etc.
I suspect you're frustrated because you're new to installation and like a
lot of people thought it would be straightforward. I replied to one of your
other posts saying that it's similar to COM in complexity and content and I
meant it. I wouldn't expect many to master COM in a week, same here with
setups.
--
Phil Wilson
[MVP Windows Installer]
"Le Chaud Lapin" <jaibu...@gmail.com> wrote in message
news:1175803432....@b75g2000hsg.googlegroups.com...
Richard [Microsoft Windows Installer MVP]
"Phil Wilson" <phil....@wonderware.something.com> spake the secret code
<el6znB8d...@TK2MSFTNGP04.phx.gbl> thusly:
>I suspect you're frustrated because you're new to installation and like a
>lot of people thought it would be straightforward. [...]
It is pretty straightforward with VS.NET and a simple Windows
application that just needs to deploy files and a few registry items.
As soon as you bring in COM objects, services, and so-on, then it
leaves the realm of the straightforward and requires that you think
through your approach in MSI terms.
If you need to do COM objects and services on a regular basis, I would
suggest looking at WiX which has a project type add-in for VS.NET.
Le Chaud Lapin
<phil.wil...@wonderware.something.com> wrote:
> VS 2005 wants you to install services with installer classes. Most (every?)
> other tool uses the built-in Windows Installer ServiceInstall and
> ServiceControl tables. There are walkthoughs for installer classes. With the
> other tools you use the IDE to describe the service and the tool populates
> the ServiceInstall and ServiceControl tables.
Link?
> The tool I added at InstallSite.org is a way for VS people to avoid
> installer classes, your choice or not. The reason is that running code
> during the setup is unreliable and most people don't deal properly with
> rollback or uninstall. Getting the data intro MSI tables relieves everyone
> of running code, regsvr32, installutil, regasm, DllRegisterServer, etc etc.
I read your very nice article last night, about the predicament
that .NET programmers find themselves, in, etc.
> I suspect you're frustrated because you're new to installation and like a
> lot of people thought it would be straightforward. I replied to one of your
> other posts saying that it's similar to COM in complexity and content and I
> meant it. I wouldn't expect many to master COM in a week, same here with
> setups.
No that's not why I am frustrated. I feel like a mechanical engineer
who has been designing vehicles for 20 years, trying to find the
keyhole in a new vehicle that just came out by competitor, and upon
asking, 'Where is the keyhole", be informed in pieces about how
pistons work, spark plugs, alternators, dog teeth, etc.
I have write two full-blown COM shell namespace extensions, several
EXE services, several other DLL'S, several "normal" EXE's, and a non-
trivial NDIS device driver. All modules are multi-threaded and
involve complex algorithms for distributed communication. I guess what
I am saying is that I am intimately familiar with how self-
registration works, among other things.
While I do not mean to trivialize the art and science of MSI-based
installation, you must empathize with my position - some of us make
this sh*t (excuse my Low German).
This is why I said hand-holding. I am not lazy in the least. But
three days is far too long to spend on getting something install, one
EXE for example, and it is not becaus of lack of understand of "what's
going under the hood." I am simply looking for a keyhole.
So these installer classes seem to be the next step (thank you).
Assuming that what I wrote above is true, what is wrong with a simple
outline to get me started. Or even one link. It is patently clear to
people who have done service installation a gazillion times what needs
to be done. My guess is that it is not as complicated, as say,
explaining the Fraunhofer far-field approximation from
electrodynamics, but I could probably do that in a few sentences for a
reasonably intelligent individual who had a basis in physics to start
with.
I don't mean to be ugly, really I don't. I hope you understand what I
mean.
-Le Chaud Lapin-