Here’s the real scoop: A service is a service is a service. That’s my motto. What I mean by that is I don’t care if you are using a C++ EXE, a VB exe, a C# EXE, some thunking host EXE such as SrvAny.exe… they all implement the same API’s to interact with the service … Read more
I am just wondering what your overall goal is (several options could apply): Is the goal to prevent regular users from running the application? (if so, you could make elevation required for running – not great, but should work. Regular users would be asked for admin password on application launch. If they don’t have it, … Read more
I don’t have time to test the options I list below, but they should be viable, technical possibilities. Hopefully one of the options will be satisfactory. But, first of all: I dislike this approach of setting secondary, top-level directories – is it really needed? Can you explain the scenario? Maybe there is a more reliable … Read more
INSTALLED should be Installed. Properties are case sensitive and you must definitely fix that in your condition – or else that part of the condition will never be true – even if the product is installed. The rest of the condition looks OK actually. Just some ideas to determine what is wrong: WiX Source Element: … Read more
ProductCode identifies a particular product. It changes every time you ship a new replacement product. UpgradeCode defines a series of products by using the same UpgradeCode in a updated products whose versions are expected to continually increase. By default, new product versions replace older product versions with a major upgrade. Because upgradecode defines a product … Read more
Here’s my two cents…. I don’t find the VersionNT property terribly useful. VersionNT64 is: VersionNT64 …. Not VersionNT64 to determine bitness. This is a bit of a hack (they do this, we do that…) but desperate times call for desperate measures…. In all of the compatibility games MSFT is playing they only seem to be … Read more
Your MSI needs to define a property like so: <Property Id=”SOMEPROPERTY” Value=”Default”/> You can then set this property from the bundle: <MsiPackage SourceFile=”<package>.msi” Id=”SomeId”> <MsiProperty Name=”SOMEPROPERTY” Value=”[SomeProperty]” /> </MsiPackage> After this you can set the property in the Bootstrapper as described here: WiX Bootstrapper: How do I set burn variables from the command line? Notice … Read more
There’s no way to do this without editing the registry, but you can do it programmatically. You have to be sure the icon is included in the deployment. We set our assembly description to the same string as our Product Name, so we can look through the uninstall strings for the right application by searching … Read more
You can do this without bootstrapper, if you create embedded transformations, and MSI installer will automatically apply one of them, according to your system locale. For complete details & scripts, please, follow this link: http://www.geektieguy.com/2010/03/13/create-a-multi-lingual-multi-language-msi-using-wix-and-custom-build-scripts/ They say, it is undocumented feature of Microsoft Installer, so please, be careful using it.
You have two different defined namespaces: In XML: http://schemas.microsoft.com/wix/2006/wi In XSLT: http://schemas.microsoft.com/wix/2006/wix As far as I know, correct namespace for WiX is http://schemas.microsoft.com/wix/2006/wi. So you should change your XSLT. XSLT: <xsl:stylesheet version=”1.0″ xmlns:xsl=”http://www.w3.org/1999/XSL/Transform” xmlns:msxsl=”urn:schemas-microsoft-com:xslt” exclude-result-prefixes=”msxsl” xmlns:wix=”http://schemas.microsoft.com/wix/2006/wi” xmlns:my=”my:my”> <xsl:output method=”xml” indent=”yes” /> <xsl:strip-space elements=”*”/> <xsl:template match=”@*|node()”> <xsl:copy> <xsl:apply-templates select=”@*|node()”/> </xsl:copy> </xsl:template> <xsl:template match=”wix:Wix/wix:Fragment/wix:DirectoryRef/wix:Component/wix:File[@Id and not (@Id … Read more