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.
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.
We are trying to install a Java program to run as a windows service. Of the various available options(JSW, YAJSW, Launch4J, procrun, WinRun4J etc etc), we would like to use srvany.exe and install it using InstallShield. The Windows documentation says ...
Using RegEdit : create a "Parameters" key for your service (e.g. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MyService\Paramaters\ )
Using RegEdit : within the newly created "Parameters" key , create a string value called Application and enter the full path to the application you are wanting to run as a service.
Is there a way to achieve this using InstallShield without using InstallShield's registry editor? Is there an InstallScript call that can take care of adding and removing "Parameters" to the srvany entry in the registry? The solution should to work for Windows 2008R2 & 2003R2.
Any help will be greatly appreciated.
Assuming you are using a Basic MSI project type, I find a combination of the ServiceInstall, ServiceControl and Registry tables to be a good solution. Due to the fact that ServAny is really just a thunking layer, the ServiceInstall table can't fully describe the service without a little assistance from the Registry table. Still, no custom actions should be needed and the MSI will be very solid and robust.
As we were not able to find a favourable solution within available time, we decided to not use the srvany.exe. We decided to use YAJSW and within InstallShield use "Text File Changes" to modify the wrapper.conf for the YAJSW to launch our java application.
We have a client/server application which includes a Windows Service and a Winform client tool. I've managed to create a Wix project in Visual Studio (2010, using the wix 3.5 toolset). I'm using the "harvest" feature on the references instead of specifying every file, because there are many library projects involved.
Problems I'm trying to figure out:
How to include referenced DLLs? Some are in the GAC, some are in a relative path within the workspace. I assume I could list each file explicitly but it seems like there should be a way for Wix to autodetect them.
How to install the service while "harvest" is enabled. All the examples I've seen require adding an explicit element with KeyPath=true. However this doesn't work with the harvest=true setting.
I realize that the harvest functionality might be a convenience which is not feasible when there are more complex things going on. Should I give up on harvesting and just try to specify each file explicitly?
Most of the examples I've seen on Wix have been just snippets of xml files. Is there anywhere I can find complete real-world examples of installing services other non-trivial setup features?
Use WixEdit. http://wixedit.sourceforge.net/
It's very easy to import an entire folder using it.
Also, check out the great WiX tutorial here: http://www.tramontana.co.hu/wix/
5.4 Services Rendered
Services can be installed and started automatically.
http://wix.tramontana.co.hu/tutorial/net-and-net/services-rendered
For even more information, check out more WiX documentation here: http://wixtoolset.org/documentation/manual
I've got simple java-based ppt->swf sub-project that basically works. The open source software out there, OpenOffice.org and JODConverter do the job great.
The thing is, to do this I need to install OO.o and run it in server mode. And to do that I have to install OO.o, which is allot of software (~160MB) just to convert the source PPT files to an intermediate format. Also, the public OO.o distributions are platform specific and I'd really like a single, cross platform set of files. And, I'd like to not interfer with a system's current settings, like file extension associations.
As things are now, my project is not particularly 'software distribution friendly'.
So, the questions are:
Is it possible to create a custom distribution of OpenOffice? How would one about this?
How lightweight and unobtrusive can I make the installation?
Would it be possible to have a truly cross platform distribution since there would be no OO.o UI?
Are there any licensing issues I need to be aware of? (On my list of things to check out, but if you them already then TIA!)
I have no idea to accomplish such task, but Microsoft has its PPT viewer that is for free and very small, maybe in .NET (C#) you can use some kinda function to save into a intermediate file that you need...
and by the way, how are you handling slide transictions?
I found a software that does that but you need MS PPT installed.
this was just an idea, now regarding your actually question:
you can create your own installation of OO, just jump to the Installation project and follow the lines.
I did not read 'til the end, but from the 1st paragraph it seams what you are searching for.
No, not unless you are neck deep coding in the OpenOffice project.
If I have a windows service on a server, what is 'best practise' for updating the service? (say there was a bug in it, or I need to ad more features to it).
Is there a way I could shutdown the service, patch it and get it up and running in a more automated way?
(any links with code would be great)
Well, you could always up the version on the installer (if you used one) and run that, from my experience it overlays old versions with the newer one.
Or you could simply shut down the service, copy in the new .exe (and dependencies if any) and start it back up. This could all be done with scripting and the NET start/stop functions I would imagine.
I'm sure there is a better way to do it than this though...
Depends how your service is written - monolith EXE - you'll need to stop and restart it using a process of choice e.g. Installer, Script + Service Control, batch and NET STOP/START etc.
If you structure it a little differently e.g. bootstrap EXE loading your service implementation as modules that can be unloaded/reloaded then you can have a different conversation. This is of course a quite a bit more complicated.
I've had some success in C# with a hosting solution like this, similar conversation here:
I want my C# Windows Service to automatically update itself
InstallShield supports Windows Services. Leveraging installers will make your task much simpler.