PDA

View Full Version : installscript project weird behaviour during installation.



gurinder
11-17-2008, 04:45 AM
Hi

I have created an Installscript project using installshield 2008 premier edition. The project runs absolutely fine on some of the system but on some systems it takes mare than 10 minutes to complete the installation which should normally take 20-30 seconds. All the systems have same configuration and operating system ( Windows XP ). It has been observed that the system which takes longer to install this setup has an increased network activity during the installation. On removing the system from the network completes the installation process in 20-30 seconds like it normally should do.

Anyone who has faced something similar to the behaviour i am facing pls let me know.

Thanks
Gurinder

gurinder
03-17-2009, 02:29 AM
Does anyone has any idea why is this happening. Anyone from Installshield.

gurinder
03-30-2009, 04:44 AM
Hi

When installation is taking place or more specifically when .Net assemblies are being copied the firewall reports that installer is trying to access something from the internet.

Anybody any ideas or clues....

Thanks
Gurinder

GetExp
03-31-2009, 09:24 AM
I guess comparing the log files of the quick and the time consuming installation will help in identifying the problem. Are you compiling the .Net framework with your setup?

gurinder
03-31-2009, 11:37 PM
Hi

Thanks for the reply.
I am not compiling .net framework with the setup. Although setup checks for the .net framework installed on the system if its not there setup terminates. I am using Installscript project, the option to generate the default log file is not there. I would have to write a log writing function of my own.
Any other ideas

Thanks
Gurinder

joshstechnij
04-01-2009, 04:44 PM
We do not actively use any network connection unless there is something in the setup explicitly referencing a network location (for example, passing a network/Internet path to CopyFile/XCopyFile).

My first guess would be something on these machines is hooking into the setup process and attempting to talk to something outside of the machine as a result (virus scanners or other anti-malware type utilities, for example). We typically recommend shutting down or disabling any services or applications on a machine prior to running a setup since these services can interfere with how the setup operates.

Another thing to try would be to use a default setup.rul in your project and test with that on the machines experiencing this behavior. If the behavior is resolved with a default setup.rul, then there is something called in the script that is generating the network traffic.

gurinder
04-03-2009, 02:29 AM
Hi Josh

Thanks for the reply.

I tried what u suggested. I created another installer which only copied the .net assemblies with default setup.rul. And the result was same. I am attaching the message reported by my firewall. Its the dotnetinstaller.exe which is trying to access something from the internet.

Thanks
Gurinder

joshstechnij
04-03-2009, 11:22 AM
The dotnetinstaller.exe provides the following functionality for InstallScript projects:
- Registration of .NET assemblies for COM interop (through the use of Assembly.LoadFrom (http://msdn.microsoft.com/en-us/library/1009fa28.aspx) and RegistrationServices.RegisterAssembly (http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.registrationservices.registerassembly.aspx))
- Support for calling installer classes in .NET assemblies (through the use of AssemblyInstaller.Install (http://msdn.microsoft.com/en-us/library/system.configuration.install.assemblyinstaller.install.aspx) and AssemblyInstaller.Commit (http://msdn.microsoft.com/en-us/library/system.configuration.install.assemblyinstaller.commit.aspx))

There isn't any code in dotnetinstaller.exe that would attempt to talk to any network or Internet resources, and besides the above .NET framework services, dotnetinstaller.exe does not really call any other code (besides some basic string methods for command line parsing). The dotnetinstaller.exe is digitally signed, so verification of the signature could result in Windows contacting the root authority on the Internet for the certificate we use. In addition, since dotnetinstaller.exe can load and call third party .NET assemblies, network activity could be generated by these assemblies and would be reported as coming from dotnetinstaller.exe.

gurinder
04-09-2009, 01:05 AM
Hi Josh

None of the assembly is trying to access anything on the internet. Also during slow installation i have noticed installer takes a long time to copy files into the target directory. What could be the reason for this. The setup is run with administrator privileges.

Thanks
Gurinder

joshstechnij
04-14-2009, 11:27 AM
Unfortunately, I'm not sure what would be causing the behavior you are seeing without being able to reproduce it.

Note that turning on InstallScript trace logging will significantly reduce the performance of all InstallScript installations run on a machine. Please ensure tracing has not been enabled on the machines you are seeing these performance issues on.

rbrand
04-21-2009, 11:21 AM
My install was doing the same thing - the installscript install would install on a pc with no internet connection and appear to halt. The process dotnetinstaller.exe was running as well - every time. I found that my c# apps were being placed in the local assembly using .Net Assembly and that they were also being scanned at build for dependencies. Once I changed the .Net Assembly to Not a .Net Assembly, the dotnetinstaller.exe wouldn't appear and the install would allow me to go on. Now why is this? Why would the GAC or the Install (dotnetinstaller.exe) need internet connection? What could it possibly be doing that would need to contact the outside world???:confused:

joshstechnij
04-21-2009, 11:53 AM
As I mentioned in my previous post, dotnetinstaller.exe does not contain any code that would attempt to talk to a network or the Internet. If there is anything in the context of dotnetinstaller.exe communicating with the Internet it would be out of our control to prevent as this would be occurring as a result of .NET assemblies called in the dotnetinstaller.exe process context or from .NET code that we call to register assemblies or call installer classes.