On Thu, Mar 14, 2013 at 2:09 PM, chennam chatrapathi.chen...@gmail.comwrote:
Is their any property setting possibility of Heat not be executed for
every build?
I don't believe so. My first thought was to modify the Condition to execute
HeatDirectory only when the OutputFile does not Exists()
DoNotHarvest controls whether the WiX MSBuild scripts will automatically
harvest files in the project for you using the HeatProject task. If my
memory is correct, it is set to True because the current implementation
doesn't harvest something correctly. I think it had something to do with
Also note that unless you change the default behavior, then
'$(TargetName)' == '$(OutputName)'
So, I would change the OutputName property to whatever name you need.
--
Edwin
On Fri, Apr 5, 2013 at 5:54 AM, Rob Mensching r...@robmensching.com wrote:
Yeah, changing the TargetName should just
That character limit on paths is imposed by .NET. :-(
On Fri, May 3, 2013 at 10:56 AM, Marco Tognacci mark...@live.it wrote:
I have used HeatDirectory to harvest a folder with many subdirectories and
files, but Heat.exe report an error because the filepath of an item is
larger than 260 chars
See
http://damianblog.com/2008/02/21/configuring-http-namespace-reservations-on-vista-using-wix/
All of the custom actions in that post are important. Note where they are
scheduled to execute.
--
Edwin
On Fri, May 10, 2013 at 7:36 AM, Brownfield, Cory cbrownfi...@aeci.orgwrote:
To illustrate
On Mon, May 13, 2013 at 11:20 AM, John Cooper jocoo...@jackhenry.comwrote:
You can pass the server/instance pair to the Server attribute. I've never
tried this with SqlDatabase, but can you pass the server/instance,port?
I would expect server,port to work as well.
--
Edwin G. Castro
The custom action will execute before file copy if it is an immediate
custom action rather than deferred.
--
Edwin G. Castro
On Tue, May 28, 2013 at 7:05 AM, Pally Sandher pally.sand...@iesve.comwrote:
From your InstallExecuteSequence code it looks like the Custom Actions
should be called
My understanding is that a Bundle is processed by the burn engine.
ARP == Add/Remove Programs
On Fri, May 31, 2013 at 12:44 PM, Alain Forget afor...@cmu.edu wrote:
By burn, you mean what I'm referring to as the Bundle?
And by ARP, you mean Add/Remove Programs?
Just making sure I
Deferred custom actions must be scheduled between InstallInitialize and
InstallFinalize to execute within the installation transaction and thus
elevated.
Prefer to use
PermissionExhttp://wix.sourceforge.net/manual-wix3/util_xsd_permissionex.htminstead
of writing your own custom action.
On Wed, Jul 17, 2013 at 8:15 AM, Dana Epp d...@vulscan.com wrote:
CustomAction Id=RegisterApp BinaryKey=their-bho-registrator_exe
Execute
=deferred
ExeCommand='/install=[INSTALLFOLDER]$(var.Our.App.TargetFileName)
/privileges=admin /returnExitCode=false' Impersonate=yes /
One reason why
On Fri, Jul 19, 2013 at 8:35 AM, Chen, Jianxin jianxin.c...@bakerhughes.com
wrote:
“One reason why this CustomAction works from an elevated command prompt
but not from a non-elevated shell is that the CustomAction is scheduled
outside of the installation transaction (before InstallInitialize
The build engine for Visual Studio is MSBuild. In MSBuild environment
variables are accessed just like properties. The build event macros are
defined as properties wix2010.targets. That's where your name collision
comes in. One of the attributes that gets set on the Light MSBuild task is
On 8/27/13 10:05 AM, Skildum, Mathew wrote:
Here is an example of the build errors:
CustomAction.cs(4,17): error CS0234: The type or namespace name 'Deployment'
does not exist in the namespace 'Microsoft' (are you missing an assembly
refere
nce?)
CustomAction.cs(12,58): error CS0246:
On 8/27/13 11:03 AM, Skildum, Mathew wrote:
All hint paths are correct as everything build correctly in Visual Studio
(2010 and 2012). The only time it fails is when I use the 64 bit version of
MS Build.
Can you provide the reference XML from the project file? I assume you
have not modified
HintPath..\..\Assemblies\Powershell\System.Management.Automation.dll/HintPath
PrivateTrue/Private
/Reference
Reference Include=System.Windows.Forms /
Reference Include=Microsoft.Deployment.WindowsInstaller /
/ItemGroup
Mat Skildum
-Original Message-
From: Edwin
I'm highly suspect of the values for the Path, Depth and
AssignToProperty attributes in your DirectorySearch.
The example sent by John Cooper, replicated below for convenience,
didn't set AssignToProperty=no nor Depth=0.
Fragment
PropertyRef Id=INSTALLLOCATION /
Property
There must be a UIRef Id=WixUI_Advanced / somewhere in your project
OR in a wixlib you are referencing... You might try grep WixUI_Advanced
(or equivalent) on all the files in your project and all referenced WiX
projects.
--
Edwin G. Castro
On 8/29/13 3:34 PM, jo...@msli.com wrote:
Tracking the
destination. Since I cannot know from where IT will deploy our MSIs, I have
to figure it out on the
fly...
And it's still failing - son if someone has an idea for me to look at, I'd
appreciate it
Thanks,
Kai
On Thu, 29 Aug 2013 13:47:19 -0700, Edwin Castro wrote:
I'm highly suspect
I've had problems in the past with a service not starting as expected
because of missing dependencies but never a problem uninstalling the
service.
I don't see anything obviously wrong here. I checked the ServiceInstall
and ServiceControl documentation to double check syntax and everything
looked
On 9/18/13 1:57 PM, Alain Forget wrote:
Gaining knowledge on how code works is fine and has value, but at the end of
the day, people have primary tasks they're trying to get done and can't
always commit the time or effort into tangential secondary tasks.
I think it is clear that the WiX
I assume you are getting duplicate entries after you attempt an upgrade.
If so, how is $(var.Version) changing between upgrade attempts?
Be aware that Windows Installer only takes the first THREE parts of the
ProductVersion into consideration. ProductVersions 1.2.3.4 and 1.2.3.5
are the same
to the right path prior to the
FileRemove entries in the uninstall log, though.
I think your CA_SetCDrive custom action is scheduled too late. I thought
directories needed to be set prior to CostInitialize.
--
Edwin Castro
On 12/13/13, 3:07 PM, Markus Ewald wrote:
warning LGHT1076 : ICE69: Mismatched component reference. Entry
'ApplicationStartMenuShortcut' of the Shortcut table belongs to
component 'ApplicationShortcut'. However, the formatted string in
column 'Target' references file
On 12/13/13, 3:46 PM, Markus Ewald wrote:
On 12/14/2013 12:18 AM, Edwin Castro wrote:
On 12/13/13, 3:07 PM, Markus Ewald wrote:
warning LGHT1076 : ICE69: Mismatched component reference. Entry
'ApplicationStartMenuShortcut' of the Shortcut table belongs to
component
On 12/19/13, 5:31 PM, Gerry Reno wrote:
The relevant code section is:
Binary Id='CMDEXE' SourceFile='C:\WINDOWS\System32\cmd.exe' /
CustomAction Id='LaunchSetup' BinaryKey='CMDEXE'
Execute='deferred'
ExeCommand='/k [INSTALLDIR]/myprogram.exe' Return='asyncWait'
On 12/20/13, 9:46 AM, Gerry Reno wrote:
On 12/20/2013 10:44 AM, David Connet wrote:
From: Gerry Reno [mailto:gr...@verizon.net]
Binary Id='CMDEXE' SourceFile='C:\WINDOWS\System32\cmd.exe' /
I don't think that's legal. cmd.exe is not a redistributable file. You
can't include it
On 12/20/13, 9:49 AM, Gerry Reno wrote:
It's not a Windows program. It's a CUI program that you launch from cmd.exe
Which you can still more easily start directly. If you insist in
wrapping the call with cmd.exe then you MUST adhere to cmd.exe's funky
quotation rules.
Do it the easy way and
On 12/20/13, 10:27 AM, Gerry Reno wrote:
I not certain this will work. It might with something like a .bat file since
the system knows that .bat files are
executed by cmd.exe.
But what is there to tell the system that my exe requires being run by
cmd.exe?
Assuming that your exe is
Jacob,
You mentioned something interesting that I can't get to work. I tried
Chain
MsiPackage SourceFile=$(var.projectName.TargetPath)
MsiProperty Name=BUNDLEPROVIDERKEY Value=[WixBundleProviderKey]/
/MsiPackage
/Chain
But BUNDLEPROVIDERKEY is always empty in the msi log.
Should I
I have two custom action functions (A and B) that use LoadLibraryEx() to
load a DLL that already exists on the target system (NOT installed by my
MSI) and then proceeds to call a few functions in that DLL. My MSI is
installed by the WiX Standard Bootstrapper. These custom actions functions
in a
=BUNDLEPROVIDERKEY Value=[CMDLINE_BUNDLEPROVIDERKEY]
Execute=firstSequence /
...
Custom Action='SaveCmdLineBUNDLEPROVIDERKEY' Before='AppSearch'/
Custom Action='SetFromCmdLineBUNDLEPROVIDERKEY'
After='AppSearch'CMDLINE_BUNDLEPROVIDERKEY/Custom
-Original Message-
From: Edwin
The remarks at
http://wixtoolset.org/documentation/manual/v3/xsd/dependency/providerkey.html
say
This provider key is designed to persist throughout compatible upgrades so
that dependent bundles do not have to be reinstalled and *will not prevent
your product from being upgraded*. If this
Is there a way to predict the cache location for my bootstrapper so I can
pass it to my MSI in public property? I need to set a registry value with
the uninstall command for my bootstrapper (similar to the ARP
UninstallCommand) but I'm having a hard time guessing the cache location
for the
I'd like to install or uninstall an ExePackage whenever an MsiPackage is
selected for install or uninstall.
Details:
* ExePackage must be installed whenever MsiPackage is selected for install.
* ExePackage must be installed before MsiPackage is installed.
* ExePackage must be uninstalled whenever
I’m trying to recache one of a number of packages before
RemoveExistingProducts. My custom action extracts the new package from the
Binary table, then attempts to MsiOpenDatabase() to update the new
package’s ProductCode and ProductVersion to avoid needing a new package for
each instance we’re
I'll provide more details. I inherited the installer codebase for a product
that has released twice (A, B) and was almost ready to release again (C).
Releases A and B have poorly written custom actions that cause them to fail
occasionally (say 5% of the time) while they are getting uninstalled as
I work at a security company and one of our products provides additional
protection beyond built-in access controls in Windows. The end result of
all of this additional protection is that the installer I'm maintaining
cannot simply use some of the built-in tables/actions in Windows Installer
It occurs to me that I don't want to change the ExePackage's request state.
Rather I want to change it's action state to the same action state selected
for the MsiPackage.
Is there a way to get and set package action state?
On Thu, Apr 2, 2015 at 2:14 PM, Edwin Castro egca...@gmail.com wrote
Unfortunately, you'll need to address the duplication yourself. The MSI
database schema doesn't allow for primary keys to be duplicated.
Years ago, when I was using HarvestDirectory, I wrote some XSLT transforms
to either remove duplicates or modify/set File/@Id to avoid duplication. I
also had
You could try setting the HarvestDirectoryAdditionalOptions property in
your *.wixproj file. Something like this:
PropertyGroup
HarvestDirectoryAdditionalOptions-svb6/HarvestDirectoryAdditionalOptions
/PropertyGroup
--
Edwin G. Castro
On Tue, Jun 9, 2015 at 2:18 PM, Brad Woodfiel
I'm trying to implement same version upgrades in our bootstrapper. We build
our product in one build process and later create the installers in a
second package process. This allows us to repackage our product when fixing
installer changes that do not affect the product in any other way. We do
not
not.
_
Short replies here. Complete answers over there:
http://www.firegiant.com/
-Original Message-
From: Edwin Castro [mailto:egca...@gmail.com]
Sent: Tuesday, June 23, 2015 1:58 PM
To: General discussion for Windows Installer XML toolset
My ExePackage gets uninstalled during upgrades and I'd like to only
uninstall during an actual uninstall. Any suggestions on how I might go
about doing this? I was hoping I could do something in my bafunctions.dll
but I'm hitting a wall in my brainstorming.
My bundle consists of the following:
*
Is there a way to get the timestamp used in the WixBundleLog? I'd like to
use it as part of the log filename in the InstallCommand and/or
UninstallCommand of the ExePackages in my Bundle.
--
Edwin G. Castro
--
I forgot to mention that I'm using WiX 3.8.1128.0.
On Thu, Jul 2, 2015 at 5:07 PM, Edwin Castro egca...@gmail.com wrote:
Our bundle fails to install when our product is built with bullseye for
code coverage. The bundle log is not created. Instead
Setup_timestamp_Failed.txt is created
Our bundle fails to install when our product is built with bullseye for
code coverage. The bundle log is not created. Instead
Setup_timestamp_Failed.txt is created and contains the following:
[04AC:0744][2015-07-02T14:59:01]e000: Error 0x80070057: Failed to
parse @Code value: -1
I see the fix in wix39rtm.
WiX 3.9 and Bullseye appear to work better together. We're going to
recommend upgrading to WiX 3.9.
On Fri, Jul 3, 2015 at 8:54 AM, Rob Mensching r...@firegiant.com wrote:
I was looking at HEAD. Bug fix in WiX v3.9 or v3.10?
I'm using WixStandardBootstrapperApplication.HyperlinkSidebarLicense
in my burn bundle. I have localized strings for a few languages. I'm
looking into a bug reported against our Spanish localization. The
expectation is that when the Alt + A is pressed, the focus would be
received by the EULA
I know this is now a WiX specific question. Please point me to a better
place to ask this.
I have a custom action that launches an exe. The custom action uses
MsiLogFileLocation as a base to construct a log file path for the exe
command line. This all works great during install and uninstall
I was trying to use RegDelete from the dutil library and I noticed my
32-bit key did not get deleted on a 64-bit system. I think the problem is
the following RegOpen call
hr = RegOpen(khRoot, wzSubKey, KEY_READ, hkKey);
if (E_FILENOTFOUND == hr)
{
ExitFunction1(hr = S_OK);
}
Since
I can't use semi-custom-actions for this particular piece of work because I
need to call an API to get permission to create, delete, or modify these
particular registry keys. I work at a security company where they have
implemented additional security features through drivers that disallow
normal
I have a bundle that I have successfully installed. When I try to uninstall
I get the following:
[0E54:03D0][2015-07-13T15:34:03]i300: Apply begin
[07F0:0814][2015-07-13T15:34:03]i360: Creating a system restore point.
[07F0:0814][2015-07-13T15:34:10]i361: Created a system restore point.
I'm trying to use CabExtract from cabutil.h (WiX v3.9) but I always get hr
== 0x80070003 (The system cannot find the path specified).
My code is equivalent to the following:
hr = CabInitialize(false);
hr = PathCreateTempDirectory(NULL, Lextract, 1, tempDir);
hr = PathConcat(tempDir, Lfile.cab,
, then the fix is to ensure the directory
portion of wzPath exists before calling CreateFileW.
On Thu, Jul 9, 2015 at 10:34 PM, Edwin Castro egca...@gmail.com wrote:
I'm trying to use CabExtract from cabutil.h (WiX v3.9) but I always get hr
== 0x80070003 (The system cannot find the path specified
54 matches
Mail list logo
