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 mis
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
(http://download.microsoft.com/download/5/6
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
'gracefully
On Wed, 8 Sep 2010 09:55:43 +0100
"Nick Ball" 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 see if it's 4.0 or newer
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 discus
On Wed, 8 Sep 2010 10:39:24 +0100
"Nick Ball" wrote:
> 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
My (simple) application should continue to work on future vers
How are you getting CheckCPU.exe onto the target system? You may want to
change your Custom Action to a Type 2 rather than a Type 50 as it
appears you're trying to do if your supplying the CheckCPU.exe
application inside your package. Custom Action types are listed at
http://msdn.microsoft.com/en-u
On Wed, 8 Sep 2010 10:39:24 +0100
"Nick Ball" 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 installed 4.0
it wanted
Hi Bruce,
The package that comes with Visual Studio (which I assume you are
currently using) does the same registry check. From the product.xml
file:
BTW, take a look in that file, and you'll see how to launch the package
specifying /q etc:
You'll find it here:
C:\Program Files
On Wed, 8 Sep 2010 11:17:29 +0100
"Nick Ball" 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:
>
>
> Key="HKLM\Software\Microsoft\NET Framework Setup\NDP\v4\Full"
> Value="Version" />
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 ''\file.dll'' -gg -scom -out
-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:
http://windows-installer-xml-wi
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 Setup\N
On Wed, 8 Sep 2010 14:21:58 +0200
Tobias S 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 detection for 4.0 versions:
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
ru
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
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:
http://download.microsoft.com/download/9/5/A/95A9616B-7A37-4AF6-BC36-D6EA96C8DAAE/dotNetFx40_Full_x86_x64.exe
"
DetectCondition="Netfx4FullVersion AND (NOT
VersionNT64 OR Netfx
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 Oper
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 platf
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 no
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 a
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 bes
heat.exe : warning HEAT5150 : Could not harvest data from a file that was
expect
ed to be a SelfReg DLL: , 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:
http://windows-installer-xml-wix-tools
I think that's an open bug in heat.
On Wed, Sep 8, 2010 at 12:02 PM, Tenzen wrote:
>
> heat.exe : warning HEAT5150 : Could not harvest data from a file that was
> expect
> ed to be a SelfReg DLL: , error: 193
>
> The same dll but compile as 32bit works fine.
>
> If I use 32bit harvest in 64bit i
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 ms
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 w
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
(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 number.Und
29 matches
Mail list logo
