We have an Outlook addin that we created in Visual Studio 2010 in C#. When publishing, we're given an exe that does not allow for any quiet installation processes - none of the typical command switches work.
How do I generate a silent MSI instead of the default setup exe?
Found the solution I was looking for in an MSDN help article.
Deploying an Office Solution by Using Windows Installer
This is all I wanted to do - create an MSI instead of using the provided exe (which does NOT include an integrated MSI or other packages). This allows for flexible, scalable deployments without user interaction, regardless of user that is logged in to the machine.
The short answer is that it just works if you use only the MSI file. The setup.exe installs the prerequisites and then launches the MSI file. There is no good answer I can give about the prerequisites because they may all be different, but in general you just use whatever the details of the redist tell you in docs or a web search, installing prereqs by administrators etc.
It's an MSI, you publish it to the machine (I think that's the group policy description) and in fact the install is required to be silent and will give you an error if you attempt to show UI, the message being "This advertised application will not be installed because it might be unsafe. Contact your administrator to change the installation user interface option of the package to basic."
In other words when the administrator has defined the install parameters etc the user cannot change them.
Related
I've developed an Outlook addin that perfectly works with my outlook. I used our organizational code signing cert and used ClickOnce. Now I want to deploy it on a small group of machines (piloting). I followed this to create an MSI. The problem here is it copies all the files to C:\ with I double click on the setup.msi. But when I run it as an admin, it copies the files in the right location. Below is what I get from the msi log file.
MSI (s) (84:FC) [13:43:15:553]: Ignoring disallowed property TARGETDIR
MSI (s) (84:FC) [13:43:15:964]: PROPERTY CHANGE: Adding TARGETDIR property. Its value is 'C:\'.
What am I doing wrong?
Looks like you need to change the target folder of your installer. Most probably you chose a folder which requires admin privileges for writing.
You may find the Deploy an Office solution by using Windows Installer article helpful.
With Visual Studio Setup Projects the main reason for this is that the installing user does not have admin privileges, as you seem to have discovered. These VS setup projects switch to a per-user non-elevated install when the user is not privileged. Among other things, this means that the install can't create files and folders in restricted locations (the Program Files folders and others) so the install gives you a separate isolated install in C:. The ALLUSERS value in a VS setup project is 2, and as the documentation here says:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa367559(v=vs.85).aspx
you can get a per-user non-elevated install if the user is not privileged. Windows won't let limited users write to restricted locations just because it's an install.
Is there any way to compile the Nullsoft Installer Script (NSI) setup as a MSI package instead of an EXE?
Unfortunately, No.
NSIS lets you create scriptable, procedural installation packages. It's simple, easy to use and has a number of features not present in Windows Installer.
Windows Installer (MSI) creates database driven, transactional installation packages. When written properly a Windows Installer package is very robust, a file gets corrupted/deleted and it will be automatically reinstalled. Windows Installer is aware of UAC and only elevates when required, basically if you're creating software for the corporate market, you will need to provide an MSI.
Check out The Definitive Guide to Windows Installer for a good introduction to understanding MSI.
NSIS installers can be wrapped in MSI files using the MSI Wrapper. It is a small tool that I made for wrapping NSIS and Inno Setup installers. It uses WiX to compile the MSI but there is a GUI to help you instead of an XML file.
It was made because I needed a tool for creating MSI files based on traditional EXE installers. I needed support for uninstall and upgrades and only wanted the wrapped installers to show up once in the Add/Remove programs in the control panel.
I also wanted to be able to pass command line parameters to the wrapped installer when the MSI is installed.
If you want to use it or help me improve it, you can find it at http://www.exemsi.com.
I share the opinion that wrapping an executable installer in an MSI package is not the ideal solution. However, when you already have the exe it can make a lot of sense :-)
No (And there are no plans to support .MSI output), try WIX
I have a Visual Studio Setup Project created to install a VSTO application. The Setup Project outputs an EXE and 2 MSI files. One MSI for the VSTO and another MSI for Office Runtime dependency.
I know the setup.exe is used to check for pre-requisites like the office runtime, .NET and others.
However, the group policy User Configuration > Policies > Software Settings > Software Installation only accepts MSI files. How can I package all the three files into one single MSI to perform a silent installation?
It isn't possible to merge prereqs into a single MSI. If you want to support GPO, the only thing you can do is not build the EXE with the prereqs and instead put gating checks in your MSI to verify that they are there. The customer would then have to set up other GPO distirbutions for the prereqs. (Assuming the prereqs are available as MSI, .NET is not. )
In the real world, almost no one uses GPO software distribution. It's too restrictive. They use tools such as SCCM instead. But that's a question for ServerFault not StackOverflow.
There is similar questions on SO such as this and this however both suggest ClickOnce which I don't (can't) use.
I have started a new Setup project (InstallAllUsers=false) and have specified theApplication Folder to be [LocalAppDataFolder][ProductName]
which at install time points to
C:\Users\nonadmin\AppData\Local\Setup1\
When running the installer on Windows 7 as a non-admin I get this:
From my perspective it appears all the MSI does is copy the one text file to C:\Users\nonadmin\AppData\Local\Setup1\, something that could be done manually without this popup showing
The error message says something about 'unknown publisher' - does this occur for any msi/exe that simply runs? (even if it does nothing)
How can I avoid this dialog (a la ClickOnce) for non-admin users?
To avoid a consent prompt, you need to mark the package as "UAC compliant." (See "Guidelines for Packages" in the MSI SDK.) It looks like Visual Studio deployment projects don't support that bit so you'd have to modify the package in a post-build script (or use a different tool, like Wix that supports it directly).
Any package or executable that isn't Authenticode signed shows up as "Unknown publisher."
when I build solutions in Visual Studio, that generates installer files as .exe and .msi, .exe files are useful for what?
The .EXE file that is created by the installer project is a bootstrapper for the .MSI setup file. It is used to launch the .MSI setup file.
Generally, both will launch the setup program and allow the user to install the application. However, sometimes the setup.exe file will run a custom validation routine to determine if the user's computer meets the minimum requirements for installing the software.
For example, if the user does not have Windows Installer, they will not be able to launch the .MSI file, but the .EXE application will still run and inform them that they need to install Windows Installer first. For .NET applications specifically, the .EXE file verifies the presence of the appropriate version of the .NET Framework, and if it is not present, it prompts the user to download and install it.
You can customize the prerequisites that are required for your application in your installer project using Visual Studio. See these MSDN articles for details on how to do that:
http://msdn.microsoft.com/en-us/library/ms165429(v=VS.100).aspx
http://msdn.microsoft.com/en-us/library/7eh4aaa5(v=VS.100).aspx
Others have commented on the how (.exe bootstraps the .msi) but part of the reason why is that users know that .exe files are the things you run. I don't think your average user knows that .msi files are something that you can click on to install an application.
The .exe file is made for installing the prerequisites of your application.
Let's say your application uses the .Net 3.5 framework, you can tell the installer project to include the installation of the needed libraries if they're not already installed.
You may also deactivate it, so only the .msi is being created.
This page shows how to activate and configure the prerequisites setup, just uncheck the checkbox in order to deactivate it.
You also find more details on the process of Bootstrapping on MSDN:
the capability to automatically detect
the existence of components during
installation and install a
predetermined set of prerequisites
.exe files are useful for executing your programs that you've just built in Visual Studio, assuming you're not doing web applications.
Pretty much every Windows program out there is executed using files with an .exe suffix.
Installer exe files are normally just the msi wrapped in a bootstrapper. The bootstrapper can do anything, but normally its purpose is to ensure the user is running a sufficient version of Windows Installer, then extract the msi and invoke msiexec.exe to start installing the msi. Generating installers as exe's is deprecated these days, but some still do it.