Our installers install also a configuration (text) file where - if necessary
- the user can configure some options to run our application. Unfortunately,
it will be overwritten without request when installing an upgrade (different
Product Id, different Product Version) using "msiexec /i ". We ar
While we do not use WiX inside TFS, we do use WiX in a daily build process on a
machine without installing WiX on the build machine.
Instead, we have checked in all the WiX binaries and targets files into the
tree. Basically, this is the contents of C:\Program Files\Windows Installer XML
v3\bin
Chris,
I just have croped full error in email, so its reason that you see
syntax error. Thanks for this article, but this one for VS2008, where
I am using VS2005.
But I did override some target in
Microsoft.TeamFoundation.Build.targets file, so my syntax in proj file
looks same as in example th
Well, to be fair, there's a syntax error in my XML which would make it not
work. I messed up copying the example code and retyping it for here, and
the closing tag is not the same as the opening tag. Find a property that
team build is passing that wouldn't be present in a local workstation build
Hi,
Thanks for a nice discussion, but last mails are missed a point of
the problem.
I will try explain how MSBuild working:
If you are will look inside of teambuild.proj you will see at the
begin Microsoft.TeamFoundation.Build.targets/> where this
target file have target with name "CoreBuild"
Pyro.exe would be broken by making it a 64-bit tool, since it has to interop
with a 32-bit dll (not via COM) that does not exist in a 64-bit version.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson
Sent: Sunday, July 06, 2008 4:24 PM
To: Genera
Has anyone seen this error while building the Votive2008.csproj? If so, what
is the resolve?
[exec] Done building project "Votive2008.csproj" -- FAILED.
[exec]
[exec] Build FAILED.
[exec]
C:\PROJECTS\Microsoft\WIX_DROP_1\src\votive\SDK_VS2008\Tools\Build\Microsoft.VsSDK.targets
Hi all,
A nice example chris I never thought of that option.. I have done it
completely differently, my current code is quite messy as I was trying to
find a way to do this first. It really needs to be refactored using a
serializer or something.
We use a master xml file here which contains en
Hi Wix experts,
We are getting this error when we try to use setupbld.exe.
setupbld.exe -out
D:\AGPM_30\source.binaries.x86fre\agpm_30\agpm_30_server_x86.exe -mt
D:\AGPM_30\source.binaries.x86fre\agpm_30\agpm_30_server.x86.en-US.msi -u 1031
D:\AGPM_30\source.binaries.x86fre\agpm_30\server_de-D
TFS enforces a mutex of 1 running build per build server per project.
Otherwise it's possible to get multiple builds going at once on a single build
server if they build out of seperate TFS projects.
InstallShield craps out when attempting to do this and I've repeatedly tried to
get them to f
Can TFS do concurrent builds? If more than one build kicked off at the
same time, that could be pretty bad.
Chris
On Mon, Jul 7, 2008 at 5:35 PM, Neil Sleightholm <[EMAIL PROTECTED]> wrote:
> Just a thought but why not put the WiX MSI in TFS and then do a silent
> install of WiX at the start o
Just a thought but why not put the WiX MSI in TFS and then do a silent
install of WiX at the start of the build. Then you get the best of both
worlds, a standard WiX install and WiX being automatically updated on
all build machines. Also, if the WiX tool set gets some new tools or
config you don't
Or, if I were smarter, I'd suggest you put the PropertyGroup structure in
your Team Build .proj file instead, without the condition at all.
Chris
On Mon, Jul 7, 2008 at 4:58 PM, Christopher Karper <
[EMAIL PROTECTED]> wrote:
> I would imagine the best way to do this would be to manually edit yo
I believe that WiX should just work with TFS since we use MSBuild.
Admittedly, I haven't tried TFS builds before, but from what I understand,
they're also driven by MSBuild. My guess is that you're not defining
$(WixTargetsPath) early enough - you before defining $(WixTargetsPath). If that's the c
I would imagine the best way to do this would be to manually edit your
.wixproj files.
Either change the reference to your WiX.targets file to be relative to the
project directory, or set the WixTargetsPath in a Property/Property section.
If you go that route, you can make it conditional on being
I picked this dialog from some Wix UI scheme and it is now compiled into
my project. However, I have no idea how to use it or how to get the
system to invoke it !?
Namely, during my testing, some other, system-provided dialog (i.e. not
part of any UI that I added) pops up and offers to close the
a
Jonh,
This is a reason that I am trying to inegrate WiX on build server in this way,
Thanks that you wrote those reason.
Did anybody have any idea how to do it?
I have found some ugly way to pass parameters: I just write some task
that add all my required properties to
task.BuildEngine.GlobalPro
Interesting read...
http://www.testearly.com/2006/07/25/the-magic-machine-antipattern/
Personally I build the build box. There are some really cool things you can do
with virtualization and TFS to break the magic machine antipattern.
Christopher Painter, Author of Deployment Engineering Blog
H
2 big benefits I can think of:
1) Machine maintenance
If you have 5 build machines, you don't have to update WiX on all 5 of
the build machines. The synch process pulls down the appropriate WiX version
during the build process.
2) Large projects that share Build machines don't need t
I can add wix.targets, light.exe, etc to source control, so build
server will take all this files with my sources, I will pass all
required parameters to wix.targets file, so I will able to compile &
link wix project without installing WiX on build machine.
Dima
On Mon, Jul 7, 2008 at 11:25 PM,
How would you expect the build server to be able to use the WiX tools
without them being installed?
I mean, strictly speaking you don't need to install them, just make them
available. But what would be the benefit?
Chris
On Mon, Jul 7, 2008 at 4:01 PM, Dmitry Berkovich <[EMAIL PROTECTED]> wrote
Hi,
I want compile WiX projects on team build server, but I don't want
install WiX on build server, so I am planning add all needed files to
source control.
I have some problem when I am compile wixproj file. wixproj file
contains those 2 lines:
$(MSBuildExtensionsPath)\Microsoft\WiX\v3.0\Wix
True. I just wanted to clarify that it `could` be done and I'm sure with the
proper attention to detail, could even be done reliably if it was ever truely
needed.
Regardless, the original poster is probably more interested in some way of
dynamically generating WiX UI XML from an external datas
You are correct.
I always forget about temporary rows..
However like your post details that still requires a custom action and
doesn't get the benefit of validation.
On Mon, Jul 7, 2008 at 10:08 AM, Christopher Painter
<[EMAIL PROTECTED]> wrote:
> Jason-
>
> MSI is a relational database that sup
On Sun, 06 Jul 2008, jmcfadyen wrote:
> what I would do is create 3 components for your 3 certs.
>
> Condition each of your components with a valid condition such as
>
> PROD="true"
> TESt="true" etc
>
> then using an Immediate CA chop up the computer name or domain name env
> var's then us
The latest build (4227.0) has an outdated UI localization file for Dutch.
Missing entries below.
Danny
---
http://schemas.microsoft.com/wix/2003/11/localization";>
[ProductName]
Setup
WixUI_Bmp_Banner
{\WixUI_Font_Title}Lees aub de [ProductName]
Licentie-overeenkomst
Jason-
MSI is a relational database that supports temporary records. It's entirely
possible to dynamically emit controls at runtime:
http://blog.deploymentengineering.com/2008/07/dynamic-windows-installer-ui.html
But otherwise you are correct. The general practice is to have a bunch of
disabl
Hi,
Any idea what causes this? I'm trying to follow the steps defined here:
http://blogs.msdn.com/pmarcu/archive/2007/06/28/sample-patch.aspx
to create a patch for my application, using wix 3.
I've created two wixout files, using light.exe -xo ...
When I try and create a transform, torch says:
t
Our application is available in two different versions - one with embedded
Java Runtime Environment (JRE) and one without. The JRE is nothing else than
a directory in the installation directory (no special registry settings). We
don't provide special update packages (containing just the differen
Thanks Bob,
Really appreciate it...
Andrew Lamb
If you've received this email by mistake, we're sorry for bothering you. It may
contain information that's confidential, so please delete it without sharing
it. And if you let us know, we can try to stop it from happening again. Thank
30 matches
Mail list logo
