I'm trying to modify an existing wxs file in order to configure a service. I want this service to be configure for restarting when it stops. This service is installed by my msi.
I use a util:ServiceConfig, nested under ServiceInstall. I set First/Second/ThirdActionFailure to "restart". This work fine except on Windows Seven and Windows Server 2008 R2.
I have look on internet, and found that I should use a ServiceConfigFailureActions Element, and maybe a ServiceConfig (not sure of this one).
I tried to use both of them, but nothing changes. The service is installed, no problems, but not configured for restarting on failures.
Here is the code corresponding to the ServiceConfigFailureActions Element.
<ServiceConfigFailureActions Id="ServiceRestarter" OnInstall="yes" OnReinstall="yes" OnUninstall="no" ResetPeriod="0">
<Failure Action="1" Delay="0" />
</ServiceConfigFailureActions>
I tried to set three failures under ServiceConfigFailure Actions, I tried to nest it under ServiceInstall or not, but nothing changes.
Has someone an idea that can help me ?
Thank you for reading.
Problem solved.
the ant script which generate the MSI file generate one file for 32bits and one file for 64bits.
I was modifying one and testing with the other.
Classic.
Thank you.
Related
I have developed an Excel XLL using ExcelDNA and C#. I am at the point where I would like to begin testing the deployment, but cannot find much information that actually provides steps that work.
My project was developed as a Class library with ExcelDna references. In the .dna file, I have the code below that will pack all resources into a packed version of the XLL (i.e. the Pack="true" attribute).
<DnaLibrary Name="ExcelXLL" RuntimeVersion="v4.0" Language="C#">
<ExternalLibrary Path="ExcelXLL.dll" LoadFromBytes="false" Pack="true" />
I would like to deploy the packed XLL to the target machine in the path:
%APPDATA%\Microsoft\AddIns
In order to automatically register the XLL with Excel, I need to add a registry key that depends on the version of Excel that the user has.
For instance, on my computer (Windows 7 64 bit running Excel 2007 32-bit), I would need to add a registry key to the following path:
HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Excel\Options\
The key would be type REG_SZ with the name OPEN (or OPEN1, OPEN2, etc.) and the value
/R "ExcelXLL-packed.xll"
I have 2 problems though. The first is in determining which version of Excel that the user has to get the correct path and the 2nd is to determine the correct OPEN version that I need to create (for example, if the user already has OPEN, OPEN1, and OPEN2 then I would create an OPEN3 key).
I am trying to do the installation using either the Setup and Deployment project or a InstallShield LE project and cannot determine how to go about this. Does anyone know how to do this or a better way of doing it?
EDIT 1:
I have done a great deal of research on this and have looked at several windows installers.
In the Package and Deployment and InstallShield LE, I can get the install/uninstall to work by putting an installer class into my class library and bundling project output with the install. In this approach, I handle inserting/removing the registry key using the installer class. The problem that I have is that the user must uninstall first before running a new install (no update capability).
I downloaded the Setup Factory demo version and can get install/update to work but cannot do the framework check (not shipped with the demo). Also, the uninstall fails (though I may be able to get this to work with some more investigation).
I am interested in using the WiX installer, but would like to know if anyone has a sample of how to perform the deployment using WiX. I would also like to know if I need to use the installer class or if there is a different way to handle the search for the OPEN[n] key under HKCU\Software\Microsoft\Office[Version].0\Excel\Options. If I were to use the project output to enable the installer class, then I need to have 2 separate target directories (one under Program Files for the basic project output and one under %appdata%\Microsoft\AddIns for the packed XLL).
Any help is greatly appreciated.
Thanks,
Lee
To detect Excel 32-bit vs. 64-bit, you can check the registry: Detect whether Office is 32bit or 64bit via the registry
For the OPEN, OPEN1, OPEN2 etc. you typically need a Custom Action in the install script that enumerates the keys.
Using IsWix and Wix 3.7, I was able to resolve this.
Useful links for how to register the components are as follows:
For generating a C# class to handle Windows Installer Custom Actions:
http://www.codeproject.com/Articles/132918/Creating-Custom-Action-for-WIX-Written-in-Managed?fid=1599130&df=90&mpp=25&noise=3&prof=False&sort=Position&view=Quick&spc=Relaxed&select=4131367&fr=1#xx0xx
http://blogs.msdn.com/b/jschaffe/archive/2012/10/23/creating-wix-custom-actions-in-c-and-passing-parameters.aspx
For setting the property of the CustomAction.config file to Content
WIX Custom Actions built for .Net Framework 4.0 does not work? Ways to resolve?
EDIT 1:
For general knowledge on WiX (Very important)
http://channel9.msdn.com/blogs/scobleizer/wix-team-the-most-used-piece-of-software-at-microsoft-and-its-open-source#Page=2
I'm working on an installer that is supposed to install Windows services in wix v3.8. The problem is that we need to make a major upgrade without uninstalling the service only to stop it.
We're using ServiceInstall and ServiceControl inside the component that holds the service exe file. Is there a way to make the execution of ServiceInstall conditional (using a condition like REMOVE="ALL" AND NOT UPGRADINGPRODUCTCODE) so the service is not uninstalled when upgrading (just stopped so we can upgrade the files)?
One solution would be to use custom actions, but maybe there is a better way?
Thanks!
You would have to override the action that process those elements. The following may work as long as you are okay if it applies to all services in your MSI package (if you only have one service then good on ya):
<InstallExecuteSequence>
<DeleteServices>NOT UPGRADINGPRODUCTCODE</DeleteServices>
</InstallExecuteSequence>
You don't need to condition for remove since the DeleteServices would already factor in the state of the Component.
What finally ended up working for me was
<DeleteServices><![CDATA[REMOVE ~= "ALL" AND (NOT UPGRADINGPRODUCTCODE)]]> </DeleteServices>
<InstallServices><![CDATA[NOT Installed]]> </InstallServices>
I arrived at this answer through a series of trial and error attempts and a combination of a few other threads with similar answers.
One of the possible reasons why only the doesn't work is because WIX also removes the service upon re-install.. we only want to install the service once, during the initial install. We also want to make sure that the service is removed upon uninstall. This is the only combination of conditions which worked for me, allowing the service to keep its settings and user account.
In one of the projects our team is working on, we are trying to make an automated deployment system for an existing desktop application. In order to do that we need to understand how InstallShield installs the application to begin with.
We have access to the InstallShield manifest, but there is an OCX file that we cannot figure out how to install manually (without InstallShield). This particular OCX file is set to 'Extract COM Information'.
Here's a screenshot:
The other OCXs in this application are self-registering, so they can be registered with Regsvr32.exe. But the OCX we are having problems with cannot be registered in that fashion.
How would one manually install an OCX file that is set to 'Extract COM Information' in an InstallShield manifest?
RegSvr32.exe calls the LoadLibrary API to load your DLL and then invokes the DllRegisterServer entry point inside your DLL. The code inside that function does the actual COM registration. If RegSvr32 is failing, that typically means a dependency of your DLL is missing or invalid.
InstallShield does all of this along with some really low level bit hacking to virtualize all of this and then harvest it. An old article on the subject is:
Spying on Registry Entries
InstallShield doesn't actually use this technique per say ( they have several techniques, most of which is not documented and various filters and transform engines to clean up the data ). If you are just looking for a way to do it without InstallShield, then look at Windows Installer XML's "Heat" command line tool. This can "harvest" COM metadata into WxS XML elements.
Also WiX is open source so if you are really curious you could go looking at their code.
As Christopher mentioned, InstallShield extracts COM information from your .ocx by seeing what it registers when invoked similarly to regsvr32.exe will invoke it. Its various forms of redirection (for capturing purposes) have the added benefit of working around several potential permissions problems while the file is registering in your build environment. However if I'm not missing the point of your question, it's "why doesn't regsvr32.exe your.ocx work on the target machine?"
This is a bit of a stab in the dark, as you haven't included enough information. While missing dependencies can cause this, I'm going to guess you only see this failure on Windows Vista/Server 2008 or higher. If this is the case, there's a good chance your application is trying to write to registry keys that are protected by Windows Resource Protection (WRP), or is being tripped up by a per-user typelib registration problem.
When a poorly behaved self-registration routine encounters WRP, it attempts to write to a registry key it lacks permission to modify, then fails the entire registration. I'm uncertain what happens to the keys it wrote before that point, but all ones after it definitely never make it to the machine. You should be able to confirm whether this is the case with a tool like Process Monitor.
What do you do if this is the case? Well, you can stick with an extraction approach like that of InstallShield (which you say you want to leave). You can fix the file to not attempt to write to protected keys (which you say you cannot modify). Or you might be able to use the Application Compatibility Toolkit (ACT) to shim things, but I don't see how you can generally do that downstream. Generally speaking, I would recommend fixing the file, or continuing to use a working approach.
We currently use Ant to automate our deployment process. One of the tasks that requires carrying out when setting up a new Service is to implement monitoring for it.
This involves adding the service in one of the hosts in the Nagios configuration directory.
Has anyone attempted to implement such a thing where it is all automated? It seems that the Nagios configuration is laid out where the files are split up so that they are host based, opposed to application based.
For example:
localhost.cfg
This may cause an issue with implementing an automated solution as when I'm setting up the monitoring as I'm deploying the application to the environment (i.e - host). It's like a jigsaw puzzle where two pieces don't quite fit together. Any suggestions?
Ok, you can say that really you may only need to carry out the setting up of the monitor only once but I want the developers to have the power to update the checking script when the testing criteria changes without too much involvement from Operations.
Anyone have any comments on this?
Kind Regards,
Steve
The splitting of Nagios configuration files is optional, you can have it all in one file if you want to or split it up into several files as you see fit. The cfg_dir configuration statement can be used to have Nagios pick up any .cfg files found.
When configuration files have changed, you'll have to reload the configuration in Nagios. This can be done via the external commands pipe.
Nagios provides a configuration validation tool, so that you can verify that your new configuration is ok before loading it into the live environment.
I've got a nant build script (.86 beta) and it is telling me this:
BUILD FAILED
Failed to initialize the 'Microsoft
.Net Framework 2.0' target
framework.
The process cannot access the file
'C:\Users\cconway\AppData\Local\Temp\tmp25E3.tmp'
because it is being used by another
process.
This file does not even exist on my machine. Does anyone know the cause of this? Rebooting seems to allow me to run the script once successfully, but every time after that I get this message (though the name of the tmp file changes per reboot).
Thanks!
Are there any third-party tasks which might leave temp files open or keep running in the background, thus leaving file locked?
Maybe try sysinternals process monitor which will allow you to see the process which has the handle on this file.
Also, make sure that you have all the right versions of .Net installed and they are the correct ones (SDK vs Runtime). If you open the config file for nant you can see where it expects the .net version to be go check to make sure it's there and that you can see hte compiler methods (csc, vbc, etc). So it could have something that is trying to find it but it's not there or the pathing is off.
It is beta so there could even be a typo in the config file.
The answer is my anti-virus. I should have tried disabling that first! Once I disabled it, everything worked like a charm.
Hope this helps someone.