I have a C# project that I've written using the .NET 4 framework, I've created an installation project using the setup wizard within the solution, the problem is that once the program is installed and I launch it, a dialog appears saying that the program is being configured and then starts the program, why is this? Is it necessary? How can i prevent this from appearing or happening altogether?
UPDATE
I installed my application and launched the application from the .exe created in Program Files and a config window didn't appear and the app launched normally! How do i create a link to this shortcut without it showing the windows shown above? As i need to place a shortcut to the users startup folder.
This happens because Windows Installer detects missing resources. For example, some of the installed files were moved/removed/renamed or were installed per-user for another user account.
Here is an article with more details: http://setupanddeployment.com/general-installation-problems/preparing-install-popping/
You can use Event Viewer to determine which resource is causing this, like explained in the article I mentioned.
The MSI file has auto-repair enabled. I don't think VS has an option to turn it off.
The shortcut links generated don't actually link to the files they should. They link to an executable in appdata. When that file's opened, it runs the installer repair check silently and opens the configuring dialog while any repairs take place. For some reason the installer thinks that files installed with your program are being deleted / corrupted. Perhaps temporary or configuration files?
This link given in this question should fix it if that's the case, but it'll still be activated if the user hits Repair in Add/Remove programs.
Related
I'm using the Visual Studio Installer Projects extension to build the MSI-installer for my application. However, my application is meant to be running at all times, and if it's open when the user is installing a new version of my software, the open files are not overwritten, and very little to nothing is actually updated (although there are no installer-errors).
I've found that using the installer project's "Custom Actions" to run a script that closes the application doesn't help, as none of the actions are called before the files are replaced.
Is there a good way to make sure the open/locked files gets terminated before the files are supposed to be overwritten?
We had this problem, and the solution we came up with was to create two apps; the user app and an updater app. The MSI installs both. Each app checks if the other needs updating and, if it does, closes the other app, downloads the other app's updater, runs it, then relaunches the other app. Additionally, each app monitors if the other app is running and, if it isn't, launches it.
It would be useful to know more about your application and how you are doing the upgrade because:
You will normally see a FilesInUse dialog saying that files are in use, prompting the user to shut them down, but not if the install is silent.
Visual Studio setups have no built-in support for shutting down and restarting services, so if your app is a service you'll need extra work.
Files that actually do need to be replaced will prompt the user for a reboot (if they are not previously shut down) in order to replace them at reboot time.
So if you're not seeing reboot requests or FilesInUse dialogs in a UI install then something else is going on. So you need to be sure that:
a. You are really doing an upgrade where the version of the setup project has been incremented, the UpgradeCode is the same (and the ProductCode changes when you increment the setup project's version). Your symptoms could be the result of the upgrade not working and you're seeing just a repair.
b. The definition of "new version" is that you have an upgrade as in a., AND, the file versions of the binaries have been incremented. The default overwrite rules for installs require incremented file versions, so if they haven't been incremented you'll see no updates, and Windows will not attempt to show FilesInUse dialogs or reboot because there are no files that need replacing.
This isn't a solution to the problem, but rather another solution; the one requiring the least work in the end.
I ended up not using 'Visual Studio Installer Projects' for my installer. Instead I looked to Advanced Installer, which just works with no issues. Things like this is taken into account, and custom actions allow for more options.
If your project is open source, you can write to them about a free open source "professional" license, equal to their "professional" plan, which is normally $399 (onetime purchase).
REBOOT: How are you installing this MSI? What command line? If you set REBOOT=ReallySuppress on the command line, you will not be prompted for a reboot even if one is required to complete the installation of the product.
msiexec.exe /i MySetup.msi /QN REBOOT=ReallySuppress
If you are using a distribution system I suppose suppressing reboot prompts could be standard behavior. Then your product files should be put in place after a reboot (PendingFileRenameOperations or perhaps some newer mechanism).
It is also possible that Visual Studio Installer Projects do something strange that I am not aware of.
Log: I would try to create a good log file for the install, to determine what is going on:
msiexec.exe /i C:\Path\Your.msi /L*v C:\Your.log
Log All MSIs: Personally I like to enable logging for all MSI installations - as described in the "Globally for all setups on a machine" section in the above link.
Interpreting an MSI log: interpreting a log file can be challenging sometimes. Here is an answer with some links to help with this.
Reboot Manager: Reboot management is a very complex topic, and Windows features functionality - in the form of the restart manager feature - to try to minimize the need for reboots, by instead shutting down and restarting applications as part of an installation in an "auto-magical" fashion (application listens for messages and shuts itself down gracefully when told to, and the system may restart the application after the install - if configured to do so).
Updating your application to comply with the restart manager is the only real fix for such problems that you see, in my opinon.
The section "Restart Manager" in this question tries to summarize how to implement such support (maybe just read the yellow section a bit down the page).
The Advanced Installer guys have a very nice, technical article about this:
How do I add support for Windows Restart Manager to my application? Also linked to in the link directly above - still worth a direct link here I think.
According to below link
https://social.msdn.microsoft.com/Forums/windows/en-US/0b40b367-3341-43d8-b82e-1ace546969f8/how-can-installation-stop-and-restart-existing-service-?forum=winformssetup
"There is no good support in VS installs to stop and start services. During install, the issue is that custom actions run after everything is installed so it's too late to stop a service that you are upgrading or replacing. Yes, they have names like "BeforeInstall" but they really are not before the install."
What I Have Done:
I created a Visual Studio Setup Project that creates the installer for my WPF application. This installer creates the MSI I use to install the application.
I created a Primary Output with my primary project and created a shortcuts to this.
The application installs successfully.
Problem:
When I click the shortcut that was created on the desktop I get the following screen before the application loads and starts:
Header: [Application Name]
Message: Please wait while Windows configures [Application Name]
Loading Bar Header:
Gathering required information...
(Followed by a progress bar and a cancel button)
This takes up unnecessary time.
The application starts after this finishes and continues as intended.
How can I prevent this from happening, what reasons could there be for this to happen?
PS: when I open the application from the exe in the program files this does not happen.
This nearly always happens because people are unaware of the fact that if they install a file (or registry entry) and then delete it later a repair will be triggered by using an advertised shortcut. There are other entry points into repair, but shortcuts are the obvious one. Attempts to defeat repair are often pointless because there are other things that can prompt a repair of a changed product. such as upgrades, patches, and the user right-clicking the MSI to repair, or doing repair from Programs and Features.
Another cause is that the setup installs an item (such as a file or registry entry) into a user profile location (such as User's data) in an Everyone install. The is installed for the installing user, but not for another user so repair will install it. However you'd see this just once per new user.
There have also been VS setup project bugs that can cause this issue.
The documented way to prevent repair for files you want to remove after install is to null the Component Id for the file, something VS setups don't support so you need to do it with something like Orca or post-build MSI script. See ComponentId here:
https://msdn.microsoft.com/en-us/library/aa368007(v=vs.85).aspx
Note that the Windows Installer team recommends the MSI source be available anyway for a number of reasons, rule 31:
http://blogs.msdn.com/b/windows_installer_team/archive/2006/05/24/605835.aspx
Visual Studio Setup Project authors advertised shortcuts which is one of the mechanisms that MSI uses to determine if a repair is needed. It is detecting it is needed and attempting to do so but failing resulting in an infinite repair loop. Please read:
Windows Installer launches unexpectedly, for no obvious reason
This will help you identify which component is causing a problem. Unfortunately, VS Setup Projects are quiet limited and it's going to be difficult to fix this problem. I really would recommend a better toolset such as WiX, Advanced Installer or InstallShield.
The problem occurs when a windows user profile is created after installing our tool with the MSI installer.
When starting the tool with the new user, Windows wants to start the .msi file again.
(When the installation was run from a network path, Windows is then unable to find the installer)
The installation only installes 5 files (exe, dlls, txt) and creates a link on all users desktop.
Questions:
What is the reason why windows wants to run the installer again?
Is this the default behavior?
How can I prevent windows from starting the installer again with new users?
If this occurs when you click the shortcut, perhaps the advertised shortcuts have been created by the installation program and it tries to install the feature on demand. The differences between the types of shortcurts are described here. If it is your installation program you can try using non-advertised shortcuts in project. If you are talking about third-party software you can try creating your own shortcut for the installed executable.
Note that this repair to add the missing something should occur just once per new user to restore the data. If it happens more than that it's something more serious.
Even if you modify the shortcut, there is still the issue that if this new user (or any user) does anything that triggers a repair the same thing will happen. Repair is available from right-clicking the MSI file, and maybe from Programs&Features too. You really should keep the MSI file available.
If it's an accident that you didn't intend then why not just fix it? Look at the event log MsiInstaller event log entry, that might help. Also, Visual Studio may have added something that it thinks you need, like an extra HKCU registry entry - I believe that's been reported as an issue. You may find something in Orca or even in the setup project's UI in the HKCU registry.
I've just tried ClickOnce for the first time to deploy my SQL Server Compact application. I think this kind of deployment is very unprofessional:
The output setup is a folder including 3 objects, one folder named Application Files, a setup.exe and a .application file which I've never seen in a professional product setup package.
Plus, clicking setup.exe seems to help user install the application so quickly but user has no chance to select what location s/he wants to install the application. It's installed by default at somewhere in the target computer. And even I tried looking for its location after the installation, I couldn't find it.
The last, after the installation, there is a folder named "Microsoft" in All programs menu, and the installed application shortcut is located in there. I wonder why it is always Microsoft? I even tried editing my Company info in Assembly info through Project Properties window. The application shortcut is something strange when I can't find its target executable file in its properties window.
With all the above ClickOnce can bring to me, I consider it as a funny job for testing the application only not for publishing a commercial application.
Could you please correct me if there is any wrong in #1, #2, #3 and please give me a better solution for deployment, I'm interested in SQL server (service-based and file-based) application only?
Your help would be highly appreciated. Thanks.
A ClickOnce install is a per user "sandboxed" install, not a normal install you think about when installing normal applications. The .application file is used by the server as a manifest and to determine if it needs to update the install when clicked.
The reason you can't find setup.exe is because it isn't there. Once the files are installed, it isn't kept. The user isn't supposed to know where the files are, the system manages the location and updating of the app.
So, with all that, it appears you need a more normal install, not a ClickOnce. ClickOnce isn't intended to install services or other per machine files.
I'm a web developer building my first production grade console application (C# .NET 4.0). I have a question about creating a settings file that the user can edit before running the console app (to customize output folder paths, etc).
I'm a little confused -- when I publish my console application and install it (by clicking on on the generated setup.exe file in my target publish folder), all I get is an entry to my start menu. Nothing gets installed to C:\Windows\Programs, and there doesn't seem to be anywhere else on my system that files get installed to. Essentially, I'm just trying to find the app.config xml file so that I can edit it after the program has been installed. (btw, when I click on the start menu entry, the program executes properly).
Is what I'm trying to do possible?
For a clickonce deployment, the files will be installed under the profile of the user who installed the application (by default).
For windows XP this should be:
C:\Documents and Settings\username\LocalSettings\Apps...
For Windows 7 (and Vista?) this should be:
C:\users\username\AppData\Local\Apps...
An installation program for your software is a separate piece of software.
You can definitely make one but when you compile your console app it doesn't create an installation executable. It just makes it's own executable. You can copy that executable alone and run it. If you need more resources to go along with it and therefore decide you want an installation program, you have lots of options.
The two that spring to mind in this case though, are setting your project to use "ClickOnce" from the project properties, or adding a "Setup and Deployment" project to your solution from the "Other project types" section of the add project dialog box.