I'm trying to find a way to install a program to the AppData folder for each user on a computer. We have a computer that a group remotes into and each uses the program on that computer. Currently the application is installed normally in the program files. The reason we need individual installations is that we've updated the application to use AppLife Updater, and if someone runs the program while someone else is also running it, and it needs an update, the update will fail. So we'd like to have each user have their own installation that won't interfere with other users installations when updating.
I've found that you can install to LocalAppDataFolder instead of ProgramFilesFolder, but when you do that, you get several ICE errors (Specifically, ICE38 and ICE64). I found a web article that showed a version of a Wix installer that installs to the LocalAppDataFolder, but it also has ICE38 and ICE64 errors.
AppData Wix Installer code/article
My question is, has anyone made a Wix installer before that installs to the AppData folder that does not have these issues? Is there documentation on how to do this, other than the cited article? I have read the Rob Mensching blog article
How to create an uninstall shortcut (and pass all the ICE validation).
ICE64 documentation
ICE38 documentation
Related
Asking similar question because no one answered previous question asked
I have a solution with a class library project, a WPF project (start up project) and a Windows Service project. I would like to create one installer so that when the user installs the application then both WPF (UI) and Windows service gets installed.
Most of the resources I found online only talk about one or another but not both. For example this:.
I checked some question on stackoverflow but either they are not answered by any one or vague answers like this question or this one.
Any suggestion how to achieve this?
I'm not an expert on various installer solutions, but yes, this can be done. I know because my project does it.
We've historically used InstallShield, but we are actively moving to InstallAware for reasons unrelated to this discussion. Frankly, I suspect any installer solution (e.g., InstallShield, InstallAware, Wix, etc.) could be used to do this providing that it has the means to execute a batch script as part of the install process (more on this in a moment). In fact, while we are building our new installer using InstallAware, we are temporarily delivering our WPF-based application and Windows Service using a WinZip self-extracting executable. The WinZip self-extractor puts the WPF application in the C:\Program Files\<application>\<version> folder, puts the Windows Service in the C:\Program Files\<application>\Common folder, and then installs and starts the Windows Service.
The trick to all of this, of course, is getting the Windows Service installed. Initially, we used the InstallUtil.exe utility to do this, but we had to err on the side of caution and deliver it with our installer because we couldn't verify whether or not we could depend on the utility being available on the target system. At some point along the way, I read this answer by #Marc Gravell. This provided the springboard to my answer here, which provides detailed instructions for having your Windows Service install itself from the command line without the need for InstallUtil.exe.
So as a set of instructions...
Update your Windows Service based on the details here.
Create a .bat file with the following commands:
cd <PathToWindowsServiceInstallationFolder>
<YourWindowsService>.exe -install
Build the installer for your WPF Service and Windows Service. Note that this should focus on deploying the files to their correct locations. You'll need to include the .bat file as part of the installer. If your installer solution allows you to copy files to a temporary folder that gets deleted at the end of the installation process, copy the .bat file to that location since you won't need it after the installer is finished.
Finally, execute the .bat file from your installer during installation. This will install the Windows Service.
It's really not that complicated all things considered.
The one thing to be aware of is that your users should plan on running the installer as an administrator. Since installing the Windows Service updates the registry, users without administrative privileges might run into problems when trying to install your product.
HTH
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."
Now I have a completed program, that needs to be deployed with some files. I would like to ask, if it is possible to deploy the program without the use of ClickOnce or other external tools, with the minimum amount of required files?
The program will run on a server, and will be updated locally, but since the program is installed per user, does that mean if I log in to the server with my user, a person that uses the direct path to the program will not find it? It also makes maintaining the program slightly more annoying, because when changes come, the current maintainer will have to always navigate to the xyz folder to edit one config file. How do I publish the program without ClickOnce or other tools?
Your options include:
Click once (which you don't want)
Visual Studio installer Projects
WiX Toolset
Other installers ...
Write an installer on your own (wouldn't recommend)
Just put the exe (and other needed files) in some directory and launch the program
Put the exe on a shared location and launch from there
You can redistribute as a set of files. However I would not recommend this approach. You force the person who deploys your program :
Choose location for the files
Remember this location when time to uninstall comes.
Handle updates and version management
Restore program functionality if any of the required files will get damaged.
You can use VS Setup project template, here's tutorial
Alternatively you can use free Wix installer, it has a bit of a learning curve but provides much more power to the developer.
You can do perMachine install both with VS setup project and with wix.
i created an application using c# language. this application is doing a task like report generation.i am using that application exe file directly to run the application.i never installed that application in my system. without installation of that application, i can use it in my system.then why people are installing a software/application in systems.please clarify me. so that i can differentiate the MSI installation and direct use of exe file.
Install in cs jargon means guided setup, so what you do is already, basically, installing. Installing may involve much more complicated steps than simple copy/paste of bin directory or unzipping in some folder. installation process may contain the below processes:
Controlling user license
Registry key control
Database creation
Com components registration
....
and much more.
But the core concept remains the same: guided setup of all necessary components of your program to run it properly. So, if the only thing your program needs is a binaries folder, copy/paste is your install.
What you are doing is called an "xcopy" deployment. It was all the rage when .NET came out but it has serious limitations.
Windows Installer (MSI) is a windows platform service / SDK that aimed to create a declarative framework for consistent installer behavior. Simply put instead of learning how to write script to automate install/uninstall (and making a lot of mistakes along the way) you leverage MSI to tell it I have a product named X with feature Y that has these files Z in these directories along with a shortcut and some registry entries and let MSI do the rest for you.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
What are the specific differences between .msi and setup.exe file?
I am working on an installer for a new version of my project (C#).
Previously, I've used Inno Setup to create .exe files for installing my projects on other computers in the workplace. While reading through some tutorials, though, I came across Windows Installer XML, which uses XML files to build a .msi installer.
My project will be available on a network share that all the employees have access to so they can install the software (I'm currently working on an update checker as well)
What are the major differences between .exe and .msi installers? Why would I want to chose one over the other? Would either make more sense given my specific environment?
I found some of the information at this question, but there was not a lot of information.
I wouldn't use WiX for a new project. I'd use an 'Installer Project' in Visual Studio to build an MSI. An installer project is much, much easier to put together.
Many exe installers are actually stubs or containers that hold an MSI, btw.
I guess you've checked out http://en.wikipedia.org/wiki/Windows_Installer?
MSI's give administrators the ability to restrict installs, rebase installs, change or add custom actions, automate installs/reinstalls/uninstalls, standard logging and switches. It just really integrates into a corporate IT environment ( http://technet.microsoft.com/en-us/library/bb742606.aspx ).
A custom installer may have many of those features, but that would depend on the installer package.
Most EXE installers available today are simply stubs to verify that the target machine has just enough support to launch an MSI stored within the EXE. They do basic windows version checking and Windows Installer version checking, then essentially invoke msiexec and let Windows Installer handle the rest.
For a very basic installation, the Installer Project in Visual Studio can get you by, but for just about any kind of real customization or tweaking you'll need a real MSI editor. We use WiX and love it - but it's a bear to learn. If you've got the cash you can invest in InstallShield - but that has it's own set of quirks.
MSI is configurable while EXE is not. I know this doesn't answer your question directly, but I thought I should point towards the ClickOnce technology.
MSDN: See example here.
Simply stated, a ClickOnce application
is any Windows Presentation
Foundation, Windows Forms, or console
application published using ClickOnce
technology. You can publish a
ClickOnce application in three
different ways: from a Web page, from
a network file share, or from media
such as a CD-ROM. A ClickOnce
application can be installed on an end
user's computer and run locally even
when the computer is offline, or it
can be run in an online-only mode
without permanently installing
anything on the end user's computer.
For more information, see Choosing a
ClickOnce Deployment Strategy.
IndigoRose's MSI factory is extremely powerful and much, much cheaper than InstallShield.
It uses WiX internally and allows you to modify the XML files in any way you like. The bootstrapper (.exe, if you add one) has a powerful scripting engine based on Lua to do... well anything.