The main window asks me not to interact, but it's not progressing at all - I've left it for over half an hour. My setup is made using Inno Setup 5.5.9. From what I understand the whole process should be automatic, but as you can see it's not working, and I'm not sure what to do now.
In case you want to do this in future (or for anyone else with the same issue who comes looking for this question) I did have a similar issue myself. I have no experience with Inno Setup but I used an MSI file created through a Visual Studio Installer project. It would get stuck on the first screen of the installer.
There should be a stage before the you start running the tests (the same stage when it asks for the file) when it asks for any parameters. I took this as an opportunity to include the same parameters I would use when running MSIExec.exe from the command line if I wanted an install to do a silent install (/qn). Presumably a passive install would have worked as well.
Looking at http://www.jrsoftware.org/ishelp/index.php?topic=setupcmdline, it appears Inno Setup should accept parameters such as /verysilent and /sp. I would expect these to have the same effect.
Related
I'd like to install Direct X with a web-installer (to make my setup smaller) on a users machine using Inno Setup during the setup of my windows application. If possible, I'd like to do that conditionally, if Direct X is not installed. If also possible, I'd like to do that silently.
I couldn't find out a working way to do this so far - Microsoft seems to make this a bit hard. Can anyone point me into the right direction or describe how this is possible?
EDIT: A semi-working solution can be found here: http://www.vincenzo.net/isxkb/index.php?title=DirectX_-_How_to_detect_DirectX_version
FYI: After all, I just used the directxwebsetup.exe with the silent flag ("/Q"). When DirectX is installed, just a small GUI flashup is seen, and otherwise a DirectX install GUI opens and installs DX.
There is a good sample for detecting the .NET version on the ISXKB wiki. This can be expanded to use Nick Sherlock's InnoTools downloader to download it and you can then run it with the appropriate command line options to do it silently.
We have an MSI installer (created using Wix) which is setup to be able to perform upgrades. Our clients are using it to upgrade our application on multiple machines at once using an SMS package running msiexec in silent mode.
The problem with this is that some of their users will still be running our application at the time the installer is run. We don't want to kick these users off, and running the install while they are using the app invariably breaks things.
Our ideal solution would be for the install to be scheduled to happen the next time the machine boots up.
This is a fairly hefty list of requirements, but does anyone know how I could achieve this or where I might look next?
You could add a value to the registry under HKLM\software\microsoft\windows\currentversion\RunOnce and it will run the next time a user logs on.
Windows Installer automatically detects files in use. Also, during a silent installation it handles them automatically:
files which are not in use are overwritten
files in use are scheduled for update after a reboot
As you can see, this is somewhat problematic because some files are updated and some file are not.
A good solution is to set REBOOTPROMPT property to "S". This way the target machine is automatically rebooted after install.
Unfortunately MSI packages cannot detect running processes, stop the install and schedule it at the next reboot. This could be done only with a custom EXE bootstrapper.
I'm writing an NSIS installer and the setup program elevates "as administrator" as needed on Windows 7 / vista.
I need to run the installed program at the end of the install and don't want to launch it with the same privileges as the installer.
The regular NSIS exec commands run the child process with the same permissions as the installer.
There is a UAC plugin for NSIS, but the documentation on it isn't great and it seems v. new; I'd prefer not to use that plugin.
Ideally, I'm looking for a small .exe I can include that'll launch the target program without UAC elevation. Does this exist?
Any other suggestions?
Thanks!
You only have two options:
Uncheck and remove the run checkbox (When running on NT6+)
Use the UAC plugin (It is not that new, but it is a pain to use, so I would suggest you just go for the first option)
There is no external program you can use since it is impossible to get back to the original user from a elevated process (You can try, and get pretty close, but it will not get the correct user in every case)
I found the following, which could be wrappered into a a simple command line utility:
http://brandonlive.com/2008/04/27/getting-the-shell-to-run-an-application-for-you-part-2-how/
It only took about an hour to get that code working for my project, and it works flawlessly so far. ;)
it starts up windows installer with random applications on my machine . . after i click cancel a few times, it loads vb6 fine.
any ideas why this is happening?
To stop this behavior:
Start VB6
Open the Add-Ins dialog
Uncheck the "Visual Component Manager" Add-In
Source:
After VS2010, SP1, VB6 launches VS2010 installer
This is what a Windows Installer repair looks like. It means that something is broken in one of the installed products on your system. Ideally it's a one-off repair so you might be better off letting it runs its course and do the repair, except of course if it asks for a install CD that you don't have.
The Windows event log (Application) will have MsiInstaller entries saying what product and component has the problem.
It's possible a previous installation has not completed correctly.
Use the utility at the following link to remove any rogue installations files:
http://support.microsoft.com/kb/290301 (broken link Aug.2017, leaving URL for "historical purposes").
As PhilDW has pointed out this is a Windows Installer Self-Repair issue, and can often be resolved by allowing the self-repair to complete once. At other times the problem persists and it should be fixed by other means. Even when the self-repair completes and the problem goes away, it can still resurface once you launch the conflicting application. Windows Installer is not easy to deal with.
In your particular case you might be able to get away with a "workaround" rather than a fix. By locating the main VB6 EXE file on disk (in its main installation directory) and manually creating a shortcut to it on your desktop, you might be able to successfully launch VB6 via this new shortcut without the self-repair kicking in. It might be worth a try.
This shortcut trick will not remove the underlying problem, but might help to "bypass it". Just for the record: the reason this might work is that the new, manually created shortcut is not "advertised" and will not trigger a key-path check of the installed product when launched. This is Windows Installer's way to verify that a product is correctly installed. Note that even if the workaround works, self-repair might still result during application use because of faulty COM data being detected (which is very likely the cause of the whole problem you are seeing, but give the manually created shortcut a try).
There is a rather comprehensive "article" on self-repair here: How can I determine what causes repeated Windows Installer self-repair? which might help to track down the cause of the self-repair kicking off in the first place, but fixing it can be a rather complicated process (so try the workaround first). It is a long article because there are so many different ways self-repair can occur. The common denominator is that different installers on your system are fighting over a shared setting that they keep updating with their own values on each application launch in an endless loop. The last application to launch will overwrite the registry or file system with its own setting.
This worked for me, for VS2010 RC:
"Please wait while windows configures Microsoft Visual studio 2010 Ultimate."
THe work around that fixes the issue for me was to run the following via the admin cmd prompt.
Md "%ProgramFiles(x86)%\Microsoft Visual Studio 10.0\common7\IDE\FromGAC"
from http://social.msdn.microsoft.com/Forums/en-SG/vsprereleaseannouncements/thread/572a0f8a-16b0-4e1d-b581-16be36a9b564
This was also happned to me.
Whenever i tried to open vb6, it started windows installer to configure "Autocad".
Autocad had not broken. and it was working fine.
I tried removing and reinstalling Windows Installer, But it did not solved the issue.
Then i installed Microsoft's "Windows Installer Clean Up Utility 2" from given link.
Using this utility i removed the autocad from "Windows Installers" Database.
After that VB6 never started installer again.
Keep in mind 'removing any entry from installer's database may be risky, but i had no choice. So do it on your own risk.
Download "Windows Installer Clean Up Utility 2" (this is a deprecated, unsupported and unsafe tool to use - Aug.2017. I will leave the link in for "historical purposes", don't use it).
I have a setup project created by Visual Studio 2005, and consists of both a C# .NET 2.0 project and C++ MFC project, and the C++ run time. It works properly when run from the main console, but when run over a Terminal Server session on a Windows XP target, the install fails in the following way -
When the Setup.exe is invoked, it immediately crashes before the first welcome screen is displayed. When invoked over a physical console, the setup runs normally.
I figured I could go back to a lab machine to debug, but it runs fine on a lab machine over Terminal Server.
I see other descriptions of setup problems over Terminal Server sessions, but I don't see a definite solution. Both machines have a nearly identical configuration except that the one that is failing also has the GoToMyPC Host installed.
Has anyone else seen these problems, and how can I troubleshoot this?
Thanks,
I had LOTS of issues with developing installers (and software in general) for terminal server. I hate that damn thing.
Anyway, VS Setup Projects are just .msi files, and run using the Windows installer framework.
This will drop a log file when it errors out, they're called MSIc183.LOG (swap the c183 for some random numbers and letters), and they go in your logged-in-user account's temp directory.
The easiest way to find that is to type %TEMP% into the windows explorer address bar - once you're there have a look for these log files, they might give you a clue.
Note - Under terminal server, sometimes the logs don't go directly into %TEMP%, but under numbered subdirectories. If you can't find any MSIXYZ.LOG files in there, look for directories called 1, 2, and so on, and look in those.
If you find a log file, but can't get any clues from it, post it here. I've looked at more than I care to thing about, so I may be able to help
Before installing, drop to a command prompt and type
CHANGE USER /INSTALL
Then install your software. Once the install has completed, drop back to the command prompt and type:
CHANGE USER /EXECUTE
Alternatively, don't start the installation by a double click but instead go to Add/Remove Programs and select "install software" from there.
Good luck!