Hi All,
I'm trying to create a bootstrapper to install .Net 4. It works fine in
general, but fails with an error code 5100 on machines that don't have the
Windows Imaging Component already installed. If you run the .Net installer
separately it shows an error dialog that windows imaging is
Hi Matt,
First of all I never developed a .Net 4. Bootstrapper. But actually I
use the InstallShield Environment with a configuration for such a
bootstrapper. So in total they use the downloaded version of the
client profile dotNetFx40_Client_x86_x64.exe
Hi @ all,
i've wrote an .msi-installer which runs an external .exe this App creates a
.txt file in a Folder. after that the msi should check what for a .txt was
created and installs the right files. The Problem is even though i set the
Sequence of the Custom Action at Before = 'AppSearch' the msi
Hi Matt,
We ran into this problem recently too. Installs were failing on XP 64
bit (no SP3, just SP2 and no windows imaging component). I felt the
problem was exactly as you mentioned - we just want to launch the .Net
installer with the full UI, where it reports the prerequisite error
On Wed, 8 Sep 2010 09:55:43 +0100
Nick Ball nick.b...@grantadesign.com wrote:
We ended up switching to DotNetInstaller for bootstrapping .Net 4.0
http://dotnetinstaller.codeplex.com/
One problem I've come across with bootstrapping .NET 4 is that if you
check the version of mscoree.dll to
Why do you need to check the version of mscoree? Isn't the registry key
check sufficient?
http://msdn.microsoft.com/en-us/library/ee942965.aspx#detecting_net_fram
ework
-Nick
-Original Message-
From: Bruce Cran [mailto:br...@cran.org.uk]
Sent: 08 September 2010 10:31
To: General
On Wed, 8 Sep 2010 10:39:24 +0100
Nick Ball nick.b...@grantadesign.com wrote:
Why do you need to check the version of mscoree? Isn't the registry
key check sufficient?
It seems that WiX 3.6 doesn't use the registry key for checking the
version of .NET either; at least, after rebooting having
On Wed, 8 Sep 2010 11:17:29 +0100
Nick Ball nick.b...@grantadesign.com wrote:
The package that comes with Visual Studio (which I assume you are
currently using) does the same registry check. From the product.xml
file:
InstallChecks
RegistryCheck Property=DotNet40Full_TargetVersion
the checkCPU.exe comes in with the MSI as an extra file it dont need to be
installed its only to check some CPU-features, based on this features the
MSI should install all required Files.
if its possible with a Custom Action type 2 too solve this Problem?
Thanks, Noran
--
View this message in
I use that command to generated new file.wxs:
heat.exe file ''input folder\file.dll'' -gg -scom -out ''output file''
-template:fragment
And I added that output file to my Wix project.
But it's not registering my dll like regasm. What I doing wrong?
--
View this message in context:
For the older versions of the Framework I always used the reg
detection mechanism which was also the Microsoft recommended way
(Sorry don't know the MSDN reference at the moment). InstallShield
also uses the reg detection for 4.0 versions:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework
On Wed, 8 Sep 2010 14:21:58 +0200
Tobias S tobias.s1...@gmail.com wrote:
For the older versions of the Framework I always used the reg
detection mechanism which was also the Microsoft recommended way
(Sorry don't know the MSDN reference at the moment). InstallShield
also uses the reg
In that case are you sure the MSI is finding the CheckCPU.exe
application to run it (check a verbose log)?
Actually I think I see what the problem is.
You're using DirectorySearch FileSearch to set the path to the Custom
Action. This doesn't happen until AppSearch as you'd expect so you can't
Hello List,
Last day I decided to update WiX from v3.5.2013.0 to v3.5.2103.0
Since the update I get the following MessageBox while opening old or creating
new WiX
projects in MS Studio 2005 SP1:
A numeric comparison was attempted on $(MSBuildToolsVersion) that evaluates
to
instead of
Please file a bug. That sounds like a new issue.
On Wed, Sep 8, 2010 at 6:21 AM, Dmitry MINICH
dmitry.min...@visutechsystem.by wrote:
Hello List,
Last day I decided to update WiX from v3.5.2013.0 to v3.5.2103.0
Since the update I get the following MessageBox while opening old or
Hmm, it should be. From wix36\src\Setup\Bundle\Netfx.wxs:
util:RegistrySearch Root=HKLM Key=SOFTWARE\Microsoft\Net
Framework Setup\NDP\v4\Full Value=Version Variable=Netfx4FullVersion /
util:RegistrySearch Root=HKLM Key=SOFTWARE\Microsoft\Net
Framework Setup\NDP\v4\Full
Hm... ok. Just tried to configure a bootstrapper to install the .net
4.0 client profile and ran into the same issue as well :-) Was on a XP
SP2. After installing the
wic_x86_enu.exe installation of .net 4.0 sucedded. Ok. From my current
point of view it seems the following:
.Net 4.0 Supported
Hi,
I'm having a problem building an install package.
The build proj and log are attached.
Error:
The OutputPath property is not set for this project. Please check to
make sure that you have specified a valid Configuration/Platform
combination. Configuration='Release' Platform='BWS'
The
I am using build 3.5.1909.0.
Up to now I have been merrily adding assembly references to my WiX project and
setting Harvest to true etc to get the assemblies included into the MSI. For
some reason now though this has stopped working for any new assemblies I want
to add. The new assembly does
On 10-09-08 10:52 AM, Rob Jarratt (MCS UK) wrote:
Up to now I have been merrily adding assembly references to my WiX project
and setting Harvest to true etc to get the assemblies included into the MSI.
For some reason now though this has stopped working for any new assemblies I
want to add.
What differences are you seeing? What registry entries are missing? All of
them? Some of them?
Phil Wilson
-Original Message-
From: Tenzen [mailto:ojt...@gmail.com]
Sent: Wednesday, September 08, 2010 4:49 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] What is the
heat.exe : warning HEAT5150 : Could not harvest data from a file that was
expect
ed to be a SelfReg DLL: location, error: 193
The same dll but compile as 32bit works fine.
If I use 32bit harvest in 64bit installer will that be ok?
--
View this message in context:
I think that's an open bug in heat.
On Wed, Sep 8, 2010 at 12:02 PM, Tenzen ojt...@gmail.com wrote:
heat.exe : warning HEAT5150 : Could not harvest data from a file that was
expect
ed to be a SelfReg DLL: location, error: 193
The same dll but compile as 32bit works fine.
If I use 32bit
On 10-09-08 12:06 AM, Sohail Somani wrote:
Hi,
My installer launches the app upon installer completion (well, the last
wizard page.) By this point, a required environment variable (PATH) does not
seem to have been set as the new process gets the old version.
This makes sense as the msiexec
Hello,
I'm having trouble finding documentation on how to add an include and lib path
to MSVC's paths. I essentially have an SDK I'm setting up and I have a large
number of C headers and libs - so it'd be nice if it could automatically add
itself to the list of paths. I'm not sure how well it
Hi,
I am using wix to create MSI packages.
In the File Tag, I Use the attribute Name=ABCD~2.TXT. Compile shows the below
warning
FilePath (8165) : warning CNDL1044 : The File/@Name attribute's value
'ABCD~2.TXT' is an ambiguous short name because it ends with a '~' character
followed by a
26 matches
Mail list logo
