Thanks Alex..
Regards,
Sajid
Alexander Shevchuk wrote:
Custom Action Type 51 is your friend:
CustomAction Id=AisOne Property=B Value=A is one /
CustomAction Id=AisNotOne Property=B Value=A is not one /
XXXSequence
Custom Action=AisOne After=...A=1/Custom
Custom Action=AisNotOne
I have a list of wxs files that packages files from a share folder where Team
build stages its build result. Currently I am having batch file containing
candle and light commands with sharefolder path as a parameter.
I want to integrate it with TFS so that each time I schedule a build it
creates
Bug. Would you mind filing it?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher
Karper
Sent: Thursday, July 31, 2008 19:48
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Binder variables from Votive
It's
Hi,
Do you using Wix V3 and Votive?
If yes you have 2 options:
I) just install WiX on Team Build Server and you can compile solution that
have .wixproj project and it will be work.
II) If you don't want/can not install Wix on Team Build server write me
private email I will explain how you
Here's my entire WiX file:
?xml version=1.0 encoding=UTF-8?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi
[http://schemas.microsoft.com/wix/2006/wi];
Product Id=5028B1BB-BCDE-470b-8A0D-25E49DE32661 Name=MyService
Language=1031 Version=1.0.0.0 Manufacturer=Me
But, its supported by the Installer Object of the Automation Interface.
Straight from the Windows Installer SDK...
The FeatureParent property specifies the parent feature of a feature.
An empty string for this property indicates the feature has no parent
and is a root item. This is a read-only
I've struggled with this recently as well (on XP and in Orca rather than
Light) as we were piloting running without admin rights. It turned out
to be caused not by the rights themselves but by the MSI policies. Since
validating involves launching a session object, and since we had
DisableMSI set
No sure I understand the answer. So I have the following command-line. The
extension I want to use is specified in the command line.
Candle Main.wxs -ext WixComPlusExtension.dll
When I run it, I get the following message.
C:\MultiCorpora Projects\Ito\Build\MSI\OutsideIn\Main.wxs(26) : error
Yeah, you can do it. You'll have to manually create your tasks and schedule
them in each of your project files. That's essentially duplicating what's
int he project files for Votive. I would say, even though it's going to be
some work, you'd still be better served by building Votive projects
Done and done...
http://sourceforge.net/tracker/index.php?func=detailaid=2034934group_id=105970atid=642714
On Fri, Aug 1, 2008 at 2:36 AM, Rob Mensching
[EMAIL PROTECTED]wrote:
Bug. Would you mind filing it?
-Original Message-
From: [EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED] On
Sajid,
Create a .wixproj file either manually or using the Votive integration with
Visual Studio, then check that project into TFS. After that's done you can go
through some easy steps to check the WiX tools into TFS and make a minor
modification to the .wixproj file so it will build on your
Mo Benmouffok wrote:
C:\MultiCorpora Projects\Ito\Build\MSI\OutsideIn\Main.wxs(26) : error
CNDL0200 :
The Component element contains an unhandled extension element
'pca:ComPlusAppli
cation'. Please ensure that the extension for elements in the '
http://schemas.m
Powell, Simon wrote:
But, its supported by the Installer Object of the Automation Interface.
If the raw MSI API supports that information, DTF could. But if the
Installer object is using private data that isn't otherwise exposed, DTF
wouldn't have a way to get it.
--
sig://boB
Daniel Rieck wrote:
I tried removing the Account and Password properties altogether, so it would
default to LocalSystem, but that didn't help either.
Try using a tool like InstSrv http://support.microsoft.com/kb/137890
to see if you can register the service by hand.
--
sig://boB
John-Daniel Trask wrote:
You mention there is no guarantees with this process. Does this mean there
would be a more robust mechanism of achieving the same outcome? Would
bootstrapping and then manifesting the bootstrapper in a manner that
elevated permissions resolve this issue more?
Here's the documentation I mentioned that should show up in the next weekly WiX
build:
Integrating WiX Projects Into Daily Builds
One of the most common reasons for using MSBuild with WiX project files is to
integrate the build of an installer into an existing daily build process. This
is
Hi,
I am using Wix 3.0.4318.0. I have created a Wix project using Votive
and have added it to TFS. I am attempting to either customise the
whole DefaultConstants property inside my TFSBuild.proj file or create
a property which is referenced in the DefaultsConstants property at no
avail.
I have
You can definitely do this. My first question is why are you using
CreateProperty instead of setting a property directly using PropertyGroup
elements? You should only have to use CreateProperty if the value is something
computed on the fly by the build.
Here's what our project file looks like:
Fixed a typo below, I botched a closing PropertyGroup tag.
Neil
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Friday, August 01, 2008 9:10 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Overriding
I have tried both CreateProperty and PropertyGroup, and neither seem
to work. I have placed mine inside Project element inside the
TFSBuild.proj file which looks like this
PropertyGroup
TestPropTestString/TestProp
/PropertyGroup
PropertyGroup
Here is a COM+ fragment I have just knocked up.
?xml version=1.0 encoding=UTF-8?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
xmlns:complus=http://schemas.microsoft.com/wix/ComPlusExtension;
Fragment Id=Files
DirectoryRef Id=INSTALLDIR
Component Id=LogEvnt_dll DiskId=1
Interesting, I'd never noticed that FeatureParent automation property before.
Unless I'm missing something, this looks like a rare case where the MSI
automation interface exposes functionality that is NOT directly exposed by the
Win32 APIs.
Still it is possible to get that information from the
I tried using it during patch application like:
msiexec /update Patch.msp /lv*x .\install.log
MSIENFORCEUPGRADECOMPONENTRULES=1 LOGVERBOSE=1
but reading the install.log I cannot find anything a bit more explicit
about this violation. It is certainly not saying something like you
changed the name
Joe,
Simply setting properties in the tfsbuild.proj file won't get them passed down
into the .wixproj. I wasn't sure about this and had to look it up. Is it an
option to just include those changes directly in the .wixproj file instead?
Neil
-Original Message-
From: [EMAIL PROTECTED]
Isn't the Name required to be the same in ServiceInstall and ServiceControl?
(As in the example at
http://avinashkt.blogspot.com/2007/05/how-to-install-windows-service-using.html
where they are both WixServiceInstaller).
Phil Wilson
-Original Message-
From: [EMAIL PROTECTED]
I'm already home for the weekend, but I'll check that on Monday, because I
changed all the names in the file before sending it...
*Von:* Wilson, Phil [EMAIL PROTECTED]
*Gesendet:* 01.08.08 20:40:07
*An:* General discussion for Windows Installer XML toolset.
WIX-USERS@LISTS.SOURCEFORGE.NET
Hi all,
I have a Wix 2.0 MSI that I've dark'd from a Visual Studio project. The problem
is that every time I uninstall the MSI from a computer, the MSI causes the
computer to be flagged for reboot, which I don't want. I was able to narrow it
down to it claiming a dll file is currently in use
27 matches
Mail list logo
