Setup Project

  • Thread starter Thread starter Alex Clark
  • Start date Start date
A

Alex Clark

Hi,

I'm having some strange problems with a setup project I created in VS2008.

I have been working on v1.3 of my app. I released "beta 1" to a guy to test
it - sent it to him as my Setup.MSI file a couple of weeks ago. Everything
is fine.

I then released "beta 2", compiled it into an MSI file. Increased the
version number in the MSI file, created new package code, all the usual.
Sent it to my tester. It installed absolutely fine for him without any
errors, but when he came to run it, half the binary files hadn't been
updated. The main application exe was still beta 1, as was one of the DLL
files - the other DLLs (and one exe) had all been updated to beta 2 without
any fuss though.

I confirmed this behaviour on a different system. I had installed v1.3
alpha (i.e. before Beta 1) onto a test system. Tried this new installer for
beta 2, and it DID NOT update the main .exe file - it left it as v1.3 alpha.

I have some custom actions in my installer which I thought might possibly
have interfered (it ngen's the files after installing) so I set some
breakpoints and tried to run it from within VS2008 by right clicking on my
setup project and selecting "Install".

Never hit the breakpoints. Not one of them.

Confirmed that I *have* got my custom installer DLL referenced in the Custom
Actions section of my setup project for both install and uninstall.

So can anyone shed any light on this? Why on earth would the installer
decide not to update my main .exe but be happy to update most of my
supporting DLL files? Why can't I debug the custom actions in VS2008?!

Just to make things even more weird, if I did a "repair" on the Beta 2 MSI
file after I'd installed it, that *did* update all files to their beta 2
versions! This is bizarre and inconsistent. Please help me, MS!

Alex
 
Visual Studio 2008 upgrades (RemovePreviousVersions) depend on file
versions, unlike previously. This means you must increase the file versions
of your binaries to get them replaced. This may explain most of what you're
seeing. At the end of the install one product remains on the system, and
forcing a repair will force it to verify that every file installed matches
the version on disk.
 
This does seem to at least partially explain the problem, however it
definitely overwrote *some* of my v1.3.0.0 DLLs, despite them having
identical file versions. I haven't found any difference in the versioning
attribute on those projects so I can't see why it would treat them
differently to other binaries in my solution.

One helluva gotcha though, thanks for enlightening me Phil. :-)
 
Hi Alex,

Thank you for posting. I am Hongye Sun (MSFT). It's my pressure to work
with you on this issue.

From your post, my understanding of this issue is:
When installing a higher version of your product, the installer only
replaces partial files including DLLs and EXEs in the product folder. But
when repairing, it updates all the files. If I'm off base, please feel free
to let me know.

In order to narrow down the problem, could you please try the following
actions? That will help us to locate the real cause.
1. In the properties of the deployment project, change the
RemovePreviousVersions option to true. That will make your installation to
remove the previous version.
2. Try to remove all the custom actions you mentioned in your post. And run
installation again. Check that if all the files are updated. Using this
way, we can specify whether the problem comes from custom actions.
3. If possible, would you please send us the installation log file.
Following is the way how to get the log file:
" Open the command line console, type "msiexec /I [MSI file path] /l*v [Log
file name]", for example: "msiexec /I setup.msi /l*v setup.log". For more
information about MSIEXEC tool, please check
http://technet.microsoft.com/en-us/library/cc759262.aspx#BKMK_Install

For your first question, how the installer decide which file to update.
Please refer to http://msdn.microsoft.com/en-us/library/aa368599.aspx.
As it said:
Once determined that a file should be copied, the process is complicated if
another file with the same name exists in the target folder. In such
situations, making the determination requires a set of rules involving the
following properties:
" Version
" Date
" Language

When you want to check if your MSI file matches the rule, I suggest you to
use ORCA tool(http://msdn.microsoft.com/en-us/library/aa370557.aspx) to
view your MSI file. Its installation is part of the Windows SDK, please
download it at
http://www.microsoft.com/downloads/details.aspx?FamilyID=4377F86D-C913-4B5C-
B87E-EF72E5B4E065&displaylang=en. After you setup the SDK, ORCA will not be
installed automatically, please go to "<SystemDriver>:\Program
Files\Microsoft SDKs\Windows\v6.0\Bin" and find "Orca.Msi" to install it.
After you install the ORCA, please select the File table in the left list
and you will see all your files containing inside the MSI package.

For the debugging of the custom actions in VS2008. My recommendation is
using "System.Diagnostics.Debugger.Break();". Here are some instructions:
1. In your custom action functions, write
"System.Diagnostics.Debugger.Break();" before the place you want to debug.
2. Set the project to debug mode.
3. Install the setup project.
4. When the installation reports error, select to debug.
5. Choose the debugger you want to use.

Please let me know the information above so that I can provide further
assistance on this problem. I am looking forward to your reply.

Regards,
Hongye Sun ([email protected], remove 'online.')
Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#notifications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://support.microsoft.com/select/default.aspx?target=assistance&ln=en-us.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
 
One of the other things here is that file sharing (which happens when the
upgrade is installed over the older product) depends on internal installer
Guids on each file. You can't see these in the IDE, and Visual Studio
generates them using an algorithm that *may* (guessing) depend on the file's
install path. If something like that changed then some odd things might
happen. When you do the repair there may be event log entries that describe
what seems to be missing, Guids will be the ProductCode an and installer
Component.

These are the installer file replacement rules, and an equal version should
not replace the existing one. Odd!

http://msdn.microsoft.com/en-us/library/aa367835.aspx

There's a tool called Orca if you feel like seeing the internals of the MSI
files, the Component table will show if the Guids in the old version are the
same as in the new version for files that should be replaced.
 
One of the other things here is that file sharing (which happens when the
upgrade is installed over the older product) depends on internal installer
Guids on each file. You can't see these in the IDE, and Visual Studio
generates them using an algorithm that *may* (guessing) depend on the file's
install path. If something like that changed then some odd things might
happen. When you do the repair there may be event log entries that describe
what seems to be missing, Guids will be the ProductCode an and installer
Component.

These are the installer file replacement rules, and an equal version should
not replace the existing one.  Odd!

http://msdn.microsoft.com/en-us/library/aa367835.aspx

There's a tool called Orca if you feel like seeing the internals of the MSI
files, the Component table will show if the Guids in the old version are the
same as in the new version for files that should be replaced.

--
Phil Wilson
Definitive Guide to Windows Installerhttp://www.apress.com/book/view/1590592972








- Show quoted text -
Click to expand...

I am running into the identical problem with my setup project however,
it does not install the new application.exe file during the "Repair".
I have checked installed software version numbers and confirmed that
the version number of the application.exe file is being updated to the
new version but the file and the Date Modified time stamp is not being
changed either.
If I select "Remove" and then run the setup a third time the correct
application.exe file is finally installed.

I would also appreciate any help with this problem.
 
Hi Hongye,
From your post, my understanding of this issue is:
When installing a higher version of your product, the installer only
replaces partial files including DLLs and EXEs in the product folder. But
when repairing, it updates all the files. If I'm off base, please feel
free
to let me know.
Click to expand...

That is an accurate description.

1. In the properties of the deployment project, change the
RemovePreviousVersions option to true. That will make your installation to
remove the previous version.
Click to expand...

It already was, sorry I should've specified that.
2. Try to remove all the custom actions you mentioned in your post. And
run
installation again. Check that if all the files are updated. Using this
way, we can specify whether the problem comes from custom actions.
Click to expand...

Tried it and it had no effect.
3. If possible, would you please send us the installation log file.
Following is the way how to get the log file:
" Open the command line console, type "msiexec /I [MSI file path] /l*v
[Log
file name]", for example: "msiexec /I setup.msi /l*v setup.log". For more
information about MSIEXEC tool, please check
http://technet.microsoft.com/en-us/library/cc759262.aspx#BKMK_Install
Click to expand...

I'll try and reinstall and grab it.

I should point out that updating the file version on one of the problem
binaries caused it to install without problem. This effectively solves the
problem for me, as it's only really going to be a beta testing issue. When
I ship, clients will all have v1.2.1.0 binaries and will be installing
v1.3.0.0 binaries over them, so they should overwrite without issue.

For the debugging of the custom actions in VS2008. My recommendation is
using "System.Diagnostics.Debugger.Break();". Here are some instructions:
1. In your custom action functions, write
"System.Diagnostics.Debugger.Break();" before the place you want to debug.
2. Set the project to debug mode.
3. Install the setup project.
4. When the installation reports error, select to debug.
5. Choose the debugger you want to use.
Click to expand...

Tried this, but it tells me there are no symbols available, even though I've
got the setup project & custom actions library open in VS2008.


Thanks,
Alex
 
Hi Alex,

Appreciate your update and response.

The problem is caused by file version. By default, windows installer will
reinstall if the file is missing or is an older version. Otherwise it will
keep the original file.

From your reply, I have seen that this issue only happens in beta testing.
Since file version checking is by windows installer design. Would you like
to use a workaround to solve this problem? The quickest solution you can do
is create a bat file and type "msiexec /I <Setup MSI file path>
REINSTALLMODE=amus". Then run the bat file instead of directly run the msi
file. By changing REINSTALLMODE option, the installer will override the
existing files without checking its versions. For the detailed information,
please visit http://msdn.microsoft.com/en-us/library/aa371182(VS.85).aspx.

For your debugging problem, I cannot reproduce it. What I did is:
1. In setup project, custom actions tab, right click Install folder, and
click "Add Custom Action".
2. Double click Application Folder, and click "Add Assembly" on the right
side.
3. On the select component dialog, click Browse tab and choose the exe file
from file system with pdb file in the same folder. And click Ok.
4. In the exe file project, find the entry point (generally it is "Main"
function) of the application, add "System.Diagnostics.Debugger.Break();"
at the first line of the function.
5. Build the exe project, because setup project will not automatically
build custom action referenced project.
6. Rebuild the Setup project.
7. Run the setup application.
Please try it again, and make sure that the dll you want to debug has
related pdb file. If you want to debug external dll or exe, you must have
the symbol files on your machine.

Please let me know if the quick solution works for you, or you need any
other help.

Regards,
Hongye Sun ([email protected], remove 'online.')
Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

This posting is provided "AS IS" with no warranties, and confers no rights.
 
Hi Hongye,

It's no longer an issue for me, thankyou for your help. I think it was
because my fileversion attribute in my assemblies was listed as [1.3.0.*]
and the * section was not incrementing (but seemed to be randomly changing
instead) with each build, so some assemblies were newer versions and some
were older, hence the installer acted correctly.

It's not a problem for me as it's only going to affect my 3 beta testers,
and now that they're aware of the issue they'll just perform a repair after
the install to solve the problem (or uninstall first).

Thanks for your help,
Alex



"Hongye Sun [MSFT]" said:
Hi Alex,

Appreciate your update and response.

The problem is caused by file version. By default, windows installer will
reinstall if the file is missing or is an older version. Otherwise it will
keep the original file.

From your reply, I have seen that this issue only happens in beta testing.
Since file version checking is by windows installer design. Would you like
to use a workaround to solve this problem? The quickest solution you can
do
is create a bat file and type "msiexec /I <Setup MSI file path>
REINSTALLMODE=amus". Then run the bat file instead of directly run the msi
file. By changing REINSTALLMODE option, the installer will override the
existing files without checking its versions. For the detailed
information,
please visit http://msdn.microsoft.com/en-us/library/aa371182(VS.85).aspx.

For your debugging problem, I cannot reproduce it. What I did is:
1. In setup project, custom actions tab, right click Install folder, and
click "Add Custom Action".
2. Double click Application Folder, and click "Add Assembly" on the right
side.
3. On the select component dialog, click Browse tab and choose the exe
file
from file system with pdb file in the same folder. And click Ok.
4. In the exe file project, find the entry point (generally it is "Main"
function) of the application, add "System.Diagnostics.Debugger.Break();"
at the first line of the function.
5. Build the exe project, because setup project will not automatically
build custom action referenced project.
6. Rebuild the Setup project.
7. Run the setup application.
Please try it again, and make sure that the dll you want to debug has
related pdb file. If you want to debug external dll or exe, you must have
the symbol files on your machine.

Please let me know if the quick solution works for you, or you need any
other help.

Regards,
Hongye Sun ([email protected], remove 'online.')
Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

This posting is provided "AS IS" with no warranties, and confers no
rights.
Click to expand...
 
Back
Top