What types of things are you needing to download? What about a post-install
process that downloads what you need, perhaps something similar to NuGet?
-Original Message-
From: Alec Taylor [mailto:alec.tayl...@gmail.com]
Sent: Thursday, September 22, 2011 12:19 AM
To: General discussion f
I'll see what I can do without extending Windows Installer.
I'm thinking the most difficult part will be showing output messages
and progress.
On Thu, Sep 22, 2011 at 2:13 PM, Rob Mensching wrote:
> Yes, but I think the feature you are asking for requires extending Windows
> Installer. If you fi
Yes, but I think the feature you are asking for requires extending Windows
Installer. If you find a way to do it then that'd be an interesting addition
to the WiX toolset.
On Wed, Sep 21, 2011 at 8:59 PM, Alec Taylor wrote:
> Yes, but WiX can be extended without extending Windows Installer, righ
As long as you have WiX toolset installed in VS, and VS can find the project
references as documented in the link below, they should still be openable in
VS.
On Wed, Sep 21, 2011 at 6:29 PM, JesseBearden wrote:
>
> David Rickard (USA) wrote:
> >
> > VS2010. Will the TFS build server need to have
Yes, but WiX can be extended without extending Windows Installer, right?
On Thu, Sep 22, 2011 at 1:42 AM, Christopher Painter wrote:
> Windows Installer XML ( WiX ) is a toolset that authors Windows Installer
> databases. Windows Installer is Microsoft Windows operating system
> component and i
This is a good link! I think I'll update our build servers to work this way
too.
-Original Message-
From: JesseBearden [mailto:jesse.bear...@oce.com]
Sent: Wednesday, September 21, 2011 8:29 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Best way to invoke Wix from a TF
David Rickard (USA) wrote:
>
> VS2010. Will the TFS build server need to have WiX installed on it to
> build them?
>
You don't necessarily have to install WiX on the build server. I tend to
avoid it for the cases where one branch will need a different version, and
since some developers don't h
Hi David,
thanks a lot for your answer. This was indeed the error. I moved the
keypath to the file element and it works now :-)
Alexander
Am Wed, 21 Sep 2011 10:42:23 +0100
schrieb "David Watson" :
> Oops don't think I explained that well, you should try moving the
> keypath=yes from the compon
I concur. And having just had both the "magically disappearing" and the
"magically appearing" file situation, it's no fun to figure out. Generated
builds are great to prototype an installer or to run a very pre-release
installer, but I want both hands "on the wheel" for anything that's going t
3.5 RTM (3.5.2519)
From: "John Bergman"
Sent: Wednesday, September 21, 2011 1:46 PM
To: "General discussion for Windows Installer XML toolset."
Subject: Re: [WiX-users] WiX TFS Source Control bindings in a WixProj -
Problem with a manual fix.
Is
Email me when the day comes that a file unintentionally disappears from the
installer and it goes unnoticed. :-) Trust me, I've been doing build and
install for 15 years and it will happen.
The problem you mention is easily solved by putting the responsibility on
the developer to make sure
Is that with 3.5 'RTM', or one of the 3.6 builds?
-Original Message-
From: Christopher Painter [mailto:chr...@iswix.com]
Sent: Wednesday, September 21, 2011 1:34 PM
To: General discussion for Windows Installer XML toolset.; General discussion
for Windows Installer XML toolset.
Subject:
Never noticed that before. I only spent a minute looking at it just now but
it looks like I can create the configurations through the UI but there's a
data refresh problem. It's not until I quit out and come back do the new
configurations appear in the drop down.
--
Thanks for the advice.
Though our devs work with the raw built files and our TFS builds clearly
identify build breaks. Installer issues (like someone adding a file to the
solution but forgetting to add it to the installer) would be at risk of going
unnoticed.
From: Christopher Painter [mailto:
I never saw it in 3.5 either, which is where I added all of the other projects.
I had updated to 3.6.1518 sometime ago, this is the first time I had to add a
project to TFS, and the first time I've had an issue.
Another issue that has been there since the beginning, though low priority (at
lea
I've been running WiX 3.5 in VS2010 with TFS 2010 and haven't seen this
problem. I've done some VS SDK work and I know how hard it is and how
much work the team put into making votive work right. I sure wish
InstallShield's VS integration worked nearly as well. Actually I'd settle
for it
Yes.
--
John M. Cooper
-Original Message-
From: David Rickard (USA) [mailto:davri...@microsoft.com]
Sent: Wednesday, September 21, 2011 11:02 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Best way to invoke Wix from a TFS build workflow?
VS2010. Wi
Not sure if anyone else has encountered this, but with Wix 3.6.1518.0 when I
added a solution to TFS source control it did not update the WixProj correctly,
and hence everytime I open the solution I get a message telling me that the
project is not under source control, and whether or not I wante
Open the solution up and click properties on the merge module project. Go
to the build events tab then type your command into the pre-build event
command line.
I still wouldn't do it though. This type of dynamic authoring frequently
masks up stream problems. What should have been a build br
What you is describing is harvesting and WiX 3.5 I believe had this
functionality but was disabled by default. The wixproj is an msbuild
document so you can hook any kind of prebuild target into it that you can
imagine.
I personally don't do what you suggest though. I want to explictly
add/
Alright. In this case how would you run a program to add all the files in a
given directory to the MSI? Before we had an EXE that generated a merge module
of files based on a directory. Could this hook in somehow?
-Original Message-
From: Christopher Painter [mailto:chr...@deploymentengi
I am using CAQuietExec64 with Return="Ignore" to execute an executable without
causing the install to fail if the executable returns an error code.
This is working very well, but I have the need to initiate an action if the
executable does fail. I do not want the overall install to
Yes. If you don't have it you'll get an msbuild error saying it can't find
$(MSBuildExtensionsPath)\Microsoft\WiX\v3.x\Wix.targets.
From: "David Rickard (USA)"
Sent: Wednesday, September 21, 2011 11:05 AM
To: "General discussion for Windows Installer
VS2010. Will the TFS build server need to have WiX installed on it to build
them?
-Original Message-
From: John Bergman [mailto:john.berg...@xpedienttechnologies.com]
Sent: Tuesday, September 20, 2011 4:12 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-use
Windows Installer XML ( WiX ) is a toolset that authors Windows Installer
databases. Windows Installer is Microsoft Windows operating system
component and is not open sourced.
From: "Alec Taylor"
Sent: Wednesday, September 21, 2011 10:33 AM
To: "G
But I though WiX has been released under CPL, [an open-source license]
encouraging collaboration?
I would be very happy though, to work for Microsoft to build int his
much needed feature.
Who should I speak with (if it comes to this)?
On Thu, Sep 22, 2011 at 12:36 AM, Rob Mensching wrote:
> The
The Windows Installer is owned by Windows. You'd need need to get hired by
Microsoft and work for the Windows Installer team to build this
functionality into the Windows Installer?
Burn is a bootstrapper/chainer that is part of the WiX toolset (
http://robmensching.com/blog/posts/2009/7/14/Lets-tal
As the others have said, there's nothing special about wixproj
Projects--they'll build fine as part of a VS 2010 Solution. To get build order
right, you'll want to have appropriate references to projects consumed by the
wixproj in it. All of our builds make either an MSI or a wixlib, and three
Thanks a lot. It is simple and nice solution. It works as I need.
2011/9/21 Peter Shirtcliffe
> When you refer to anything in a fragment, the whole fragment is included.
>
> Your last idea was the right one: put each feature in its own fragment
> along
> with the resources that are specific to
Oops don't think I explained that well, you should try moving the keypath=yes
from the component element to the file element.
Also making a verbose log will tell you why its failing.
Msiexec /i blob.msi /l*v log.txt
-Original Message-
From: David Watson [mailto:dwat...@sdl.com]
Sent:
From ServiceInstall Element docs...
"The service executable installed will point to the KeyPath for the
Component. Therefore, you must ensure that the correct executable is either
the first child File element under this Component or explicitly mark the
appropriate File element as KeyPath='yes'."
When you refer to anything in a fragment, the whole fragment is included.
Your last idea was the right one: put each feature in its own fragment along
with the resources that are specific to that feature. Put the shared
components into their own fragment. Feature A and feature B should both
refe
32 matches
Mail list logo
