My application will wind up shipping with a ton of loose resource files on
disk*. We will have several items with the following well-defined structure:
MyFile1.foo
MyFile1_files
\ 0
\ somefile.txt
\ 1
\ somefile.txt
...
\ 9
\ somefile.txt
This is how the files live
. Paraffin handles much of the GUID generation and updating
for you. For maintaining large directories of non-binary files where additions
and removals are common, this tool works very well for me. I just wish it
generated WiX 3.0 code
Jason Swager
- Original Message
From: Neil
consider things like this!
Neil
Neil Sleightholm
X2 Systems Limited
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
From: [EMAIL PROTECTED] on behalf of Neil Enns
Sent: Fri 11/07/2008 07:01
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-
nt in it now) then you're going to be pretty
much screwed (cause, in the worse case, all the GUIDs will change)... so
buyer-beware.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Friday, July 11, 2008 07:13
To: General discussion for
I'm messing around with trying to get my installer's ProductVersion to be based
off our main application's assemblyVersion. I thought this would be as simple
as putting !(bind.assemblyVersion.MyApplicationId) in the right places, but
this doesn't work unless I put Assembly=".net" on my main appl
://blogs.msdn.com/heaths/archive/2008/02/08/get-binder-variables-for-assemblies-without-installing-into-the-gac.aspx
Christopher Painter, Author of Deployment Engineering Blog
Have a hot tip, know a secret or read a really good thread that deserves
attention? E-Mail Me
--- On Fri, 7/11/08, Neil Enns
Christopher,
Last night in my aborted attempt to automate including files in my installer, I
got a basic extension up and running and working. If you can wait, I can zip it
up and send it to you tonight as a starting point.
Neil
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL
ld be excellent. I can't really wait, but I fear I will not make
substantial progress today, so it would probably be wonderful to have this
anyway. :-)
Chris
On Fri, Jul 11, 2008 at 1:17 PM, Neil Enns <[EMAIL PROTECTED]> wrote:
> Christopher,
>
> Last night in my aborted atte
Thanks for the suggestion, Amir. I'll tweak it next time I'm mucking with the
help file.
Neil
From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Amir Kolsky [EMAIL
PROTECTED]
Sent: Saturday, July 12, 2008 4:37 PM
To: General discussion for Windows Installer
For #2 you also have to add a reference to WiXUiExtension.dll. Since you are
using Visual Studio integration right click on the References node in Solution
Explorer and select Add Reference. Then find WixUiExtension.dll in the list and
click add. Close the dialog and build and things should work
It appears that our installer is magically detecting whether our application is
running at the time of an install, and even correctly closes it. However, the
FilesInUse dialog that comes with WiXUI isn't showing anything in the listbox
of running processes. What magic do we need to do to populat
From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Bob Arnson [EMAIL
PROTECTED]
Sent: Tuesday, July 15, 2008 6:46 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Where does FilesInUse dialog get its names from?
Neil Enns wrote:
> It appears that our install
You can think of merge modules (MSMs) like an application DLL: it's a package
of install instructions that can be included in a parent installer. You still
need some sort of tool to author the MSM, something that explains what files to
include, where they should go, and what the order of install
Murray,
I checked in changes between the builds you mention that change how localized
installers are built, to support multiple .wxl files in a project.
To figure out what's going on I'll need to see the verbose build log. From a
command line type "msbuild /v:d yourproject.wixproj > foo.txt" th
EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson
Sent: Wednesday, July 16, 2008 7:26 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Where does FilesInUse dialog get its names from?
Neil Enns wrote:
> Well, unfortunately, that's not what'
Murray gave me some logs and a sample project offline, and there is indeed a
bug in the new localization work I checked in last week. If anyone else hits
this let me know and I can give you a workaround.
Thanks,
Neil
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
PROTECTED]
Sent: Wednesday, July 16, 2008 8:27 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Where does FilesInUse dialog get its names from?
Neil Enns wrote:
> Still no love through the verbose log. I'm going to try making our app
> restart manager
Adam,
WiX ships with complete MSBuild support through a set of tasks and targets,
there's no need to try and hand-edit things.
Do you have Visual Studio installed? If so, create a new Visual Studio project
and look for a WiX node in the new project dialog. Create that, add the
contents of your
ment), then just use the MSBuild task in my build
file to build them. Does that sound sensible or have I overcomplicated things?
Anyhow, thanks again - everything's working.
Adam
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: 17 Ju
ECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony Juricic
Sent: Wednesday, July 16, 2008 7:30 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Where does FilesInUse dialog get its names from?
Same problem here so I second a plea for help and more info
-----Or
esday, July 16, 2008 7:30 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Where does FilesInUse dialog get its names from?
Same problem here so I second a plea for help and more info
-Original Message-
From: Neil Enns [mailto:[EMAIL PROTECTED]
This was my approach for a long time as well, but last week I changed to using
a binder variable. The core application we install is always stamped with an
assemblyversion by the build process. Instead of passing flags in via the
Candle command line, or using a pre-processor variable, I now grab
While Rob wasn't part of the change, I was :)
I'm looking for feedback on how to best approach tweaking this. One option
that's been suggested is to not rename the MSI file, and to instead put them
into subdirectories. So on a build you'd have
$(TargetDir)\CultureName\$(TargetName)$(TargetExt).
Taking this approach will require literally pulling in everything, right?
Including all the localization files for WiXUI_Minimal?
Neil
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher
Karper
Sent: Friday, July 18, 2008 1:58 PM
To: General dis
Ilya,
If we changed things so the localized output went into subdirectories, rather
than modified the name of the MSI, would htat work for your situation?
Neil
From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Ilya Slobodin [EMAIL
PROTECTED]
Sent: Monday, J
OTECTED] [EMAIL PROTECTED] On Behalf Of Dominik Guder [EMAIL
PROTECTED]
Sent: Monday, July 21, 2008 12:23 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Localization filename change
Neil Enns wrote:
>
> While Rob wasn't part of the change, I was :)
>
> I'
) into the
overridable property, say TargetDirLocalized.
Best regards,
Ilya Slobodin
- Original Message -----
From: "Neil Enns" <[EMAIL PROTECTED]>
To: "General discussion for Windows Installer XML toolset."
Sent: Monday, July 21, 2008 6:18 PM
Subject: Re: [WiX-users] Localizat
This won't work because you're using a pre-processor check for your condition,
which happens at the time you build the MSI, not at the time you run it.
You need to do the check by adding a element to the
element that I assume eventually includes the Registry snippet below.
Neil
_
One option to consider is using the shipping MSBuild .targets file that has a
complete build process for WiX in conjunction with NAnt. Trying to re-construct
a build process using individual tasks is often fraught with peril, and using
the one that ships with WiX is almost always a better idea.
For those that don’t read Bob’s blog and see the weekly release summaries,
please pay close attention to the note below regarding changes to address bug
2020595. In builds 3.0.4325.0 and later the output location for WiX builds of
localized installers is now outputdir\culturename\targetname.msi.
That GUID would be generated at MSI build time, not at MSI install time, so it
won't be unique for each user.
Neil
From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Pat Higgins [EMAIL
PROTECTED]
Sent: Monday, July 28, 2008 4:51 AM
To: General discussion for
Greg,
Check out the netfxutil extension. It includes many properties, including the
directories for various versions of the framework. The help file has a how to
on using it to get the framework version, and that is similar to using it for
the directory. All the available properties are in the
To elaborate a bit on what Rob states below (thanks for setting me straight,
Rob!), you can use !(loc) variables as the value for the Source attribute on a
element. So in your Japanese localization file you can set a String
property to the path to the Japanese version of the files on disk, and
Something's not making sense. Properties like [WindowsFolder] are stored
directly in the MSI and are resolved at install time. Were you simply using it
as a path in something like a element? What do the install logs show
when you run the MSI on the target machine?
Neil
___
Stefan,
We had the same problem and resolved it by simply downloading the source to WiX
and then building the printeula project inside of it. Then we included the
printeula.dll in our installer.
Neil
From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Stefan
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 da
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 ofte
You can definitely do this. My first question is why are you using
CreateProperty instead of setting a property directly using
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
build log, it has
all the defines that have been specified using votive.
Any ideas?
2008/8/1 Neil Enns <[EMAIL PROTECTED]>:
> You can definitely do this. My first question is why are you using
> CreateProperty instead of setting a property directly using
> elements? Yo
number that is
generated in the tfsbuild.proj into the .wixproj. So there is no way
to get them into the .wixproj?
Thanks
2008/8/1 Neil Enns <[EMAIL PROTECTED]>:
> Joe,
>
> Simply setting properties in the tfsbuild.proj file won't get them passed
> down into the .wixproj
Neil,
Can you open a sourceforge bug on this requesting the clarified documentation?
Thanks!
Neil
From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Neil Sleightholm [EMAIL
PROTECTED]
Sent: Sunday, August 03, 2008 2:38 AM
To: General discussion for Windows
If all you are trying to do is register your DLL in the GAC, add
Assembly=".net" to your element and it'll automatically get installed to
the GAC.
Neil
From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Poornima S [EMAIL
PROTECTED]
Sent: Monday, August 04,
John,
Are you building using a .wixproj file? Or custom command-line stuff?
Neil
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Gilbert
(MBS)
Sent: Monday, August 04, 2008 4:26 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] How to ign
only installing one assembly per
component (unless the assembly consists of multiple files and is a multi-module
assembly)."
Neil
From: Poornima S [EMAIL PROTECTED]
Sent: Monday, August 04, 2008 9:54 PM
To: wix-users@lists.sourceforge.net
Cc: Neil Enn
Have you set the codepage appropriately on your element? See the
"Code Page" topic in the WiX documentation for more details.
Neil
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nemzági Ferenc
Sent: Monday, August 11, 2008 3:19 PM
To: wix-users@lists.s
y fast, thanks a lot!
I changed it Central Europan (1250), a it it works!
Thanks again,
Nemzagi
Neil Enns <[EMAIL PROTECTED]> írta:
> Have you set the codepage appropriately on your element? See the
> "Code Page" topic in the WiX documentation for more details.
>
&
That's correct. This is alluded to in the documentation for ICE warning 69 at
http://msdn.microsoft.com/en-us/library/aa369019(VS.85).aspx:
"If the component referenced with the [$componentkey] property is already
installed and is not being changed during the current installation (for
example,
Michael,
Were you getting ICE validation warning when you were using the # reference?
The way you had your components set up I would expect to see the validation
warning specifically designed to prevent us from having to think :) It was
raised in my installer when I used # incorrectly, so I fix
Sonar,
Have you looked at the sample on Alex's blog for doing major upgrades? The
details are at
http://blogs.technet.com/alexshev/archive/2008/02/15/from-msi-to-wix-part-8-major-upgrade.aspx.
It's a little lengthy but it should give you the details you need to make this
work properly.
Neil
You should be able to use a combination of the Intel, Intel64, and Msix64
standard properties. They are documented at
http://msdn.microsoft.com/en-us/library/aa370905.aspx#hardware_properties.
Neil
From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Michael F
For specific explanations of how to integrate the redists into your installer
see the How To topic in the CHM that comes with WiX. It's in the How Tos
section and goes step by step through how to make this work.
Note that you shouldn't be including the policy files in your installer either.
The
You don't even have to that much. WiX includes a library to do this for you,
which you can just include and then reference the property with a .
See the How To: Check for .NET Framework Versions in the WiX CHM file for the
general approach, but substitute in WixVSExtension instead of WiXNetExten
Robert,
This happens when you have multiple .wxl files in your project with different
cultures in them. Setting the Cultures field in properties will control which
languages get built, but the output will still go into the sub-folder (this is
so you can set up different configurations, for exam
desktop vstudio and tfs build agent server
pre/postBuild event authoring more straight forward.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Thursday, September 11, 2008 1:37 PM
To: General discussion for Windows Installer XML toolset.
Subject:
ration)\ folder.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Thursday, September 11, 2008 1:53 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] what setting causes current wix build output
I've found the MsiBreak environment variable is a very useful tool for
debugging custom actions. See
http://msdn.microsoft.com/en-us/library/aa368264.aspx for the details, but in a
nutshell:
1) Start a command prompt (if you are on Vista make sure it is elevated. XP
make sure you are an admin)
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Thursday, September 11, 2008 1:53 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] what setting causes current wix build output to land
in bin\$(Confi
igning and sandcastle chm file generation prior to msi
build that uses those bits.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Thursday, September 11, 2008 5:16 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [
$(TargetExt)"
to my post build event and it caused build errors.
Where am I supposed to add "" in my Setup.wixproj to see it during build processing?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Thursday, September 11, 2008
tp://schemas.microsoft.com/developer/msbuild/2003"; />
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Friday, September 12, 2008 4:21 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] what setting
Look in the Wix.CHM file for the How To topic on how to create shortcuts to
applications. It shows you the steps to take to author the setup correctly to
remove these errors.
Neil
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roger Yen
Sent: Thursday,
ny problems yet...)
Thank you,
Roger Yen
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Thursday, September 18, 2008 4:26 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Question about LGHT0204:ICE43 and ICE
This is by design. Project references to Win32 (non-managed) projects are not
supported.
Neil
From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Worawit Wangwarunyoo
[EMAIL PROTECTED]
Sent: Thursday, September 18, 2008 9:09 PM
To: wix-users@lists.sourceforge
Alex's blog entry at
http://blogs.technet.com/alexshev/archive/2008/02/15/from-msi-to-wix-part-8-major-upgrade.aspx
is a good starting point.
Neil
-Original Message-
From: Rob Mensching [mailto:[EMAIL PROTECTED]
Sent: Monday, September 22, 2008 10:40 AM
To: General discussion for Windo
The answer to your last question is no, you do not need (and should not)
include the policy modules.
Neil
From: Travis Burkitt [EMAIL PROTECTED]
Sent: Tuesday, September 23, 2008 7:58 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-user
de and non-Unicode are also in there,
plus versions of mfcm90.dll for Winforms integration.
Phil Wilson
-Original Message-
From: Neil Enns [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 23, 2008 8:05 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users
tem was built to
(but it isn't, anymore)...
Thoughts?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Thursday, September 11, 2008 1:53 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] what se
x.php?func=detail&aid=2127057&group_id=105970&atid=642714
-Original Message-
From: Neil Enns [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 24, 2008 1:02 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] what setting causes current wix build
Shao Voon,
Your attachment didn't come through, but I'm curious: why are you trying to
hand-author build process for this? WiX ships with a complete build process for
building WiX projects using MSBuild. See the topic "Using WiX with MSBuild" in
the Wix.chm file that ships with your install. It
There is a complete example of how to do this in the WiX help file that ships
with WiX. Look under the How To section.
Neil
From: Wong Shao Voon [EMAIL PROTECTED]
Sent: Wednesday, October 08, 2008 2:54 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] H
Use the NetFx library that comes with WiX. See the WiX documentation, there's a
topic in the How To that describes how to check the Framework version. It
should also have a reference to a table with all the predefined properties for
each framework version.
Neil
I don't know whether the change was intentional, but to fix this you can edit
the .wixproj file to redirect the location. See the "Using WiX with MSBuild"
topic in the WiX.CHM for the property you need to set.
Neil
From: Neil Sleightholm [EMAIL PROTECTED]
Sent:
The Wix.chm file lists them. Look under the Advanced WiX Topics section,
Standard Custom Actions.
Neil
-Original Message-
From: David Bartmess [mailto:[EMAIL PROTECTED]
Sent: Friday, October 17, 2008 8:35 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users]
It is part of WiX 3.0.
Neil
-Original Message-
From: Kalvagadda, SivaKrishna (MLX Technology) [mailto:[EMAIL PROTECTED]
Sent: Friday, October 17, 2008 8:55 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Creating user groups using WIX
Thanks for you
The WiX help file for WiX 3.0 has a bunch of "how tos" that document best
practices for various tasks. Most of them will likely apply to WiX 2.0 as well.
When you are done with your best practices doc I'd love to see a copy :)
Neil
-Original Message-
From: Greg Silin [mailto:[EMAIL PROT
Howdy all,
I'm working on an installer that needs to detect whether a specific version of
DirectX 9.0 is installed (9.0c). Unfortunately a standard registry check using
this:
doesn't work since the Version value is the same for all flavours of DirectX
9.0. I do know a specific file
at the SDK documentation as well.
Neil
From: Bob Arnson [mailto:[EMAIL PROTECTED]
Sent: March-19-08 8:08 AM
To: Neil Enns
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Detecting the version of an installed file?
Neil Enns wrote:
I'm working on an installer that needs to detect whe
I came across a method for doing this a while back, and found it again by
searching for "url shortcut wix" at live.com. Try:
http://www.joyofsetup.com/2008/03/18/new-wix-feature-internet-shortcuts/.
It looks like you roll to a recent build of WiX it should have the support
built in.
Neil
From
Does WiX 3.0 currently have any support for signing the generated MSI at the
end of the build process? I took a quick peek at the wix.targets file and
didn't see anything obvious. Is there a recommended way of doing this?
Thanks,
Neil
s done, although again, it'd be nice if this were
standard in the wix.targets file :)
Neil
From: Rob Mensching
Sent: May-07-08 2:33 PM
To: Neil Enns; wix-users@lists.sourceforge.net
Subject: RE: Signing built MSIs?
Write a task that signs files?
Seriously, some people have suggested that
thing like
that, and have that trigger signing of the resulting MSI at the end of the
build process.
Neil
From: John Vottero [mailto:[EMAIL PROTECTED]
Sent: May-07-08 3:02 PM
To: Rob Mensching; Neil Enns; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] Signing built MSIs?
MSBuild does
reForBuild;
PreBuildEvent;
ResolveReferences;
AddCompilerDefineConstants;
CompileAndLink;
GetTargetPath;
SignInstaller;
IncrementalClean;
PostBuildEvent
Hopefully someone finds this useful.
Neil
From: Neil Enns
Sent: May-07-08 3:06 PM
To: &#x
I'm using WiX 3.0 and override the location with the following entries in my
.wixproj file:
$(SomeEnvVariable)\wix\3.0.3907.0\bin\Wix.targets
$(SomeEnvVariable)\wix\3.0.3907.0\bin
$(WixToolPath)\wixtasks.dll
It was a while back, but I believe I also changed the default imports line
Try this blog entry for details:
http://blogs.technet.com/alexshev/archive/2008/02/15/from-msi-to-wix-part-8-major-upgrade.aspx
Also try the MSDN articles on major upgrades:
http://msdn.microsoft.com/en-us/library/aa369786(VS.85).aspx.
Neil
From: [EMAIL PROTECTE
Is there such a thing as temporary files during a wix install? We're shipping
some redist installers as part of our installer, and they only need to be on
the end user's machine for the duration of install. What's the right way in WiX
to indicate they're temporary and should be cleaned up after
Has anyone had any experience with installing the .NET 3.5 redistributable as
part of a WiX installer? We are a Vista-only application, and know we'll need
to install .NET 3.5 to run. There's a standalone exe (netfx35_x86.exe) that
installs the redist, but we're not sure how to integrate that in
That's what I was afraid the answer would be :( Thanks.
Neil
From: Kelly Leahy <[EMAIL PROTECTED]>
Sent: Thursday, May 15, 2008 4:50 PM
To: Neil Enns <[EMAIL PROTECTED]>
Cc: wix-users@lists.sourceforge.net ; [EMAIL
PROTECTED] <[EMAIL PRO
stopher Painter [EMAIL PROTECTED]
Sent: Thursday, May 15, 2008 6:30 PM
To: Neil Enns; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Temporary files in WiX?
Another reason why I have to use a different tool.Everyone in the WiX world
has to roll their own equivilant to InstallShield
008 2:36 AM
To: Neil Enns; wix-users@lists.sourceforge.net
Subject: RE: Temporary files in WiX?
There isn’t anything built into the Windows Installer that supports temporary
files during the install. Thus, you will need a Custom Action to manage the
temporary files. If you’re requiring
e'll leave the files around.
Neil
From: Bob Arnson [mailto:[EMAIL PROTECTED]
Sent: May-16-08 8:42 AM
To: Neil Enns
Cc: Rob Mensching; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Temporary files in WiX?
Neil Enns wrote:
Thanks for the details, Rob. It sounds like from you write bel
That's why we're bringing the files along ourselves for the ride :) Now if only
.net 3.5 was so kind... Sigh.
Neil
From: Bob Arnson [mailto:[EMAIL PROTECTED]
Sent: May-16-08 9:57 AM
To: Neil Enns
Cc: Rob Mensching; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Temporary fi
The problem with option 1 is that it means we have to give up control of the
end-to-end install and out of box experience for our product. When you are
trying to construct a carefully designed user experience and impression of your
application, a bootstrapper is a pretty fugly addition to the mi
o working with third-party installers such as InstallShield to build
Client Profile support into their setup packaging technologies."
S... does that mean WiX too? :)
Neil
From: Christopher Painter [EMAIL PROTECTED]
Sent: Sunday, May 18, 2008 6:34 PM
To: N
Ok, there's gotta be something obvious I'm missing here. How do I compare the
result of a RegistrySearch for a dword against a number? I need to make sure
the number returned is greater than or equal to 1, but it has the pesky "#" in
front of it so a straight MYVARIABLE >= 1 in the condition fai
I guess that'll work, but wow, there's no way to do an integer greater than?
Neil
From: Christopher Painter [mailto:[EMAIL PROTECTED]
Sent: Monday, May 19, 2008 2:51 PM
To: Neil Enns; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Comparing result of a dword RegistrySearch t
You can use the NetFxExtension that comes with WiX.
http://www.wixwiki.com/index.php?title=NetFxExtension.
Add -ext WixNetFxExtension to both candle.exe and light.exe, then you can add a
PropertyRef to NETFRAMEWORK35. There's an example on the above page of how it
all works.
Neil
From: [EMAIL
I was one of those people. It's painful. And I can figure out Wix...
Neil
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching
Sent: Thursday, May 22, 2008 10:22 AM
To: Don Caton; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] wix maili
Are you doing clickonce to get the setup.exe bootstrapper? In other words, is
this "publish" from inside Visual Studio? If so, I doubt you can embed the
resource into that setup.exe bootstrapper.
If you're writing your own bootstrapper then yes, you can do this. Just add the
MSI to your project
lto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Thursday, May 22, 2008 1:40 PM
To: Wilson, Phil; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Embedding patch inside bootstrapper
Are you doing clickonce to get the setup.exe bootstrapper? In other words, is
this "publish"
1 - 100 of 145 matches
Mail list logo
