Framework bootstrapper causes slow install of .NET app

  • Thread starter Thread starter Tim Werth
  • Start date Start date
T

Tim Werth

I am installing two .NET applications, one right after another. Each is in
its own .MSI and has the bootstrapper setup.exe to make sure the .NET
Framework is installed. When kicking off the first setup.exe, the
bootstrapper displays a dialog with "Installing component setup". This
takes about 1 minute for the dialog to disappear and the msi's setup to
actually kick in.

Then, when I run the second setup via it's identical bootstrapper, it takes
~4:30 minutes for the "Installing component setup" dialog to disappear.
That is long enough for several testers to think the setup has locked up.

So there are a couple of things I don't understand. The first is since my
test machine already has the same version of the .NET framework installed,
why does the first bootstrapper take a minute to run? The second thing is
why does the second bootstrapper take soooooo much longer?

If I look in the registry after the first bootstrapper is finished, there is
a value named "NetFxUpdate_v1.1.4322" under
HKLM\SOFTWARE\Microsoft\Windows\CurrentVerwsion\RunOnce with the following
data:

"C:\WINNT\Microsoft.NET\Framework\v1.1.4322\netfxupdate.exe" 0 v1.1.4322 GAC
+ NI NID

I am testing this on a W2K server Virtual PC, but others in my group have
seen it on XP and regular W2K.

Does anyone know how to alleviate this problem?

Tim
 
Try installing one, then rebooting and installing the other. If this takes
far less time on number two, there is likely to be a buffer somewhere that
the second job is forcing to be flushed before it can proceed. Not sure how
to clear this buffer between installs, but it has to be done to speed up the
process (once again, IF that is what is happening).

---

Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************
 
Try installing one, then rebooting and installing the other. If this takes
far less time on number two, there is likely to be a buffer somewhere that
the second job is forcing to be flushed before it can proceed. Not sure how
to clear this buffer between installs, but it has to be done to speed up the
process (once again, IF that is what is happening).

---
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************
 
Sure, that worked better and the time of the setup setup was in line with
that of the first, but since the bootstrapper doesn't tell the user he needs
to reboot in between setups, he's not going to know to do that. He's just
going to see the same dialog for almost five minutes not doing anything.

Tim
 
Hi Tim,

If you can access to the setup project source code, I think you can pop up
a dialog to tell the user that he needs to reboot the machine.
Or we need to isolate the problem by testing the bootstrapper with a simple
setup project to see if we can reproduce the problem.

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
 
I do not want to tell the user to reboot in between setups because the real
situation is the user kicks off setup A (InstallShield), and it kicks off
setup B, C, and D (.NET app MSI's with bootstrappers). I need all three to
be installed before a reboot takes place.

I think the real solution is to combine B, C, and D into one setup.
Fortunately, I have that luxury. However, others may not.

The .NET framework must be doing something to want to reboot. I know the
bootstrapper suppresses the reboot until the app has been loaded. As a
matter of fact, my experience has been that it does not prompt the user
after the app has been loaded when a reboot is required by the framework.

Tim
 
Hi Tim,

How is your bootstrap written? Is it generated by a third party tool or do
you use the bootstrap sample on the MSDN?

If you are using Microsoft's bootstrap sample, it should not launch the
installation of .Net Framework at all if you already have .Net Framework
installed.

Please also check whether you are using the correct version of the
bootstrap:

Microsoft .NET Framework Setup.exe Bootstrapper Sample
http://www.microsoft.com/downloads/details.aspx?familyid=bf253cfd-1efc-4fc5-
ba7e-6a6f21403495&displaylang=en

Microsoft .NET Framework version 1.1 Setup.exe Bootstrapper Sample
http://www.microsoft.com/downloads/details.aspx?FamilyID=66350891-d15b-446b-
bd69-f7f849224a00&displaylang=en

Regards,

Felix Wang
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
 
I am installing two .NET applications, one right after another. Each is in
its own .MSI and has the bootstrapper setup.exe to make sure the .NET
Framework is installed. When kicking off the first setup.exe, the
bootstrapper displays a dialog with "Installing component setup". This
takes about 1 minute for the dialog to disappear and the msi's setup to
actually kick in.

Then, when I run the second setup via it's identical bootstrapper, it takes
~4:30 minutes for the "Installing component setup" dialog to disappear.
That is long enough for several testers to think the setup has locked up.

So there are a couple of things I don't understand. The first is since my
test machine already has the same version of the .NET framework installed,
why does the first bootstrapper take a minute to run? The second thing is
why does the second bootstrapper take soooooo much longer?
Click to expand...
<snip>

Is NGEN running? The .NET framework NGENs its assemblies to provide
faster startup; however, this is done at the cost of longer install
times (several minutes, usually). Perhaps this process is still going
on, and when the next setup is started, it waits for the process to
complete?

(I don't have any actual experience with bootstrapping/installing, so
I might be slightly off here)

Austin
 
I am using the MSDN example. We downloaded it some time ago (late last
year?), so maybe it has changed. I will take a look.

Tim
 
Hi Tim,

I look forward to your result.
Cheers!

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Looks like we were using the bootstrapper code written to deliver the 1.0
Framework, but we are delivering 1.1. There are significant differences in
the code that we have and the code from the 1.1 example. It appears to work
like it should now.

Thanks,
Tim
 
Hi Tim,

I am glad that it works now.
Cheers!

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Back
Top