Sounds like undocumented functionality of Melt. I don't see anything about
using it that way in the WiX.chm.
Also, binder variable don't solve the problem of binding the source files
into the XML file. They only give you a way to list a bunch of paths to
probe. So they don't replace the
Hi All,
I am using light.exe to create .wixout files with the -bf flag, I now get a
warning saying that this flag is deprecated. I can't find information on why.
I'm using .wixout files with bundle binary data to create patches (as described
in the Wix 3.6 book) and am now wondering if this is
I may have not been clear in my earlier emails, sorry about that.
I have a C# custom action that uses Microsoft.Win32.RegistryKey. I am
building this custom action with AnyCPU. The custom action searches for JRE
on the system and set a value to Session variable. I have 64-bit JRE
installed on
Hi,
I had to create two separate binaries for this, in a similar case. One built
for x64, the other x86 - then I trigger the appropriate one depending on the OS
architecture.
The issue is that C# Registry.LocalMachine will run against the Wow6432Node in
the registry, if the binary is 32-bit.
Thank You Jeremiah!
That's exactly what i was looking for since the last two weeks.
And the Stackoverflow-article contains a good explanation, what's the
difference between a SQL server login and a SQL server user.
Thank You and have a nice day!
-Ursprüngliche Nachricht-
Von: Jeremiahf
This is also necessary when accessing x64 areas of the file system. I have
64-bit versions of some of my custom actions when this is necessary.
--
John Merryweather Cooper
Senior Software Engineer | Enterprise Service Applications | Continuing
Development
Jack Henry Associates, Inc.® |
Regarding the comments about using AnyCPU this blog explains one reason why
on a x64 system AnyCPU runs a 32 bit instance of .Net
http://blogs.microsoft.co.il/sasha/2012/04/04/what-anycpu-really-means-as-of-net-45-and-visual-studio-11/
--
View this message in context:
We bundle MSUs up with the default bootstrapper for ease of installation of our
remote users.
A colleague of mine noticed that in c:\users\[logged in
user]\appdata\local\temp\ there are a bunch of randomly named folders with a
attached.cab and an ux.cab seemingly for each bundle ever run. I
They should be removed when the bundle finishes executing. If not, they may
have been held in use and require a restart. Has colleague restarted?
_
Short replies here. Complete answers over there: http://www.firegiant.com/
You need to start using the bindpath variables in your wxs sources. Melt will
take care of pointing the wixpdb to the new location.
-Original Message-
From: Nick Ramirez [mailto:nickra...@hotmail.com]
Sent: January-08-15 2:39 PM
To: wix-users@lists.sourceforge.net
Subject: Re:
+1 (but the first . below should be an or smile/)
_
Short replies here. Complete answers over there: http://www.firegiant.com/
-Original Message-
From: Tunney, Stephen [mailto:stephen.tun...@nuance.com]
Sent: Thursday,
Bind paths vs. Visual Studio project references (e.g.
$(var.MyProject.TargetDir))...the latter doesn't require passing custom
parameters to light. Why make the specifying of a source file more arcane
with a bind paths binder variable? Especially when the use case is a patch
file in the unseen
Melt kind of does an administrative install of the database (msi or msm). It
updates the wixpdb Data entries to point to the new location for the files.
-Original Message-
From: Nick Ramirez [mailto:nickra...@hotmail.com]
Sent: January-08-15 3:04 PM
To: wix-users@lists.sourceforge.net
You should be building separate MSIs for both arcitectures:
http://blogs.msdn.com/b/heaths/archive/2008/01/15/different-packages-are-required-for-different-processor-architectures.aspx
so build an x86 Dll for 32-bit systems and an x64 Dll for 64-bit.
In any case, AnyCpu for a Dll actually means
Yes.
_
Short replies here. Complete answers over there: http://www.firegiant.com/
-Original Message-
From: Nick Ball [mailto:nick.b...@grantadesign.com]
Sent: Thursday, January 8, 2015 3:17 AM
To:
My bad, I always forget that. For binaries, the Windows Installer peeks at the
executable binary and figures out how to host it. Any CPU managed code
assemblies a 'architecture preference' (default is x86, IIRC). You can change
that preference at build time, IIRC.
Ouch. So now you have to keep your old and new source files on hand. Would be
nice to keep the bind-files option or work it into the wixpdb. Also, not
being able to bind the files into the wixout or wixpdb means that if you
move the wixout/wixpdb and then try to run Pyro against it, all the paths
Bind paths or Melt.exe.
_
Short replies here. Complete answers over there: http://www.firegiant.com/
-Original Message-
From: Nick Ramirez [mailto:nickra...@hotmail.com]
Sent: Thursday, January 8, 2015 11:39 AM
To:
Update:
We figured out that this occurs when our check if installed application calls
Microsoft.Tools.WindowsInstallerXml.Unbinder.Unbind (from DTF), as we use that
to determine the UpgradeCode, as per another post from this list. I save to a
temporarily location and overwrite any existing
Oh, and to answer Rob: yes, since they go way back (see below on the update
as to how often they get created).
WiX (and hence DTF) 3.7, for what that's worth.
Keith Douglas
Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6
Statistique Canada | 170, promenade Tunney's
20 matches
Mail list logo
