I have a service [C# exe] and I can deploy it using Visual Studio Command Prompt window typing "InstallUtil MyService.exe". Now how to do the same thing from Install Shield 2009 Premier(and also start the service as we do manually)?
There are two main options. The easy one, but not so recommended, is to add MyService.exe as the key file of a component, and mark the component as an Installer Class. This will invoke InstallUtilLib.dll (which functions similarly to InstallUtil.exe) to install this component. However all versions of InstallUtilLib has no handling for rollback, and will yield an incomprehensible message box window if there's any error; these are the reasons to prefer other approaches.
The other option starts the same way, with MyService.exe as the key file of a component. Then open the advanced options of the component and use the Install NT Services and Control NT Services nodes to install and start the service respectively. The potential downsides are that you'll need to know the internal name of the service to do this, and I'm not certain whether it works for all C# services.
Related
I need to build a vdproj on a jenkins machine (Windows Server 2012 R2)- which requires devenv.exe and not msbuild. I cannot install Visual Studio.
Devenv.exe is required for a MSI package.
I've used process monitor and determined I require one more file for devenv.exe to work : api-ms-win-core-heap-l2-1-0.dll
This file does not exist on any developer machine that we have, and devenv.exe/devenv.com works on the dev machines.
Where can I find this file?
Are there other ways to build a vdproj without Visual Studio?
Virtual Machine: This sounds a little hairy I am afraid. Could you use a virtual machine - with Visual Studio on it - to build the Visual Studio Installer project in question?
WiX et al: Converting to WiX or another deployment tool besides Visual Studio Installer Projects would solve the problem? Is this a very complicated installer? Using the WiX decompiler dark.exe to decompile an MSI to WiX markup can help you convert the installer to WiX format. Quite a bit of WiX knowledge will be required to do this successfully. Maybe something a consultant could do quickly? Depends on the complexity.
Windows API-set: As far as I know api-ms-win-core-heap-l2-1-0.dll is a Windows API-set, and not a real file or real dependency as such. These are new constructs in Windows. Try opening such an API-set file with Dependency Walker to see what they redirect to. Pretty mysterious these API-sets:
An API Set is a strong name for a list of Win32 APIs. The convention
for assigning a strong name to an API Set is to use what appears to be
a dll name. But the purpose of an API Set is to provide architectural
separation between the API Set's name and its associated host DLL
implementation for improved portability of your app, so you should
think of an API Set's name as just a unique character string, and not
as a dll name. For delay load, you use the name of the API Set.
API Sets rely on operating system support in the library loader to
effectively introduce a namespace redirection component into the
library binding process. Subject to various inputs, including the API
Set name and the binding (import) context, the library loader performs
a runtime redirection of the reference to a target host binary that
houses the appropriate implementation of the API Set.
The decoupling between implementation and interface contracts provided
by API Sets offers many engineering advantages, but can also
potentially reduce the number of DLLs loaded in a process.
On disk I find most of these API-Sets in %SystemRoot%\WinSxS and %SystemRoot%\System32\downlevel.
Nice article on the technical aspects of this new API-Set feature.
Complex Executable: Though devenv.exe is just an EXE file like any other, I do think there will be dependencies for Visual Studio Installer Projects beyond just dll import tables that will be very hard to set up properly, and what about future releases when all can fail without warning? (if something changes - Visual Studio has been a pretty moving target of late).
WiX Quick Start: Here are some of the best links that I have found over time for WiX:
Some WiX Quick Start Tips - chaotic, but
upvoted. Must have been helpful.
Helge Klein's real-world WiX sample - do check this out.
Rainer Stropek's WiX Samples on Github - can be very helpful.
From MSI to WiX by Alex Schevchuk - aging content, but excellent.
I wrote a windows service that runs on Framework 4.0 and running in VS 2015.
I also created a setup project (free Installshield version).
My service did not show under services.msc after I installed it, so according to some other posts I had to mark the Primary Output in InstallShield as 'Installer Class', but when I do that I get Error 1001 when I run the setup.exe.
This post states that "Error code 1001 ALWAYS means a failure in the Installer class custom action." and that I should not use Custom Actions. I'm not using any custom actions at the moment.
Most of the solution on this site have instructions for Installshield 2010, and the steps does not work for 2015.
The error appears on both my dev machine as well as all client machines.
Any suggestions?
EDIT:
The event viewer displays "Failed to create restore point (Process = C:\Windows\system32\msiexec.exe /V; Description = Installed My App Name.; Error = 0x80070422).
I had this exact same issue. Suddenly after upgrading to VisualStudio 2013 and the newer InstallShield LE and building my installation packages they would fail with the cryptic 1001 error.
Definitive Answer
I found the definitive answer. You can no longer have the checkbox for "installer class" selected in InstallShieldLE. You must uncheck that item.
In order to open this dialog box, go to Specify Application Data > Files and right click on your Primary Output and select Properties.
Previously, You Had To Have It Selected: Now It Must Not Be Selected
Previously (Visual Studio 2012 and before you had to have that item selected or the service installation would fail. This is quite terrible.
Now, you have to go to following tree item in the InstallShield LE project and double-click the Services node:
After that the Services item appears on the left (have I mentioned what a terrible UX and UI this entire thing is?) and right click it so you can add the service.
Choose the menu item which appears to add the service and you'll get a form which allows you to set up the installer details.
Once you do that and rebuild your MSI will work and this will resolve the 1001 error.
This was all a terrible waste of time that the original InstallShield Devs could've resolved. Unfortunate.
If you have .NET 4.6 installed on your build machine, you'll need the 2015 version of the limited edition to avoid a versioning bug with InstallShield's support for Installer Classes. (There are many causes for a 1001 error, so this is not a guaranteed fix.) Note that InstallShield 2015 Limited Edition does not support the community edition of Visual Studio.
Hopefully this will help some of you encountering the Error 1001 when trying to install a .NET Windows Service using InstallShield 2015 LE installer project with the Primary Output set as an Installer.
It's a known bug when .NET 4.6 is installed on Windows 10.
https://flexeracommunity.force.com/customer/articles/en_US/ISSUE/HOTFIX-Install-Fails-With-Error-1001-When-a-NET-Installer-Class-Component-is-Present-in-InstallShield-2015-SP1
Since i cant comment yet i will just reply with an answer to your own accepted answer. I know it has been a while since you asked the question but here goes.
If you want auto start after install you can go to step 3. Configure the Target System. Choose the Services tab. Right click Services and add Service. You should be able to locate any service in your Primary Output. Once added you can select different settings related to auto start and so on. Hope it helps you.
On a side note, i am still looking for the answer to my 1001.
This error occurs when targeted .NET framework is not installed.
If you are targeting the same development machine then please check if that service (EXE) is already running on that machine or not (It should not running).
I found something to get rid of the problem, but it does create a new question, albeit a much simpler and less critical one.
What caused my problem is that I had to remove the following code from my ServiceInstaller's AfterInstall:
new ServiceController(ServiceInstaller.ServiceName).Start();
This was added to auto start my service once it has been installed. For now I will just manually start the service.
I am using VS 2012 with InstallShield LE 2015 targeting .NET 4.5 and I have to uncheck the "Installer class" for it to work.
After some digging I found out that the installer fails with that error when it tries to remove the service (associated with whatever you are installing) - AND (the service) is not there anymore.
My use case scenario - Start install from MVS2015 of a complex solution that comprises also a windows service.
When you change the version of the solution, the installer stops in its tracks finding that the your app was installed before and can not uninstall it as it is a different version. It pops up a dialog box stating this and exits .... BUT IT HAS UNINSTALLED the service.
Now trying to install or uninstall fails with the error 1001 because windows doesn't find the service to uninstall it.
If somebody has a better solution please post it, but my solution is to use sc command line utility. sc is a utility that can be used to manipulate services from the command line (type sc for help). So i use sc to add the service (by name), and then I can do uninstall, or install as usual. Is compulsory to have a valid bin path in command - but ANY valid path will be accepted.
sc <server> create [service name] [binPath= ] <option1> <option2>...
Example:
sc create MyService binPath= C:\Windows\explorer.exe
[SC] CreateService SUCCESS
I have a single executable which, via InnoSetup, installs into Program Files\FolderName by default. The exe has a 3rd party component which goes online to check for new versions and downloads them, then does a bit of fiddling to replace the exe - simple stuff. The problem is, it can't do this in Program Files because of the necessary security there. I was reading Windows 7 - Can't update my program's files in C:\Program Files in which David Hefferman gives a solution but then seems to say it's a bad idea - but I don't know whether the bad idea bit refers to his solution or to the OP's comments!
So what is the preferred method by which a program can update itself? One that will work on XPSP3 to Win8. I can't seem to find the right phrase to enter into Google that gives me relevant results. Ignore digital signatures and suchlike for now, for simplicity.
(Please note, it may look like I worded that as an opinion question but it's not - there must be some MS-endorsed way of doing it that I can't find. FWIW this is a Delphi program but any Win32 notes will do)
That 3rd party update utility needs to be run with administrative privileges, you can achieve that programmatically.
There is nothing wrong with installing your application in Program Files, that is the designated purpose of this folder. However, user data that is used by the application should be stored in a different location.
However you run that 3rd party Utility, you should first check the Windows OS version to see if fiddling with UAC is really necessary(Vista+...) and then run the utility in the elevated state.
He says its "extremely bad practice" to fiddle with your system so that normal users can write in "Program Files".
If your program is in "Program Files" it's installed with System Admin rights. So updates need also be installed with System Admin rights.
You can configure InnoSetup to request admin-rights so you can write to "Program Files" but if the 3rd party component does not do this its best to install everything in an other directory.
i.e. C:\Your_Program
That way your 3rd party component can write there.
There are several options here:
The easiest: make updater as a separate program with manifest, which requires admin privileges. Also you can ask for admin privileges when you start your updater. Or you can move your updater into out-of-process COM object instead of separate exe.
You can create hidden user with admin rigths during installation of your program. Then you will run your updater with credentials of this user.
You can install system service during installation of your program and this service will run from system account. So your updater will be implemented as a service.
I need to install a windows service using wix. Unfortunately ServiceInstall doesn't fit my needs. It doesn't allow to specify service file explicitly and needs to be placed into the same component where the service executable file is. But my components are dynamically generated by heat each time the project is build. So I can't put ServiceInstall there.
Does anyone know alternative ways to install the service?
The service is .net one so my first idea would be to run installutil from .net framework directly.
I've spoken at length of the many limitations of dynamic installation authoring. What I would do is statically author this component for the service (using ServiceInstall ) and exclude it from the dynamic generation process.
Then again, I don't use dynamic authoring period. I don't consider it a best practice.
You can transform the heat output with XSLT transform (see -t switch) the way you want. And it is still better than falling back to installutil... Take a look at the DTF documentation (DTF.chm installed with WiX, Development Guide > Managed CAs > InstallUtil) for the reasons why using installutil is not considered a good idea.
I have made a simple installer application in Delphi, nothing fancy. Basically I include files into the Exe, and then extract them to a user specified path.
I stumbled across a problem however, and I have noticed this works with ANY Windows Executable, it does not matter if it is an installer or not.
If an Exe is named, or contains the following words in the filename, "Setup", "Build", "Install" and maybe others, then.. whenever the Application is run and closed, Windows pops up a Product Compatibility Assistant dialog, saying the Application may not have installed correctly.
This is a problem, as even though the Files from my installer have actually extracted, and in my eyes the installer has done its job, Windows is complaining about it.
The only idea I have regarding this, is that Windows must check the filename of the Applications when executed, and in this case has identified it as an Installer. Windows must of then set a flag or something on the System, my Installer must then update this flag to say that the installation was a success?
Windows does not complain about this when debugging from the IDE, so it cannot be code related, it must be the OS - this only happens when launching the Application from Windows, not Delphi.
You can try this easily, either create an Application or rename one as Setup.exe, Run it and then close it - wait a few seconds and the Product Compatibility Assistant Dialog will show.
I don't know where to start investigating how to stop this dialog, or where a setting may be to tell Windows the Installer was completed correctly.
Appreciate your thoughts and solutions thanks.
If I recall correctly, this happens when your install app does not include an application manifest. When UAC was introduced, MS introduced a heuristic detection for installers and shows the UAC elevation dialog. The heuristic checks for names like setup.exe, install.exe. The simple solution is to include an application manifest. If it is an installer you probably want to use the requireAdministrator setting.
The feature is known as Installer Detection and is discussed here.
For what it is worth, I would always build an installer with a dedicated install tool like InnoSetup for example.
As David pointed out, MS uses some fuzzy logic to try to guess if the program is an installer. I wouldn't rely on this, as this is only for supporting legacy installer applications.
All new applications should have a manifest file, specifying whether it requires elevated privileges.
If an application has a manifest file that includes the requestedExecutionLevel directive, then Windows does not attempt Installer Detection.
Any program that is detected as an installer program but does not add a registry entry to the Add Remove Programs section of the registry (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall) will get the message "This program might not have installed correctly".