I'm building a setup executable using Visual Studio 2015 Setup Project template.
I added an external executable in the file system of my package that the user needs to install to be able to run my program. Then, I added this package as a custom action on Commit.
I want my install package to recognize if this external executable is already installed on the user computer by looking at the registry of looking at a certain folder structure on the computer (the method to check is not defined yet).
How can I set up this kind of check for the custom actions ? I've seen that there is a Condition property when clicking on the .EXE in the Custom Actions window, but all I can find about this property is that, which does not really answers my problem.
VS setups offer a registry search, and that search will set a property name that you define (in uppercase). If the registry entry exists, meaning that you don't need to run the program, then you give the custom action a condition of NOT FOUNDREGISTRY assuming FOUNDREGISTRY is the name of the property.
Having said that, if that program is a redistributable that installs something then:
They are typically smart enough to figure out if they need to do anything or not, and that includes seeing if what's already installed is an older version, so they should run anyway because it's a newer version. So it may be best to just run it anyway.
If the executable wraps a MSI-based setup then it will fail because you can't install an MSI-based setup with a custom action in a VS MSI setup.
Related
I have a written a setup script for my own Windows EXE using InstallShield Premium 2012. My EXE, however, ultimately relies on the presence components provided by a Microsoft EXE called AccessDatabaseEngine.exe.
In order to run this AccessDatabaseEngine.exe executable with my installation, I added it as an embedded binary resource then used the Custom Action Wizard to launch AccessDatabaseEngine.exe as "Deferred Execution in System Context" as an "After PublishFeatures" Install Exec Sequence. This worked as expected: The AccessDatabaseEngine.exe launches after my Setup completes most of its work.
However, once I see the UI for the AccessDatabaseEngine.exe and acknowledge its UI prompts, I see "Error 1500", which states that another installation is in progress.
I understand that two MSI packages cannot be running at the same time unless you tweak the registry to allow it, which I do not want to do on my customers' workstations, which are Windows 7 32-bit machines.
I would like to successfully implement one of these options:
OPTION ONE: Have the user launch my Setup.exe program, which will at some point launch the Microsoft AccessDatabaseEngine.exe without generating any error message. I just don't know how to do that without causing the Error 1500 to appear...
OPTION TWO: If it's possible to somehow wrap my Setup.exe along with Microsoft's AccessDatabaseEngine.exe into a single EXE, then I could provide my end users with that single EXE and it would first execute the embedded Setup.exe and, once that's done, it would execute AccessDatabaseEngine.exe.
I realize that I could implement OPTION TWO as a .bat (batch) file, but I want to deliver only a single EXE to my end users and have that single EXE install everything needed for my software to operate properly.
Any ideas?
What you describe here is exactly what InstallShield's prerequisites are designed for. Launch the prerequisite editor from the Tools menu and add files, command lines, and conditions that carry, install, and detect the installed footprint of the AccessDatabaseEngine.exe; then use the redistributables view to include that new prerequisite in your project.
Once you've done this correctly, InstallShield's setup launcher will check to see if the prerequisite footprint is present, and, if not, it will run the prerequisite as described. Since this is done before it launches the main .msi file, it avoids having two .msi files installing at the same time.
See Defining InstallShield Prerequisites, Creating an InstallShield Prerequisite, and Setting Installation Conditions for an InstallShield Prerequisite in the help for more details. For defining where these end up in your built installer, see Specifying the Run-Time Location for InstallShield Prerequisites at the Release Level or Specifying a Run-Time Location for a Specific InstallShield Prerequisite. Note that when dependencies of a prerequisite are added, they often use the release-level setting, so unless you really want a mix of locations, you're best off specifying this in the release.
Apparently there are TWO settings that determine if a prerequisite ends up in its own, separate folder (a release folder below the folder that contains setup.exe), or if it gets embedded into a single setup.exe file.
The first setting is available in the Installation Designer under Application Data | Deliverables. Find your PRQ prerequisite listed there with a check mark, right click it, and view Properties. You will see a Build Location dropdown--one of the options is Extract From Setup.exe. That's the way mine was set.
But then there is SECOND setting, and that's in the Installation Designer's Media section, under Releases. In my project, I had a Releases root, then a PROJECT_ASSISTANT branch, then a SINGLE_EXE_IMAGE branch. I left-clicked SINGLE_EXE_IMAGE and viewed its property sheet. In that list is an entry near the bottom of the list that says Setup Prerequisite Location. Double-click the right column (where its value is listed) and you will see a selection there that also says Extract From Setup.exe.
This second setting OVERRIDES the one specified in the deliverables section, and that's why it wasn't working as specified in the prerequisite setting. That's because I was using the "Copy From Source Media" setting.
So if you have multiple prerequisites and you want all of them to be included in the setup.exe then it's okay to use the Extract From Setup.exe settings. But if you prefer to configure where the prerequisite ends up, then choose the Follow Individual Selections options in the Releases' Setup Prerequisites Location section and then ensure that you've selected the correct option for each of your prerequisites.
Even if others had suggested doing this in previous answers, those explanations weren't clear to me and I wasted a lot of time before ultimately discovering what's actually going on.
We have a couple of dlls we like to install using an msi.
In our test environment, we are using regasm -codebase to register the dlls.
As I understand from googling, this is accompliched in an msi project by setting the register property to vsdraCOM.
The problem is that when we run the installer and checks the registry, the codebase path is set to the path the file were in when building the msi.
I'm going to expand on Hans' answer and that link info, and it may be more than a comment can hold.
That reg file will contain the path to the file and the link article recommends using [TARGETDIR], which is basically wrong if the file is not being installed to the application folder. The path to your file should be written as [#file-key] in the reg file that you import. In a VS setup project the file-key will be (just an example) something like _B049230C37DE4B6787C578DCEE30252A. Open your MSI file with Orca, go to the File Table and use the file key in the File column that corresponds to your file name.
That comes from here:
http://msdn.microsoft.com/en-us/library/aa368609%28v=vs.85%29.aspx
the 7th bullet point. It resolves to the file path wherever it is installed to.
The other thing that can be done is to let Visual Studio do its incorrect thing, then go to the Registry table with Orca, find the path and put that [#file key] in it such as [#_B049230C37DE4B6787C578DCEE30252A] and people sometimes do those kinds of updates with a post build script to update the MSI.
None of these are great, but they should work and get you out of using the GAC. VS setup projects really should be using that [#file key] syntax, and it's just a silly bug I assume.
Speaking as someone who's made a full time living writing installs for 18 years, my first suggestion would be to switch to Windows Installer XML. If you insist on using .VDPROJ, I would suggest reading: Redemption of Visual Studio Deployment Projects.
The concept is you use Windows Installer XML to create a merge module and then consume that merge module with .VDPROJ. In Wix, you use Heat to harvest the DLL. It will extract the COM / Regasm metadata and author it as Registry table entries. This provides a nice clean encapsulation using authoring best practices and avoids the need to do any post build hacking of the built MSI database.
I would like to know how can I detect if help file is contained in setup file for windows platform application (msi or exe). Is there any method to get this information without installing the software first ?
Of course setup file can be created by many setup makers like innosetup, installshield and so on. So I wonder if there is some universal method to solve this.
For an MSI based install it would be very easy. For example you can use the Microsoft.Deployment.WindowsInstaller interop via C# to open the MSI as an InstallPackageClass then access it's Files collection to see if it contains the file you care about.
For a Non-MSI based install, there is no universal way and in most cases, no way period. See, that's kind of the point of MSI: to have a standards based package rich in meta data to be able to see what it's doing. When you do some proprietary script driven installer you lose that openness.
If it's a MSI file, open it up using Orca, and you can view file names.
For both of them, you should be able to do an administrative install, which would extract the files, but not register anything. Depending on where the exe came from, doing an administrative install changes, since each vendor(installshield, innosetup, etc) has their own way to run an administrative install.
for a MSI it's simply
msiexec /a <msi_filename>
For an exe you'll have to look up how to pass the /a argument.
I would like to build a setup, or something like that (1 file), to deliver a single file to a target system. Plugin for an application, installable to users AppData folder.
After some research I'm still not sure in which direction to look. I can create the setup project with Visual Studio 2010, but all of the options so far seem to be way too heavy or have some flaws.
SetupProject stubbornly wants to create an application folder which I don't need, and complains about installation to user folder. Cab doesn't seem to offer automatic install, oneclick is not available for the project, etc.
Is there an easier setup technology I could use?
Requirements:
Install -> Copy 1 file to a folder
under %userprofile%\3rdpartyapp\ if
it exists (xcopy).
Uninstall -> Delete the file and also
one folder with custom settings
(rmdir \s).
Distribution -> Free for commercial
use.
Maybe I should just pack the file in self extracting c++ exe?
It may be overkill for one file, but I like InnoSetup for creating setup packages. Check it out, and see if it suits you. It is very easy to use and deploy.
Take a look at WiX toolset. It allows creating MSI-based installers, and the installer could be quite simple:
Search for %userprofile%\3rdpartyapp;
Copy the file into it, if it exists;
Fail install or maybe create it, if it does not exist.
Uninstall would be very simple: it would need to remove the installed file. To remove a subfolder of 3rdpartyapp, you can use RemoveFolderEx element.
MSI registers the installed app with Add/Remove Programs Control panel. Uninstall is handled by Windows Installer service, therefore you don't need to copy any additional files or programs to support uninstall.
I think any setup technology is too heavy for one file. I'd go with creating a simple application that would extract the file from its resources stream and copy it into %userprofile%\3rdpartyapp.
Uninstall is trickier: there should be something that can handle the uninstall process. It could be a batch or script (js, vbs) file stored somewhere in user's profile, another simple application or the same one. (Installation process can also be handled with a script.)
Using Installshield 2010 and Basic MSI project.
I have an exe that was previously installed by my installer. That exe needs to be running during an installer upgrade. Is there a way to guarantee that the installer won't try shutdown the process? Basically, I would like the behavior to be : If file doesn't exist, lay it down, otherwise ignore it.
I have made the exe a key file in a component and set it 'Never Overwrite' to true. Should this give me my desired behavior ?
Never Overwrite will be used by future installers to determine if the file will be overwritten or not by other MSI packages. Basically, this attribute should have been set for the installed EXE.
A good approach is to use a file search to determine if the EXE exists. The search property can then be used to condition the new component.
Windows Installer doesn't automatically close applications, but it does show a FilesInUse dialog which offers this option to the user.