I created an installer using InstallSheild Limited. During the install process, I have a Custom Action which runs a C++ exe after registering the product. In the C++ exe, I move files that are in the installers program directory to various places on the computer.
Now, I need to make the uninstaller be able to remove those files. Is there a way to do this in InstallSheild Limited Edition. If not, what can I do to achieve the same results?
Related
I created the MSI build package for our application. After this installation, we triggered another dependent driver software in the separate process in a committed event of Installer class like below,
Process.Start (" Path of driver software ")
We are facing an issue, installed directory ( It's empty ) folder is not removing while un-installing the same. Actually like installation, we triggered the un-installation of dependent driver software in the separate process by overriding the Uninstall method of installer class.
Anyone, please help me to overcome this issue? How could I remove the installed directory?
I can't change the installation procedure, since we are aware that we can't process another installation/un-installation when another one is going.
You are running a non-MSI driver install EXE from within your MSI? Correct? Or maybe it is an MSI wrapped in an EXE?
Do you have Installshield Premier? Could you use a suite project and install the EXE via the bootstrapper before (or after) the MSI install? I have honestly never used this feature, but running setups in sequence is what it is for. Embedded custom actions in MSI files kicking off EXE files are notoriously unreliable. This is - in my opinion - especially true if you are running with managed code as well (which I think you are).
In the long run managed code may yield safer custom action code (security-wise based on CAS), but for now it seems to cause unwanted runtime dependencies - especially for very large-scale distribution (global distribution) targeting diverse Windows versions (Vista, 7, 8, 10).
I am told it takes a while to get used to Installshield's suite feature, but maybe it is better for you? You can run EXE files, MSI files, patches and zips in sequence. Some fiddling to define uninstall and upgrade behavior I guess and lots of testing. I am pretty sure corporate application packagers would be happy to see a suite rather than an MSI with lots of strange stuff embedded in it.
UPDATE: Once you have compiled a suite setup.exe file it can be extracted as described here: Regarding silent installation using Setup.exe generated using Installshield 2013 (.issuite) project file
Alternatively you could try to extract the setup.exe files for the driver setup and install the drivers as regular MSI components and run DPinst.exe to install / uninstall the drivers (tool from DIFx). Also quite clunky - especially when you need to include uninstall.
Your driver setup likely uses DPInst.exe already. I would check if you can extract an MSI from the EXE and use it instead of the EXE to include in the suite project. Some hints for how to deal with setup.exe files (extraction, runtime paramenters etc...): Extract MSI from EXE.
WiX has the Driver element in one of its extensions to deal with driver installs. I have never had the chance to test it.
I have been able to successfully install a simple program using an Installer Project on Visual Studio Community 2017. However, I can't find out how to create a fully working deployable uninstaller for an end user.
The Installer Project was set up to only create an Application Folder (in C:\Program Files...) with the Program .exe, and nothing else. This it does successfully. I would like an installer because later I plan to make some registry keys upon installation.
To test uninstallation, I have run the original .exe file built by the Installer Project with the "Uninstall" option. This removes the Application Folder but does not remove the program from the Add/remove programs list in Windows - Leading me to believe there are other registry entries that have not been removed.
I have tried to uninstall purely from the Add/remove programs list, but then I get an error:
C:\WINDOWS\system32\msiexec.exe
"Windows cannot access the specified device, path, or file. You may not have the appropriate permissions to access the item."
In Visual Studio, I can click "Uninstall" from the Installer Project right-click menu which does successfully remove both the Application Folder and the Add/Remove Programs Item, but this is not a deployable solution.
Notes:
OS: Windows 10
Using Visual Studio 2017 Community
Looking at the application Folder, there is neither an install nor uninstall .exe file in it. The Installer Project .exe is only in the original build location, and I cannot find how to get a copy in the Application Folder (not sure if a copy there would work).
I have tried configuring the Installer Project as x86 and x64 with no change.
I have tried using both Debug and Release build configurations with no change.
From looking around, WiX seems to have more features and flexibility, but I haven't yet dug into that. Is there an easier solution?
Has this issue occurred to anyone else? My hopes were that Installer Projects were the simple way to learn and handle installation.
Looks like I jumped to conclusions in the comment above, however I think I found the issue: I cannot uninstall the program from the Windows Apps & Features window in System Settings, but uninstalling from Control Panel\Programs\Programs and Features works fine.
When typing in "Remove" using the windows start button, the default item that comes up is "Add or Remove Programs" in System settings (This looks like a Windows 10 thing). When you click that, it forwards you to the "Apps & features window. I am now learning that for some reason this has different functionality than the control panel window. Or maybe it has lower permissions, although I am the admin and only user of this computer...
Because it can be uninstalled from Control Panel, I think this would be the preferred solution. My assumptions about the other window in system settings was my real issue. I just wish the Apps & features window aligned its functionality/permissions with control panel.
I also learned that uninstall is successful when I run msiexec.ex /I{PACKAGEID} in cmd. Not sure how relevant this is, but documenting here.
Installs and uninstalls are transactional, they either work completely or roll back completely. If you do an uninstall but the entry remains in Add/Remove Programs then it's likely that the uninstall did not in fact work.
When you do the install, if it has a UAC elevation dialog then the install is running with elevation and installing files/registry entries to locations prohibited to limited users. Removing files from those locations also requires elevation. You haven't said exactly how your uninstall works, but most likely it requires elevation to succeed, and your program isn't running elevated. If your program uninstalls silently the uninstall will fail silently, so it's possible that your program isn't actually checking that the uninstall worked.
I'd also guess that your Visual Studio session may be running elevated so uninstall from there works fine.
Apart from privileges, an uninstall from a running installed program tends not to work very well because the uninstall process cannot remove your running program or its folder because it's in use. So while you could get it to work (with elevation) you might find that your program and its folder are left behind until the next reboot. If people really want to do this, one of the strategies is to copy an uninstall program to the temp folder and fire it off asynchronously, so everything can be removed.
Uninstalls from Add/Remove Programs&Features generally work fine. Without some context that error message doesn't mean much. It's not a message that comes out of Windows Installer, so it's perhaps coming out of a custom action. Otherwise it may be an issue specific to the test machine.
There is never an uninstall exe in a Windows Installer setup. When you remove a product the system just calls the Windows API to remove the product. Windows Installer is part of the Windows OS with API support for everything that needs doing. Only non-MSI setups require an install and uninstall exe to do anything.
None of these issues seem to be related to your choice of tool. They all create MSI files and if an MSI design is not optimal it doesn't matter what tool you use. There's nothing wrong with WiX, but to install literally a few files it's overkill compared to Visual Studio.
This ought to be simple, but seems to be anything but.
I wish to create an installer that can be used by those using group policies to install products. I do not know then if this must be an MSI, or an EXE. Can an EXE install be installed via a group policy? I chatted with another Wix novice who seemed to think it was a bad idea to have an install that was a plain MSI file.
My product uses the Visual C++ 2010 redistributables. I do not wish to use merge modules. Both this and this link give some of the disadvantages of using them. I object to 1) installing things that the user has not consented to, and 2) not having a control panel uninstall item with a version number that users can inspect and see if they have the latest version of. Thus, I am not interested in responses consisting of people lecturing me on why I ought to use merge modules. If what I am asking for is truly IMPOSSIBLE without merge modules, then please explain why.
I do not know if it is necessary to use a bootstrapper to kick off an EXE install. I gather that it is, but it seems bizarre for me, for an MSI with such involved tables and descriptions, not to be able to kick of a mere EXE, ON THE CONDITION that the redistributable is not installed already.
If it is necessary to use a bootstrapper, I would like to know if anyone can find a complete example, with both bootstrapper and Wix code, for an example of a product install; ideally, together with the command lines necessary to compile them, for such a common case as installing a VC++ 2010 (or possibly 2012) program, together with its redistributable - with the latter being installed as the EXE.
I have found this to be straight-forward and easy to do in Inno Setup Pascal - except for the Group Policy part. I have found anything but COMPLETE examples and/or straightforward explanations to accomplish this using a Microsoft installer. No matter what Microsoft says, I would consider such an installer to be best practices. My code is not managed, and I would like to support XP. Thus, a bootstrapper that requires some .net to already be installed would only add another unsolved layer of complexity to the problem. One that statically links to a .net library might not be too bad, if it did not create very much overhead. My MSI install seems to work pretty well. I did not realize that installing a vcredist_x86.exe would be a problem with such an elusive solution. I do not have Visual Studio. I am using the Qt framework, and have Visual Studio installed only to compile my application. If you have a bootstrapper solution, please specify which bootstrapper you are using. Ideally, the same idea could be extended to more than one prerequisite, and the same coding pattern could be used. If there were a way to use a merge module or additional MSI so that the redistributable would have its own control panel entry, that could be acceptable.
Brownie points for suggesting a mailing list, forum or well-populated chat channel to talk about Wix that does not require one to receive a lot of unnecessary mailing list traffic.
Group Policies by default don't allow EXEs to be installed. I did read about some admins that repackage EXEs into MSIs to deploy them via GPO but that is rather hacky. There is also the possibility to script the deployment - GPOs support script execution, machine or user level.
You can't embed an MSI within another MSI either because only one installation can execute at any time (Windows Installer design).
I don't know how you will be providing your product to your customers but vcredist_x86.exe (I am trying this with the v100 version) uncompresses into the root folder and generates an msi and a cab (vc_red.msi and vc_red.cab) among other files. If you provide these to your customers they can add them to the same GPO used to deploy your product.
We have a TeamCity build server with a couple of agents set up to build code on check in for several c++ projects. Now, we've run into some problems regarding handling dependencies on Windows SDK since
It's to large to check-in and still be able to work with the source
smoothly.
Several can't be installed at the same time without problems.
The easiest way to set up TeamCity agents is to just install the Windows SDK. However, installing two versions the Windows SDK is problematic since it seems to overwrite registry entries of previous installations. Another approach is to cherry-pick files from the installation and put it on an rsync-server or the like, but the Windows SDK installer seems to modify Visual Studio binaries, etc so that does not feel good either. I've also checked with microsoft and they strongly suggested against cherry-picking files from the SDK install.
How have you set up your c++ projects on TeamCity and what would you suggest in our situation?
If you make sure the versions of the SDK are installed in the same location on each machine that you use (both developer and build machine) then you can add a step to the start of your build scripts which sets the current SDK for use. You can do this either:
Using the registry settings (if you have only one build going at any time)
Using environment variables, which you reference in your project files for lib, bin etc.
I've seen this work pretty well before, although we we weren't using TeamCity.
I had to create an executable (using Borland C++ Builder 6) in place of a batch file for Windows 7, since permissions didn't allow ordinary users (non-admins) to run the necessary batch. We've got a number of different Windows 7 machines, some 64 bit and some 32, etc. The problem I'm running into is that the "Program Files" directory is hard coded in to the program, but it's not always the RIGHT program files directory, which leads to some errors on some machines.
I'm familiar the method for getting the program files dir from the registry, but I'm afraid this won't work on all machines because of permissions settings not allowing programs to access the registry. I've been searching high and low for a function like GetWindowsDirectory, but to no avail. Does ANYONE have any suggestions?
EDIT:
I've programmed this on a Windows XP Machine to simply be placed on Win7 (No way to change or avoid the XP/7 thing, crappy as that may be). It's a simple utility that needs no installation; it's just placed in a file. It just needs to go out and find the program files directory to perform some tasks.
This is first of all a deployment problem. You will have to copy/install your program to c:\program files (x86) on a 64-bit machine. You can simply use c:\program files in your code, Windows redirects it to the (x86) directory.
There is otherwise no easy cure for trying to bypass UAC. You'll have to embed a manifest in the executable to ask for admin privileges. The user gets the UAC prompt to let her know that you are going to be hacking the private parts. How to do this with such an old tool isn't obvious to me, you'll probably have to embed it in the .rc file. Or use a .manifest file.
How to get Program Files folder path (not Program Files (x86)) from 32bit WOW process?
Use SHGetFolderPath with CSIDL_PROGRAM_FILES.
There's a newer version called SHGetKnownFolderPath if you're always on Windows Vista or later, but you might need to update your Platform SDK. If you're still using Borland C++ 6, I suspect your Platform SDK might be older. In that case, you should be able to use SHGetFolderPath.
after installing the software, go to :
C:\Program Files\Borland\CBuilder6\Bin
Right click on bcb.exe file, choose
Properties -> Compatibility
Select the option - Run this program mode Windows XP(Service Pack 3) and Privilege Level
then, select the option Run as administrator, and then click Apply.
This works for my problem.
On windows 7 x64, just create a junction point in "c:\Program Files" pointing to the actual folder where the installation is in "c:\Program Files(x86)". This should be done by the same user who installs the software. That should not only take care of your problem but also third party packages that would not otherwise work on Win 7 x64.
If you don't know what a junction point is, just read the help for mklink.