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."
Related
I have a UWP application. I can run it inside of Visual Studio by using the Run button. I also know how to create an App Package and distributed it via App Center.
What I can't figure out how to do is build an EXE file that I can run on my own computer without launching Visual Studio (or copy to another computer). I found the EXE in the project folder under bin/x64/Debug (or bin/x64/Release), but it won't run. In fact it does nothing when I double-click on it.
What am I doing wrong?
The easiest way I have found to get apps installed on computers for non-technical users is to give them the output of that Create App Packages submenu, which includes a ps1 script and certificate file. If you give it to them as a zip make sure they unzip the whole folder first, and run the ps1 script from the unzipped folder. If Developer Mode is not enabled on their computer, the settings dialog to enable it will open automatically, and they just have to flip the switch. Otherwise, they are just pressing Y or A in the PowerShell window to continue through the installation process.
It's not too bad, the whole thing takes about 30 seconds if you breeze through it, but I believe you need admin rights on the computer you're installing on, there's a UAC prompt at some point.
I found the EXE in the project folder under bin/x64/Debug (or bin/x64/Release)
The exe file is the uwp executive core, but it could not run directly, because it has some dependencies need to be packed together, so we need use Visual Studio to create package for your app. And this document contains detailed steps you could refer.
After getting the installation package, we need the side-load, and please note:
If you are not publishing your app and simply want to sideload an app package, you first need to trust the package. To trust the package, the certificate must be installed on the user's device.
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.
I'm using InstallShield 2012 Spring Express. I finally figured out that, during the installation for my app, I could run a custom action with an elevated process EXE (application manifest set to "requireAdministrator") if I set its "In-Script Execution" property to "Deferred Execution In System Context."
That's nice.
But now I must be able to do exactly the same thing during the uninstall. So far, even on the paid version of InstallShield 2012 Spring Express, I can't get it to work.
First of all, for the "Custom Actions During Uninstallation" section, there are only two entries, "Before System Changes" and "After System Changes."
I didn't try adding my custom action to "After System Changes," because the EXE that I need to run is part of my package (and thus would have been removed by then.) And so I added it to "Before System Changes." Now for some reason, when I add it to "Before System Changes," there is no "In-Script Execution" option. And because I don't have this option, when my uninstall attempts to run the elevated process EXE, it fails with an error 1721...which is exactly the same error I used to get during the installation, until I changed the "In-Script Execution" option to "Deferred Execution In System Context."
So, how can I get my elevated process EXE to run correctly during the uninstall? Is InstallShield incapable of properly handling this?
Thanks,
JP
You can author a merge module using Windows Installer XML to correctly schedule and sequence your custom action. InstallShield express can then consume that module. See:
Augmenting InstallShield using Windows Installer XML - Certificates
If you aren't comfortable mixing tools ( this is just like writing a DLL in VB.NET and referencing it in an EXE written in C#) then you'd have to upgrade to InstallShield Professional.
I have created a winforms app and a setup and deployment project for that app (VS 2010).
All I need is this:
When a user runs the msi, right after he selects the installation folder I want to check if the main executable of the application already exists in that folder. In that case I want to break the installation and prompt the user to either uninstall the existing application or choose a different folder.
I would like, if possible, to not use any custom installer action. At first, a launch condition (with a file search) seemed to be the right way, but it seems launch conditions (since they are 'launch') run at the beginning of the msi execution and not after folder picking.
Visual Studio Setup and Deployment Projects don't support this type of authoring. It's one of the many reasons that Microsoft removed that project type from Visual Studio 2012.
The only way to do it using this tool would be to build an MSI and then use ORCA to create a transform authoring the validation custom action and scheduling it into the UI as a gating control event. You could then write a postbuild script to apply the transform to the MSI every time it gets built.
Very advanced stuff and frankly not worth the effort. It would be far more beneficial to switch to a tool that supports doing this such as Windows Installer XML (FOSS) or InstallShield 2012 Professional. ($$)
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.