Visual Studio 2013 Installer Projects Extension copying to root folder - visual-studio

I have installed Microsoft Visual Studio 2013 Installer Projects to create a simple installer. When I run the installer however it copies the files to c:\ instead of the proper folder in Program Files (even though it asks for the path).
This seems to be caused by the fact that the MSI (the only thing produced by the Installer project) is not run with elevated privileges. The other thing is that you cannot say run as administrator for MSI file (unless you do some reg-hacks).
I have searched for a solution and there seem to be loads of more or less complicated ways how to tackle this.
The question is - is there not a simple switch that would allow me just to copy the files to appropriate Program files folder? I do not want to create workarounds for something that seems to be the very basic functionality.

If adjusting the environment (UAC settings, Registry values) is totally not an option for you then maybe you could try one of the following:
The Visual Studio Setup Project produces both an MSI and a setup.exe file. The latter one you can run as administrator by right-clicking on it. No hacks.
Another way of starting a process with elevated privileges is opening a command prompt (cmd) as administrator and then launch your EXE or MSI from the command prompt window.
-
Note: Even though it may not be related to your question, I would also pay attention to the Target Platform. For instance, you cannot install a 64-bit project to the Program Files (x86) folder.

Related

Outlook Addin MSI installer copies file in C:\

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.

How can I make an MSI file that runs all EXEs in its own directory?

Currently, our customer uses a Windows .bat file in order to batch-install a series of installers (currently .exe files produced using Inno Setup, although there are plans in the future to replace them with .msi installers) found in a directory.
However, they have requested that this be replaced with an .msi file -- it sounds crazy to me (as it doesn't actually INSTALL anything, merely search for external files already on the target machine and then run them) -- but presumably it is in order to take advantage of Windows Installers' logging functionality, as well as to prevent unauthorized tampering with the installation process.
Most of the stuff I've found on Windows Installer custom actions seems to refer to running programs installed by the MSI, not programs that were already on the target machine before the installer was run. What do I need to do to run already-existing files (in the same directory as the MSI itself) as part of an MSI's processing?
I'll accept solutions using either Visual Studio or WiX.

Setup/MSI - Multiple user input directories

I'm in need of a setup creation tool (preferably outputing MSI file but not necessary) that is able to prompt the user for a "core" installation directory, and then prompt a second time for a "runfile" directory.
I've messed around a bit in Visual Studio 2010 and with Inno Setup but can't seem to find a solution.
Any suggestions?
A list with the best tools available currently: http://en.wikipedia.org/wiki/Windows_Installer#Tools

How to create my an installer for my DLL?

I am currently using Visual C++ to develop my DLL program. This DLL also uses outside executables inside my local hard drive.
When doing testing, I manually install the DLL using this command regsvr32 filename.dll at the Windows command prompt.
What I would like to do now is an installer, like the Installshield etc. So, after this I can easily install it on other Windows machines without the need to manually use the command prompt, copying those separates executables into the hard drive and so on.
Is there a way to do this the open source way? or Is it available inside Visual Studio? Need advice on best practice.
Another possibility since you're already using VS, you can create a "Setup and deployment project", found under "Other Project Types". This allows you amongst other things to select the output of another VS project (in the same solution), add registry entries, package files from the file system, and register (regsvr32) files. To register a DLL (once you have added it to the project), change the "Register" entry on the "Properties" Window to vsdrfCOMSelfReg. However if you're packaging other executables off the hard drive, I'm not sure how you would make sure that they run. You prob have to make sure that you package all their run-times and dependencies.
AFAIR this functionality is not available in the express editions of VS.
WiX is open source, and there's a free (no cost) version of InstallShield available for Visual Studio 2010, so both.

Why Visual Studio creates .exe installer files?

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.

Resources