Hello,
I'm trying to understand how MSI does decide if to use the cached package or
the original package I start from.
Therefore I installed one of my packages with version 1.0.0.0 . After that I
opened the package with Orca and change the product version property to 2.0.0.0
and gave the
Hi everyone,
I have looked at the constructor for DetectRelatedMsiPackageEventArgs and I
noticed that it requires a Long for the version number. If I try to create a
new instance of DetectRelatedMsiPackageEventArgs in order to change the
Operation I cannot do this because args.Version is not
How to pass .ini configuration file to InstallCommand for a
SQLEXPR_x64_ENU.exe ExePackage element.
ExePackage Id=SQLExpressx64
Name=SQLEXPR_x64_ENU.exe
DisplayName=Microsoft® SQL Server® 2008 R2 SP2 - Express
Edition x64
Here is the short version of what I am trying to accomplish with Burn. I have a
chainer that is responsible for installing up to 12 different products, plus
prerequisites. If there is a hotfix available for one of those products, then
there will be a new msi for that product and it will be
How about setting an MSIProperty?
Bundle ...
Variable Name=IniPath Type=string bal:Overridable=yes Value=
Persisted=yes/
MsiPackage ...
MsiProperty Name=INIPATH Value=[IniPath]/
/MsiPackage
/Bundle
Using this method you can also change the path from within your bootstrapper
It doesn't help. Here it is ExePackage Element and I'm trying to execute
something similar to command line installation.
For example, in cmd.exe we can do: *SQLEXPR_x64_ENU.exe
/ConfigurationFile=c:\SomePath\SomeConfigFile.ini*
This is very simple passing of commandline installation arguments.
Take a look at .\test\src\UnitTests\dutil\IniUtilTest.cpp.
I think you are missing:
static HRESULT StandardIniFormat(__inout INI_HANDLE iniHandle)
{
HRESULT hr = S_OK;
hr = IniSetOpenTag(iniHandle, L[, L]);
ExitOnFailure(hr, Failed to set open
You should still be able to use the Variable element with the variable being
placed with [Variable], but I haven't tested this and don't have time right now
for a test to give you a better example.
Regards,
Chris
-Original Message-
From: Jerome [mailto:jero2r...@gmail.com]
Sent:
Unless you also change the Upgrade table when you're poking around in your MSI
with Orca, it's not going to see the 2.0.0.0 as a new package if you didn't
add a MajorUpgrade element when you authored your package.
See
Hi,
As you know and as posted in the article below, WiX v3 has moved to .NET
Framework 2.0 while WiX v2 will stay on .NET Framework 1.1 SP1.
http://robmensching.com/blog/posts/2007/12/7/wix-v3-on-the-.net-framework-2.0-eminent
However, I did not find much information on the plan of .NET
You may not have changed the PackageCode - Windows Installer is
sensitive to this as well as the ProductCode.
---
Phil Wilson
On Tue, Apr 8, 2014 at 9:32 AM, Pally Sandher pally.sand...@iesve.com wrote:
Unless you also change the Upgrade table when you're poking around in your
MSI
I need a path to SDK framework in post-build event.
Standard VisualStudio projects support $(FrameworkSDKDir) macro but WiX 3.7
does not.
Does WiX 3.8 bring support for this macro ?
If not, what's the best way to get that path (aside from hard-coding) ?
Thank you
I don't think this is a wix issue. When I build Wix toolset 3.8 this
variable is defined.
I think it relates to the version of VS, Windows SDK, and .Net being used.
I'm not sure what you are expecting $(FrameworkSDKDir) to point to in a
.wixproj. Which version of the framework? There is no clear answer to this
question within the context of a WiX project, because WiX projects do not
target .NET Framework versions and do not use the .NET Framework SDK.
Have you tried running the application without going through the shortcuts?
It is possible that the application may be crashing, and your machine may be
configured to go straight to the debugger when a crash occurs. Usually when
this happens, something is logged in the Application Event Log, so
To add to this:
The only time the .NET Frameworks are ever targeted in a WiX Project
is usually 1 of 2 reasons:
1. An install condition is Tested to ensure the target machine has the
Required Version installed for your application.
2. If not installed, the Burn Bootstrap Engine will install
Isn't configruationfile case sensitive?
I have run it like this from command line.
SQLEXPRWT_x64_ENU.exe
/CONFIGURATIONFILE=C:\somepath\anotherpath\ConfigurationFile.INI
If you use that don't forget to replace with quot;
You might also want to make sure your configuration file looks like
17 matches
Mail list logo
