[WiX-users] Localization and acceleration key combinations in WixStandardBootstrapperApplication

[Edwin Castro]

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 checkbox and it would become selected. Instead,
the EULA checkbox receives focus but it never becomes selected. The
localized string begins as

&Acepto ...

I was trying to read the burn source code to understand how the
acceleration key combination is setup based on what exists in the
localized .wxl files but I have to admit I'm a little lost. It appears
to me that burn doesn't parse the strings at all so that Windows API
itself sets up the acceleration key combo itself. Is that accurate? If
so, then I assume I'm doing something wrong but I don't know what it
might be.

The acceleration key for English works as expected and it begins as

I &agree ...

Is this simply a case sensitivity issue? I don't think so as I thought
I tried using Alt + Shift + A with no change.

-- 
Edwin G. Castro

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Possible Bug: RegDelete does not work properly with REG_KEY_32BIT on a 64-bit system

[Edwin Castro]

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 interactions with certain resources. Otherwise, I would totally use
the semi-custom-action approach. I use it right now to add rows to the
RemoveFile table depending on whether we're uninstalling for an upgrade or
not.

In any case, RegDelete appears broken to me. At a minimum, the bitness
should be incorporated into the RegOpen call. Should I file a bug to track?


On Thu, Jul 16, 2015 at 7:01 AM, Phill Hogland  wrote:

> FYI - I just implemented a  semi-custom
>    action
> using a
> similar implementation as I found in the WixGamingExtension which calls
> WcaAddTempRecord on the Registry table, to allow MSI to manage my registry
> change.  The CA code (specifically the registry path) is agnostic to
> WoW6432Node so that the CA can be built for either Win32 or x64 and used in
> either a x86 or x64 MSI.  I only needed to set Component /@Win64="no" and
> MSI handles the redirection.
>
> The MSI packages are also built using the InstallerPlatform MSBuild
> property
> to set the bitness of the MSI.  For most of the Components I never set
> Win64, but for this registry key setting Win64="no" was needed to get MSI
> to
> redirect the the registry hive.
>
>
>
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Possible-Bug-RegDelete-does-not-work-properly-with-REG-KEY-32BIT-on-a-64-bit-system-tp7600893p7600896.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> --
> Don't Limit Your Business. Reach for the Cloud.
> GigeNET's Cloud Solutions provide you with the tools and support that
> you need to offload your IT needs and focus on growing your business.
> Configured For All Businesses. Start Your Cloud Today.
> https://www.gigenetcloud.com/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>



-- 
Edwin G. Castro
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Possible Bug: RegDelete does not work properly with REG_KEY_32BIT on a 64-bit system

[Edwin Castro]

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 KEY_WOW64_32KEY is not specified then RegOpen checks the 64-bit hive,
doesn't find the key, and exits RegDelete.

In other words, I think RegDelete only works with REG_KEY_DEFAULT!

-- 
Edwin G. Castro
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] RemoveExistingProducts does not set MsiLogFileLocation

[Edwin Castro]

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 because my
bundle ensures that a log is always created and I'm targeting Windows Vista
or greater with Windows Installer 4.0 or greater.

During an upgrade I see that MsiLogFileLocation is set in the context of
the upgrade msi but during the execution of RemoveExistingProducts I don't
see MsiLogFileLocation set and this causes my uninstall custom action to
fail because I'm not constructing a proper path for the log command line
argument.

I expected that MsiLogFileLocation would be automatically set by
RemoveExistingProducts when uninstalling related products but that
assumption appears to be incorrect.

Does anybody have any suggestions on how I might pass the value of
MsiLogFileLocation to the uninstalling msi to produce the correct log file?

The exe in question does not write the contents of this log to standard
output so I can't use CAQuietExec to capture the log.

-- 
Edwin G. Castro
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Why Does Bundle Prompt For Source During Uninstall?

[Edwin Castro]

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.
[0E54:01C4][2015-07-13T15:34:10]w341: Prompt for source of container:
WixAttachedContainer, path: C:\Original\path\to\bundle\setup.exe
[0E54:01C4][2015-07-13T15:34:10]e054: Failed to resolve source for
file: C:\Original\path\to\bundle\setup.exe, error: 0x80070643.
[0E54:01C4][2015-07-13T15:34:10]e000: Error 0x80070643: Failed while
prompting for source (original path 'C:\Original\path\to\bundle\setup.exe').
[0E54:01C4][2015-07-13T15:34:10]e311: Failed to acquire container:
WixAttachedContainer to working path:
C:\Windows\TEMP\{e2007576-a648-4b3f-8e4d-eccd898e4591}\75A375A2F5B5EE0C8914C4790878E0D2772E4838,
error: 0x80070643.
[0E54:03D0][2015-07-13T15:34:10]e000: Error 0x80070643: Failed while
caching, aborting execution.
[0E54:03D0][2015-07-13T15:34:10]i399: Apply complete, result: 0x80070643,
restart: None, ba requested restart:  No
[0E54:03D0][2015-07-13T15:34:11]i500: Shutting down, exit code: 0x643

I checked C:\ProgramData\Package Cache to make sure my bundle was still
cached (it was).

Under what circumstances does the burn engine try to resolve the original
bundle location?

I was under the impression that the bundle was cached at
C:\ProgramData\Package Cache to avoid needing the original source to be
available.

-- 
Edwin G. Castro
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] CabExtract returns 0x80070003

[Edwin Castro]

I think I know what the problem is.

The cab file I'm trying to extract has directories inside. I think when
CabExtractCallback is called for the first file we get wzPath pointing to a
string like C:\Users\user\AppData\Local\Temp\extract\subdir\file1.txt
and the call to CreateFileW fails because
C:\Users\user\AppData\Local\Temp\extract\subdir does not exist yet. I think
this results in GetLastWin32Error returning ERROR_PATH_NOT_FOUND back in
CabOperation which converts the error into 0x80070003 which then gets
returned to CabExtract and finally back to me.

If my guess above is correct, 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  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).
>
> My code is equivalent to the following:
>
> hr = CabInitialize(false);
>
> hr = PathCreateTempDirectory(NULL, L"extract", 1, &tempDir);
>
> hr = PathConcat(tempDir, L"file.cab", &cabPath);
>
> hr = StrAllocString(&extractDir, tempDir, 0):
>
> hr = PathBackslashTerminate(&extractDir);
>
> hr = CabExtract(cabPath, L"*", extractDir, NULL, NULL, 0);
>
> CabUninitialize();
>
> I see the paths I expect to see when I log cabPath and extrtactDir:
>
> cabPath = C:\Users\user\AppData\Local\Temp\extract\file.cab
> extractDir = C:\Users\user\AppData\Local\Temp\extract\
>
> I'm at a loss because I can't figure out what CabExtract is failing to
> find.
>
> Am I doing something obviously wrong?
>
> Any suggestions as to how I might go about finding out what CabExtract is
> actually complaining about?
>
> --
> Edwin G. Castro
>



-- 
Edwin G. Castro
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] CabExtract returns 0x80070003

[Edwin Castro]

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, L"extract", 1, &tempDir);

hr = PathConcat(tempDir, L"file.cab", &cabPath);

hr = StrAllocString(&extractDir, tempDir, 0):

hr = PathBackslashTerminate(&extractDir);

hr = CabExtract(cabPath, L"*", extractDir, NULL, NULL, 0);

CabUninitialize();

I see the paths I expect to see when I log cabPath and extrtactDir:

cabPath = C:\Users\user\AppData\Local\Temp\extract\file.cab
extractDir = C:\Users\user\AppData\Local\Temp\extract\

I'm at a loss because I can't figure out what CabExtract is failing to find.

Am I doing something obviously wrong?

Any suggestions as to how I might go about finding out what CabExtract is
actually complaining about?

-- 
Edwin G. Castro
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Error 0x80070057: Failed to parse @Code value: -1

[Edwin Castro]

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  wrote:

> I was looking at HEAD. Bug fix in WiX v3.9 or v3.10?
>
> ___
>  FireGiant  |  Dedicated support for the WiX toolset  |
> http://www.firegiant.com/
>
> -Original Message-
> From: CastroAlicea, Edwin [mailto:edwin_castroali...@mcafee.com]
> Sent: Thursday, July 2, 2015 5:42 PM
> To: General discussion about the WiX toolset.
> Subject: Re: [WiX-users] Error 0x80070057: Failed to parse @Code value: -1
>
> Ok, that's really weird. That's not what I see at all.
>
> ExitCodeInfo.cs:38:this.Code = value.ToString();
>
> I'm looking at wix38rtm.
>
> Does WiX 3.8.1128.0 not correspond to wix38rtm?
>
> --
> Edwin G. Castro
>
>
> --
> Don't Limit Your Business. Reach for the Cloud.
> GigeNET's Cloud Solutions provide you with the tools and support that
> you need to offload your IT needs and focus on growing your business.
> Configured For All Businesses. Start Your Cloud Today.
> https://www.gigenetcloud.com/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>



-- 
Edwin G. Castro
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Error 0x80070057: Failed to parse @Code value: -1

[Edwin Castro]

Ok, that's really weird. That's not what I see at all.



ExitCodeInfo.cs:38:this.Code = value.ToString();



I'm looking at wix38rtm.



Does WiX 3.8.1128.0 not correspond to wix38rtm?

On Thu, Jul 2, 2015 at 5:18 PM, Rob Mensching  wrote:

> ExitCodeInfo.cs:38:this.Code =
> unchecked((uint)value).ToString();
> _
>  Short replies here. Complete answers over there:
> http://www.firegiant.com/
>
>
> -----Original Message-
> From: Edwin Castro [mailto:egca...@gmail.com]
> Sent: Thursday, July 2, 2015 5:08 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: [WiX-users] Error 0x80070057: Failed to parse @Code value: -1
>
> 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
> [04AC:0744][2015-07-02T14:59:01]e000: Error 0x80070057: Failed to parse
> EXE package.
> [04AC:0744][2015-07-02T14:59:01]e000: Error 0x80070057: Failed to parse
> packages.
> [04AC:0744][2015-07-02T14:59:01]e000: Error 0x80070057: Failed to load
> manifest.
> [04AC:0744][2015-07-02T14:59:01]e000: Error 0x80070057: Failed to
> initialize core.
>
>
> Burn is failing to parse manifest.xml because it finds an ExitCode element
> with Code="-1"
>
> 
>
> I compared the bad manifest.xml to a good manifest.xml from a normal,
> non-bullseye bundle which has the following ExitCode element:
>
> 
>
> I think something performs a conversion from int to unsigned int under
> normal conditions and that thing is somehow getting interfered with when we
> have bullseye enabled. But I can't figure out what that thing is.
>
> I've looked the wixobj files created by candle and they appear to use -1:
>
> 
>   
> VSCore32
> -1
> error
>   
> 
>
> The ExitCodeInfo constructor casts to an int before converting the value
> to a string and stored in the Code property. As far as I can tell the Code
> string is passed to XmlTextWriter.WriteAttributeString without further
> modification in Binder.CreateBurnManifest. I don't see where a signed int
> gets converted to unsigned when it gets written to manifest.xml.
>
> Field.Parse calls Convert.ToInt64 on the value read from the wixobj file
> and then casts it to an int. I think a "-1" would still parse as -1 (signed
> integer) with this code.
>
> I'm still no closer to figuring out how I get Code="4294967295" on good
> builds. The code I read suggests I should get Code="-1" which clearly
> doesn't work.
>
> What am I missing?
>
> --
> Edwin G. Castro
>
>
> --
> Don't Limit Your Business. Reach for the Cloud.
> GigeNET's Cloud Solutions provide you with the tools and support that
> you need to offload your IT needs and focus on growing your business.
> Configured For All Businesses. Start Your Cloud Today.
> https://www.gigenetcloud.com/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>



-- 
Edwin G. Castro
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Error 0x80070057: Failed to parse @Code value: -1

[Edwin Castro]

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
[04AC:0744][2015-07-02T14:59:01]e000: Error 0x80070057: Failed to
parse EXE package.
[04AC:0744][2015-07-02T14:59:01]e000: Error 0x80070057: Failed to
parse packages.
[04AC:0744][2015-07-02T14:59:01]e000: Error 0x80070057: Failed to load manifest.
[04AC:0744][2015-07-02T14:59:01]e000: Error 0x80070057: Failed to
initialize core.


Burn is failing to parse manifest.xml because it finds an ExitCode element
with Code="-1"



I compared the bad manifest.xml to a good manifest.xml from a normal,
non-bullseye bundle which has the following ExitCode element:



I think something performs a conversion from int to unsigned int under
normal conditions and that thing is somehow getting interfered with when we
have bullseye enabled. But I can't figure out what that thing is.

I've looked the wixobj files created by candle and they appear to use -1:


  
VSCore32
-1
error
  


The ExitCodeInfo constructor casts to an int before converting the value to
a string and stored in the Code property. As far as I can tell the Code
string is passed to XmlTextWriter.WriteAttributeString without further
modification in Binder.CreateBurnManifest. I don't see where a signed int
gets converted to unsigned when it gets written to manifest.xml.

Field.Parse calls Convert.ToInt64 on the value read from the wixobj file
and then casts it to an int. I think a "-1" would still parse as -1 (signed
integer) with this code.

I'm still no closer to figuring out how I get Code="4294967295" on good
builds. The code I read suggests I should get Code="-1" which clearly
doesn't work.

What am I missing?

-- 
Edwin G. Castro
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Error 0x80070057: Failed to parse @Code value: -1

[Edwin 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  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 and contains the following:
>
> [04AC:0744][2015-07-02T14:59:01]e000: Error 0x80070057: Failed to parse @Code 
> value: -1
> [04AC:0744][2015-07-02T14:59:01]e000: Error 0x80070057: Failed to parse EXE 
> package.
> [04AC:0744][2015-07-02T14:59:01]e000: Error 0x80070057: Failed to parse 
> packages.
> [04AC:0744][2015-07-02T14:59:01]e000: Error 0x80070057: Failed to load 
> manifest.
> [04AC:0744][2015-07-02T14:59:01]e000: Error 0x80070057: Failed to initialize 
> core.
>
>
> Burn is failing to parse manifest.xml because it finds an ExitCode element
> with Code="-1"
>
> 
>
> I compared the bad manifest.xml to a good manifest.xml from a normal,
> non-bullseye bundle which has the following ExitCode element:
>
> 
>
> I think something performs a conversion from int to unsigned int under
> normal conditions and that thing is somehow getting interfered with when we
> have bullseye enabled. But I can't figure out what that thing is.
>
> I've looked the wixobj files created by candle and they appear to use -1:
>
> 
>   
> VSCore32
> -1
> error
>   
> 
>
> The ExitCodeInfo constructor casts to an int before converting the value
> to a string and stored in the Code property. As far as I can tell the Code
> string is passed to XmlTextWriter.WriteAttributeString without further
> modification in Binder.CreateBurnManifest. I don't see where a signed int
> gets converted to unsigned when it gets written to manifest.xml.
>
> Field.Parse calls Convert.ToInt64 on the value read from the wixobj file
> and then casts it to an int. I think a "-1" would still parse as -1 (signed
> integer) with this code.
>
> I'm still no closer to figuring out how I get Code="4294967295" on good
> builds. The code I read suggests I should get Code="-1" which clearly
> doesn't work.
>
> What am I missing?
>
> --
> Edwin G. Castro
>



-- 
Edwin G. Castro
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] How to Uninstall ExePackage Only During Uninstall

[Edwin Castro]

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:
* A few pre-requisites (A) that will remain on the system after uninstall
* A pre-requisite ExePackage (B) that will be uninstalled only when my
product MSI is uninstalled
* My product MSI (C)

The package order in the chain is as follows:


  
  
  


B is an ExePackage that has DetectCondition and InstallCondition set.

During an install or uninstall the packages run in the expected order:
* Install: A, B, C
* Uninstall: C, B

However, during an upgrade I get an undesired order. A and B are not
upgraded because they are detected as already existing at the correct
version. C is upgraded to the new version. The last thing the new bundle
does is to uninstall the related bundle. In the log for the related bundle
uninstall I see that B is marked as Obsolete so it is uncached and
unregistered. BUT C is detected as Present and is thus selected to be
uninstalled.

* Upgrade: C, UninstallRelatedBundle(B)

I'd like to only uninstall B when C is uninstalled. I think I have my
DetectCondition setup properly to install B when the new bundle contains a
new version of B. However, I never want to uninstall B during an upgrade. B
should be uninstalled only during an uninstall.

-- 
Edwin G. Castro
--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical & virtual servers, alerts via email & sms 
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to Allow Same Version Upgrades in Bundles

[Edwin Castro]

Conversely, is there a way to DISALLOW same version upgrades in bundles
using wixstdba?

I'm trying to figure out what my options are.

On Tue, Jun 23, 2015 at 2:32 PM, Rob Mensching  wrote:

> Any BA can choose to allow same version upgrades. The wixstdba does 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.
> Subject: [WiX-users] How to Allow Same Version Upgrades in Bundles
>
> 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 change our versions when we repackage.
>
> I found that instead of upgrading the existing bundle installation, the
> new bundle is installed separately resulting in two ARP entries. I found
> feature http://wixtoolset.org/issues/3746/ requesting that burn support
> same version upgrades. Feature 3746 is listed as Untriaged and had been
> opened for a very long time. I expect this means an official fix is not
> coming soon.
>
> Are there any workarounds for supporting same version upgrades in bundles?
>
> --
> Edwin G. Castro
>
>
> --
> Monitor 25 network devices or servers for free with OpManager!
> OpManager is web-based network management software that monitors
> network devices and physical & virtual servers, alerts via email & sms
> for fault. Monitor 25 devices for free with no restriction. Download now
> http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>



-- 
Edwin G. Castro
--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical & virtual servers, alerts via email & sms 
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] How to Allow Same Version Upgrades in Bundles

[Edwin Castro]

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 change our versions when we repackage.

I found that instead of upgrading the existing bundle installation, the new
bundle is installed separately resulting in two ARP entries. I found
feature http://wixtoolset.org/issues/3746/ requesting that burn support
same version upgrades. Feature 3746 is listed as Untriaged and had been
opened for a very long time. I expect this means an official fix is not
coming soon.

Are there any workarounds for supporting same version upgrades in bundles?

-- 
Edwin G. Castro
--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical & virtual servers, alerts via email & sms 
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Getting WixBundleLog Timestamp

[Edwin Castro]

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
--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] HavestDirectory -svb6

[Edwin Castro]

You could try setting the HarvestDirectoryAdditionalOptions property in
your *.wixproj file. Something like this:



-svb6



-- 
Edwin G. Castro

On Tue, Jun 9, 2015 at 2:18 PM, Brad Woodfiel  wrote:

> With the Heat command there is an option '-svb6' for when dealing with dll
> and ocx files created in VB6.  Is there a similar option for
> the HeatDirectory tasks?
>
> Thx
>
> --
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Duplicate files from multiple locations

[Edwin Castro]

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 to modify my build to automatically apply the XSLT transforms to
the HarvestDirectory generated wix source.



-- 
Edwin G. Castro

On Tue, Jun 9, 2015 at 8:23 AM, Brad Woodfiel  wrote:

> Quick background on what I'm working on:
>
> I am creating a new WIX installer after years of using Install Shield for
> multiple of our PowerBuilder applications.   The PB apps use files from our
> .Net applications and control libraries, so therefore are receiving files
> from multiple locations. These external apps and libraries collections are
> built through TFS and also share files between them.  We also have an
> internal TFS plugin to retrieve the output from these external builds and
> drop them to the installer source locations before the build is executed.
>
> Because the internal and external files are under regular modification I've
> been setting up the WIX installer to use Harvest tasks (File and Directory)
> to automatically retrieve them from the installer build source location.
>
> The issue that I am currently running into is with the duplicate files in
> the various files and the HarvestDirectory is causing "duplicate symbol"
> errors.
>
> "Error 8 Duplicate symbol 'Component:cmp4F01576ED2586AF9D280A187DB1A1557'
> found. This typically means that an Id is duplicated. Check to make sure
> all your identifiers of a given type (File, Component, Feature) are unique.
> "
>
> Is there a way to get around the duplicate files or allow the duplication
> since they are going to the same location.
>
> Thx
>
> --
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Modifying new msi package prior to recache in a custom action

[Edwin Castro]

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
part of an upgrade to a newer version (C). We want to fix these issues in C
and deliver it as a replacement for A and B during an upgrade.

Our original plan was to build C three times. First build would have
Release A's ProductCode and ProductVersion (let's call it A' ). Second
build would have Release B's ProductCode and ProductVersion (let's call it
B' ). Third build would have a new ProductCode and ProductVersion for
Release C (let's call this C' ). C' would have A' and B' in the Binary
table and we wrote an immediate custom action to extract and recache A' or
B' when upgrading from A or B.

The we realized that we need to fix pre-releases for C (lets call them C*
because there are many). We determined our original plan does not scale
well as we'd need a C' for each C* pre-release.

The only difference between A', B', and all C' packages would be
ProductCode and ProductVersion. Thus we want to build a single C' package
to include in the Binary table. In our custom action we want to extract
that single C' package to disk, modify the package's ProductCode and
ProductVersion to what is currently installed, and recache the package.

After I have extracted the C' package to disk I try the following set of
calls (error handling omitted):

PMSIHANDLE hDatabase = NULL;

WcaLog("After previous function call");

WcaLog("Before MsiOpenDatabase(%ls)", wzFileName);
er = MsiOpenDatabase(wzFileName, MSIDBOPEN_DIRECT, &hDatabase);
WcaLog("After MsiOpenDatabase");

The behavior I see in the log is

RecacheExistingProduct:  After previous function call
MSI (s) (D4:84) [14:23:56:565]: Leaked MSIHANDLE (71) of type 790541 for
thread 1380
MSI (s) (D4:84) [14:23:56:565]: Note: 1: 2769 2: RecacheExistingProduct 3:
1
MSI (s) (D4:84) [14:23:56:565]: Note: 1: 2205 2:  3: Error
MSI (s) (D4:84) [14:23:56:565]: Note: 1: 2228 2:  3: Error 4: SELECT
`Message` FROM `Error` WHERE `Error` = 2769
RecacheExistingProduct:  Before MsiOpenDatabase(path\to\C'\package\on\disk)

FYI, I also tried MSIDBOPEN_TRANSACT but saw no difference in the log. The
wzFileName variable contains the path to the C' package I just extracted
from the Binary table.

I read online that type 790541 indicates a database MSIHANDLE is getting
leaked. I expected that if MsiOpenDatabase was returning an error that was
causing my custom action to exit early, then I would see log messages in
the cleanup code but those log messages do not show up. Instead the last
message that shows up in the log is the message logged BEFORE
MsiOpenDatabase is called AND that message appears after MSI logged the
leaked MSIHANDLE. To me this seems to indicate something similar to a
SEGFAULT occurred causing the immediate termination of the custom action.

The MSDN documentation on MsiOpenDatabase at
https://msdn.microsoft.com/en-us/library/aa370338.aspx says

"Because MsiOpenDatabase initiates database access, it cannot be used with
a running installation."

Based on the behavior I see in the log I'm interpreting the quote above to
mean that I cannot call MsiOpenDatabase in a custom action because custom
actions execute within a running installation.

I'm looking for confirmation that my interpretation above is correct. I'm
having a hard time explaining why I don't see any of the error handling
code logging as I expect it to do.

I was already using PMSIHANDLE and I know that wzFileName has valid content
because the Before MsiOpenDatabase message contains the correct path
information.

I think my only option is to move this custom action into it's own
executable so it is not executing in a running installation. Is this
correct?

--
Edwin G. Castro

On Tue, May 5, 2015 at 5:41 PM, Matthew Bobowski 
wrote:

> Edwin,
>
> No, you may use MsiOpenDatabase, but you need to be careful when and how
> you use it. For C++, try using PMSIHANDLE. Otherwise for C or other stdcall
> access, be sure to close the handle in your custom action with
> MsiCloseHandle. However, it might help to know what you're trying to
> accomplish at a high level, before commenting on the use this function.
>
>
> -Matt
>
> > Date: Tue, 5 May 2015 16:50:34 -0700
> > From: egca...@gmail.com
> > To: wix-users@lists.sourceforge.net
> > Subject: [WiX-users] Modifying new msi package prior to recache in a
> custom   action
> >
> > 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 trying to recache.
> >
> > I’m getting Leaked MSIHANDLE messages like the following
> >
> > MSI (s) 

[WiX-users] Modifying new msi package prior to recache in a custom action

[Edwin Castro]

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 trying to recache.

I’m getting Leaked MSIHANDLE messages like the following

MSI (s) (D4:84) [14:23:56:565]: Leaked MSIHANDLE (71) of type 790541 for
thread 1380

And it appears that the custom action is terminating immediately at the
MsiOpenDatabase() call site as no other custom action code appears to
execute after.

I read in https://msdn.microsoft.com/en-us/library/aa370338.aspx that
“Because MsiOpenDatabase initiates database access, it cannot be used with
a running installation.” Does this mean that I cannot use MsiOpenDatabase()
from a custom action and that I’ll need an external executable to run from
my bundle instead of recaching in a custom action?


-- 
Edwin G. Castro
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Customizing Standard Actions

[Edwin Castro]

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
because I need to request and get access.

The current version of the installer has custom actions to get access and
modify the system accordingly. Unfortunately, the resources
modified/created/etc are hard coded in the custom actions and not
associated with components, etc. I think there's an opportunity to make the
custom actions more robust by rewriting them as proper data-driven custom
actions but that would require re-implementing standard actions for
registry and services.

I'd really like to avoid re-implementing WriteRegistryValues,
DeleteRegistryValues, InstallServices, DeleteServices, StartServices,
StopServices standard actions just to request access from our protection
module. Using WriteRegistryValues as an example, could I implement a custom
action to acquire all the protection handles I need, then run
WriteRegistryValues action, and then in another custom action close all the
protection handles. For this to work, I'd need to somehow pass the handles
from the first custom action to the last custom action.

Something like

* SchedAcquireProtectionHandles - immediate CA that reads tables and
determines which resources require protection handles, sets
CustomActionData for ExecAcquireProtectionHandles and schedules
ExecAcquireProtectionHandles.
* ExecAcquireProtectionHandles - deferred CA that acquires protection
handles for resources listed in CustomActionData, handles are passed to
ExecReleaseProtectionHandles (magic?)
* ExecReleaseProtectionHandles - deferred CA that release protection
handles acquired by ExecAcquireProtectionHandles
* SchedAcquireProtectionHandles is scheduled before WriteRegistryValues
* ExecAcquireProtectionHandles is scheduled after WriteRegistryValues

Logically, there would also be a rollback CA to release the protection
handles in case of failure.

Is something like this feasible? Or is my only option to re-implement
WriteRegistryValues to acquire/release the protection handles before/after
creating registry keys and/or setting registry values.

-- 
Edwin G. Castro
--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Modifying Request State

[Edwin Castro]

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  wrote:

> 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 MsiPackage is selected for
> uninstall.
> * ExePackage must be uninstalled after MsiPackage is uninstalled.
> * I am using WixStandardBootstrapperApplication.HyperlinkSidebarLicense
>
> Can I set the ExePackage's request state to the MsiPackage's request state
> in an IBootstrapperBAFunction member function?
>
> --
> Edwin G. Castro
>



-- 
Edwin G. Castro
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Modifying Request State

[Edwin Castro]

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 MsiPackage is selected for
uninstall.
* ExePackage must be uninstalled after MsiPackage is uninstalled.
* I am using WixStandardBootstrapperApplication.HyperlinkSidebarLicense

Can I set the ExePackage's request state to the MsiPackage's request state
in an IBootstrapperBAFunction member function?

-- 
Edwin G. Castro
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Which Process Executes Custom Actions

[Edwin Castro]

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 total of 5  elements:








To make matters more complicated, our 64-bit MSI uses 32-bit versions of
the custom actions.

Should I expect the DLL to be loaded by the bootstrapper exe or by
msiexec.exe?

We are seeing logs that suggest that DLL is loaded by both the bootstrapper
exe and by msiexec.exe but I don't understand why.

Could an unrelated custom action that is Execute="immediate" have an effect?

-- 
Edwin G. Castro
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Predicting Bootstrapper Cache Location

[Edwin Castro]

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 attribute is not authored, the
value is the automatically-generated bundle ID and *will not automatically
support upgrades*.

This sounds like I was not getting some kind of automatic upgrade support
because we had not defined ProviderKey. Is this automatic upgrade support
described anywhere? What happens when I define it in version Y and try to
upgrade version X where version Y > version X and ProviderKey was not
defined for version X?



On Thu, Mar 26, 2015 at 2:01 PM, Phill Hogland  wrote:

> >>So it looks like the bootstrapper is not passing BUNDLEPROVIDERKEY to the
> MSI at all.
>
> You need to define Bundle/@ProviderKey,  here
>   .  I
> set it to a GUID (and like UpgradeCode I do not change the
> Bundle/@ProviderKey between builds (or releases) of my setups).
>
>
>
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Predicting-Bootstrapper-Cache-Location-tp7599709p7599730.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> --
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>



-- 
Edwin G. Castro
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Predicting Bootstrapper Cache Location

[Edwin Castro]

I had not defined BUNDLEPROVIDERKEY in my MSI *but* I was just trying to
verify that the data was passed from the bootstrapper to the MSI by
checking the bootstrapper and MSI logs.

In the bootstrapper log I see

[0BE4:13F4][2015-03-26T11:43:52]i301: Applying execute package:
projectName.msi, action: Install, path: C:\ProgramData\Package
Cache\{GUID}v1.0.0.0\projectMSI.msi, arguments: ' ARPSYSTEMCOMPONENT="1"
MSIFASTINSTALL="7" BUNDLEPROVIDERKEY=""'

In the MSI log I see

MSI (s) (A0:7C) [11:43:52:776]: Command Line: ARPSYSTEMCOMPONENT=1
MSIFASTINSTALL=7 BUNDLEPROVIDERKEY= REBOOT=ReallySuppress
CURRENTDIRECTORY=D:\Projects\solution\bootstrapper\bin\Debug
CLIENTUILEVEL=3 MSICLIENTUSESEXTERNALUI=1 CLIENTPROCESSID=3044

So it looks like the bootstrapper is not passing BUNDLEPROVIDERKEY to the
MSI at all.

My first attempt was with WiX 3.8 but I just upgraded to WiX 3.9 and I see
the same behavior.


On Thu, Mar 26, 2015 at 10:08 AM, Hoover, Jacob 
wrote:

> Did you define the property in you MSI and declare it as Secure?
>
> Ex (with remember-me pattern in place):
>
> 
>Key="SOFTWARE\$(var.ApplicationKeyPath)" Name="BundleProviderKey"
> Type="raw" />
> 
> ...
>  Property="CMDLINE_BUNDLEPROVIDERKEY" Value="[BUNDLEPROVIDERKEY]"
> Execute="firstSequence" />
>  Property="BUNDLEPROVIDERKEY" Value="[CMDLINE_BUNDLEPROVIDERKEY]"
> Execute="firstSequence" />
> ...
>   
>After='AppSearch'>CMDLINE_BUNDLEPROVIDERKEY
>
> -Original Message-
> From: Edwin Castro [mailto:egca...@gmail.com]
> Sent: Thursday, March 26, 2015 11:51 AM
> To: General discussion about the WiX toolset.
> Subject: Re: [WiX-users] Predicting Bootstrapper Cache Location
>
> Jacob,
>
> You mentioned something interesting that I can't get to work. I tried
>
> 
>   
> 
>   
> 
>
> But BUNDLEPROVIDERKEY is always empty in the msi log.
>
> Should I expect that to work?
>
> --
> Edwin  G. Castro
>
>
> On Thu, Mar 26, 2015 at 7:52 AM, Hoover, Jacob  >
> wrote:
>
> > To extend upon Phil's suggestion,
> > http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Updater-
> > application-using-Bootstrapper-UI-Bundle-td7596579.html
> >
> > -Original Message-
> > From: Phill Hogland [mailto:phogl...@rimage.com]
> > Sent: Thursday, March 26, 2015 7:11 AM
> > To: wix-users@lists.sourceforge.net
> > Subject: Re: [WiX-users] Predicting Bootstrapper Cache Location
> >
> > I described one approach in this  thread <
> > http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/WiX-Burn
> > -managing-installed-products-after-initial-install-td7595346.html#a759
> > 5368
> > >
> > .
> >
> >
> >
> > --
> > View this message in context:
> > http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Predicti
> > ng-Bootstrapper-Cache-Location-tp7599709p7599716.html
> > Sent from the wix-users mailing list archive at Nabble.com.
> >
> >
> > --
> >  Dive into the World of Parallel Programming The Go Parallel
> > Website, sponsored by Intel and developed in partnership with Slashdot
> > Media, is your hub for all things parallel software development, from
> > weekly thought leadership blogs to news, videos, case studies,
> > tutorials and more. Take a look and join the conversation now.
> > http://goparallel.sourceforge.net/
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
> > --
> >  Dive into the World of Parallel Programming The Go Parallel
> > Website, sponsored by Intel and developed in partnership with Slashdot
> > Media, is your hub for all things parallel software development, from
> > weekly thought leadership blogs to news, videos, case studies,
> > tutorials and more. Take a look and join the conversation now.
> > http://goparallel.sourceforge.net/
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
>
>
>
> --
> Edwin G. Castro
>
> --
> Dive into the World of Parallel Programming The Go Parall

Re: [WiX-users] Predicting Bootstrapper Cache Location

[Edwin Castro]

Jacob,

You mentioned something interesting that I can't get to work. I tried


  

  


But BUNDLEPROVIDERKEY is always empty in the msi log.

Should I expect that to work?

--
Edwin  G. Castro


On Thu, Mar 26, 2015 at 7:52 AM, Hoover, Jacob 
wrote:

> To extend upon Phil's suggestion,
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Updater-application-using-Bootstrapper-UI-Bundle-td7596579.html
>
> -Original Message-
> From: Phill Hogland [mailto:phogl...@rimage.com]
> Sent: Thursday, March 26, 2015 7:11 AM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Predicting Bootstrapper Cache Location
>
> I described one approach in this  thread <
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/WiX-Burn-managing-installed-products-after-initial-install-td7595346.html#a7595368
> >
> .
>
>
>
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Predicting-Bootstrapper-Cache-Location-tp7599709p7599716.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> --
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> --
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>



-- 
Edwin G. Castro
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Predicting Bootstrapper Cache Location

[Edwin Castro]

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 bootstrapper.

-- 
Edwin G. Castro
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] ExeCommand will not accept any path with spaces

[Edwin Castro]

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 really a compiled executable, then the PE file
format of the exe itself tells windows whether it is a windows subsystem
executable or a "command line" subsystem executable (I'm forgetting the
actual terminology). Windows determines the subsystem to use when it
loads the exe just prior to execution.

--
Edwin


--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] ExeCommand will not accept any path with spaces

[Edwin Castro]

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 remove cmd.exe from your invocation.

It looks like you don't have command line arguments for myprogram.exe...

Assuming the File/@Id for myprogram.exe is myprogram.exe, I would try



Or to run myprogram.exe without showing the Command Prompt window...




--
Edwin


--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] ExeCommand will not accept any path with spaces

[Edwin Castro]

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]
>> >  >
>>> >>  
>> > I don't think that's legal. cmd.exe is not a redistributable file. You 
>> > can't include it in your installer.
> cmd.exe is not being distributed.  Binary is how you call system files.
> 
> 

NO. Binary is how you embed files in your MSI for your MSI to use during
install. You ARE distributing cmd.exe in your MSI which is very likely
not allowed.

That said, I don't think your problem is related to including cmd.exe in
the Binary table of your MSI.

--
Edwin

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] ExeCommand will not accept any path with spaces

[Edwin Castro]

On 12/19/13, 5:31 PM, Gerry Reno wrote:
> The relevant code section is:
> 
> 
> 
> Execute='deferred'
>ExeCommand='/k "[INSTALLDIR]"/myprogram.exe' Return='asyncWait'
> />

Assuming you are trying to run something legitimate, is there a reason
you are trying to wrap myprogram.exe execution with cmd.exe? You really
should just call myprogram.exe directly.

--
Edwin

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Creating two start menu shortcuts for the same executable

[Edwin Castro]

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 'ApplicationShortcut'. However, the formatted string in
>>>  column 'Target' references file 'myapplication.exe' which belongs to
>>>  component 'myapplication.exe'. Components are in the same feature.
>> I think this warning is telling you that all shortcuts to
>> myapplication.exe should exist in the same component that installs
>> myapplication.exe.
>>
>> If you install the shortcuts and the exe in different components then
>> that opens the possibility that somebody will allow the exe to be
>> uninstalled without uninstalling the shortcuts.
> 
> Tell that to the official documentation of the WiX toolset ;-)
> http://wixtoolset.org/documentation/manual/v3/howtos/files_and_registry/create_start_menu_shortcut.html
> 
> The warning was also discussed on this mailing list in 2009 where it was 
> considered /normal/
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Incomprehensible-warning-td2234181.html
> 
> I can avoid it by using [APPLICATIONROOTDIRECTORY]myapplication.exe - 
> creating an unvalidated shortcut that could point to anything even 
> outside of the installer. I could also place my shortcuts directly under 
> the  element for myapplication.exe, but I'm generating the file 
> list via Heat.exe, so this would involve some patching via xmlpoke or 
> sed which I'm not keen on (and neither does the example in the 
> documentation do it that way).
> 

It is just a warning. It is describing a best practice. I don't think it
is a requirement.

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Creating two start menu shortcuts for the same executable

[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 'myapplication.exe' which belongs to
> component 'myapplication.exe'. Components are in the same feature.

I think this warning is telling you that all shortcuts to
myapplication.exe should exist in the same component that installs
myapplication.exe.

If you install the shortcuts and the exe in different components then
that opens the possibility that somebody will allow the exe to be
uninstalled without uninstalling the shortcuts.

--
Edwin

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Wix MSI not uninstalling files when package uninstalled

[Edwin Castro]

On 10/10/13 11:08 AM, Walter Dexter wrote:
> I had a similar thought about an hour ago while driving about c_drive not
> getting redefined properly for the uninstall and will try to validate if
> that's the problem later this afternoon. I do see it and all the
> directories getting property changed 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


--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Getting Duplicate Entries in Add/Remove Programs

[Edwin Castro]

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 ProductVersion to Windows Installer.

/Wix/Product/@UpgradeCode does not match /Wix/Product/Upgrade/@Id. I
expected them to be the same.

I also expected /Wix/Product/Upgrade/UpgradeVersion/@Maximum ==
$(var.Version) instead of 99.0.0.0.

Consider using the  element instead of handcrafting your
own Upgrade entries.

On 9/19/13 5:11 PM, Daniel Sniderman wrote:
> Not sure what I'm doing wrong.  Here's my XML,  I've tried other suggestions 
> I've found on this list, Stack Overflow etc - but nothing I do makes a 
> difference.
>
> Thanks!
>
>
> http://schemas.microsoft.com/wix/2006/wi";
>  xmlns:util="http://schemas.microsoft.com/wix/UtilExtension";>
>Manufacturer="Abbott Laboratories" Name="ActivityService"  
> UpgradeCode="89071eb3-16a3-4c6b-bd1d-e6a97c4359db">
>  Manufacturer="Abbott Laboratories"  InstallScope="perMachine"  />
>
> 
> 
> 
> Minimum="1.0.0.0" Maximum="99.0.0.0"
>  Property="PREVIOUSVERSIONSINSTALLED"
>  IncludeMinimum="yes" IncludeMaximum="no" />
> 
> 
>   
> 
> 
>   
>   
> 
>  Description="CMSNext Activity Service"
>   Display="expand"  ConfigurableDirectory="ACTIVITY_SERVICE">
>   
>Guid="31E1916C-C699-48CA-BCFB-B2542D61EFB9" Directory="ACTIVITY_SERVICE">
>  KeyPath="yes" 
> Source="$(var.ActvityServiceWindowsSvc.TargetDir)\ActvityServiceWindowsSvc.exe"
>  />
> 
>   
> 
>
>  Type="ownProcess"
> Vital="yes"
> Name="CMSNext Activity Service"
> DisplayName="CMSNext Activity Service"
> Description="CMSNext Service to send message to GIS Hub 
> when tickets are inserted or updated"
> Start="auto"
> ErrorControl="normal"
> Interactive="no"
> Account="[ACCOUNT]"
> Password="[PASSWORD]"
>   >
> 
>  Name="CMSNext Activity Service"
> Remove="uninstall"
> Stop="both"
> Wait="yes">
>   
>   
> 
> 
>
> 
> 
> 
>
> 
>
> 
>   
>   
>   
>   
>
>   
>   
>   
>   
>   
>   
>   
>   
>
>Value="Return" Order="999">1
>
>Value="LicenseAgreementDlg">1
>
>Value="WelcomeDlg">1
>Value="CustomizeDlg">LicenseAccepted = "1"
>
>Value="MaintenanceTypeDlg" Order="1">Installed
>Value="LicenseAgreementDlg" Order="2">NOT Installed
>Value="ServiceAccountDlg" Order="1">1
>
>Value="CustomizeDlg">1
>Value="VerifyReadyDlg">1
>
>Value="ServiceAccountDlg" Order="1">NOT Installed OR WixUI_InstallMode = 
> "Change"
>Value="MaintenanceTypeDlg" Order="2">Installed
>
>Event="NewDialog" Value="MaintenanceTypeDlg">1
>
>Event="NewDialog" Value="CustomizeDlg">1
>Event="NewDialog" Value="VerifyReadyDlg">1
>Event="NewDialog" Value="VerifyReadyDlg">1
>Value="MaintenanceWelcomeDlg">1
>
>Title="[ProductName] Setup">
>  Height="17" Text="!(loc.WixUIBack)" />
>  Height="17" Default="yes" Text="!(loc.WixUINext)">
>   
>   ACCOUNT <> "" AND PASSWORD 
> <> ""
>
> 
>  Height="17" Cancel="yes" Text="!(loc.WixUICancel)">
>   1
>
> 
>  Height="44" TabSkip="no" Text="WixUI_Bmp_Banner" />
>  Height="0" />
>  Height="0" />
>  Height="15" Transparent="yes" NoPrefix="yes" Text="Enter service account 
> details.">
>
> 
>  Transparent="yes" NoPrefix="yes" Text="{\WixUI_Font_Title}Service account" />
>  Id="BodyLabel" Text="Specify the logon account for the [ProductName] 
> service." NoPrefix="yes">
>
> 
>  Id="AccountLabel" Text="&Account name (Example: domain\user or 
> user@domain):" />
>  Id="AccountTextbox" Property="ACCOUNT" />
>  Id="PasswordLabel" Text="Pa&ssword:" />
>  Id="PasswordTextbox" Property="PASSWORD" Password="yes" />
>
>  Y="170" Id="Warning" Text="WarningIcon"/>
>  Height="40" Text="The account entered here will not be validated. Make sure 
> that the account details entered are correct." />
>
>   
>
> 
>
>   
> 
>
> --
> LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
> 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
> 2013, SQL 2012, MVC 4, more. BEST VALU

Re: [WiX-users] [SPAM] Re: Bootstrapper -- Can it be UI-less?

[Edwin Castro]

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 developers are working on what they
believe to be the most important primary tasks as they relate to WiX
even though WiX development is clearly a secondary task for most of them.

Generally speaking if something hasn't been done in an open source
project, the reason usually is that it simply hasn't been important
enough for anybody to work on it, yet. If you have an itch, then
volunteer your time and expertise and scratch it.


--
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. 
http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Service Uninstall not Removing Service

[Edwin Castro]

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 correct. I see the ServiceControl documentation for Remove says "
Specifies whether the service should be removed by the DeleteServices
action on install, uninstall or both." Perhaps the DeleteServices action
is not getting scheduled or is not executing due to a condition or
something similar? I wouldn't expect this but it's worth looking at a
verbose log to determine what is happening with the DeleteServices
action. We can troubleshoot further from there.

--
Edwin G. Castro

On 9/5/13 10:29 AM, Greg Edwards wrote:
> WIX Users,
>
> I have created a simple windows service installer with the following 
> configuration:
>
>  Guid="{980F0B9A-9F25-B729-7225-F24075392C80}">
> KeyPath="yes" ShortName="ALTUSC1.EXE" DiskId="1" 
> Source="$(var.AltusService)\Service.exe" />
> Name="AltusService" DisplayName="Altus Service" Description="Altus Service" 
> Start="auto" Account="LocalSystem" ErrorControl="ignore" Interactive="no" />
> Remove="uninstall" Name="AltusService" Wait="yes" />
> 
>
> It installs correctly and starts the service as expected.
>
> When I uninstall the service it stops it correctly, but it does not remove 
> the service from the service list.
>
> Is there something that I am missing in my configuration that may be 
> hindering the service from being removed?
>
> Thank you.
> -Greg
> --
> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> Discover the easy way to master current and previous Microsoft technologies
> and advance your career. Get an incredible 1,500+ hours of step-by-step
> tutorial videos with LearnDevNow. Subscribe today and save!
> http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>

--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] FileSearch issues

[Edwin Castro]

I searched for WiX FileSearch in same directory as MSI on google. The
first hit [1] I received [2] includes a reply from Phil Wilson
suggesting the SourceDir [3] or OriginalDatabase [4] (with some
additional parsing) might work.



[1]
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-get-the-current-directory-of-msi-is-running-from-td3058873.html
[2] I find it frustrating that different people can receive different
results. *sigh*
[3] http://msdn.microsoft.com/en-us/library/aa371857.aspx
[4] http://msdn.microsoft.com/en-us/library/aa370562.aspx

--
Edwin G. Castro

On 8/31/13 10:21 AM, Kai Peters wrote:
> Hi Edwin,
>
> no need to be suspicious of Depth and AssignToProperty (firstly, omitting 
> them didn't improve 
> things, nor did I expect it to) as Depth can avoid unnecessary file system 
> traversal (don't know how 
> deep the search would go if no Depth is specified but would assume that 
> default should be 0); 
> AssignToProperty seems redundant to me as I would always expect the innermost 
> element of a nested 
> search to be assigned - but I just put it in here to make things absolutely 
> clear.
>
> As I wrote (though not put in my example code) BOTH absolute and variable 
> path specifications fail - 
> I would never use absolute paths in production.
>
> The idea behind this search is simply that our customers' IT people could 
> place a configuration file 
> template beside our MSI and that during MSI execution this template would be 
> copied into its 
> 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 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".
>>
>> 
>> 
>>
>> 
>>  
>> > Id="WebFolderSearch" Path="Web">
>>  > Id="WebHostFolderSearch"
>> Path="ProductName"> > /> 
>> 
>> 
>>
>>
>> The Path value in your example is hard coded and that seems wrong to me. 
>> Even if you can
>> guarantee that the MSI will ALWAYS reside at that location I believe that 
>> caching by Windows
>> Installer will cause problems for you.
>>
>> My vague memory tells me that others have attempted this and couldn't 
>> reliably determine where
>> the MSI was located in other to find a companion file located in the same 
>> directory.
>>
>> An obvious workaround is to provide the path to the companion file via a 
>> public property.
>>
>> --
>> Edwin G. Castro
>>
>> On 8/29/13 10:04 AM, K Peters wrote:
>>> Hi,
>>>
>>> I am still struggling with my FileSearch - no matter what I try, it always 
>>> pops up the "File
>>> does not exist next to MSI" message. I have tried using "SourceDir" as well 
>>> as the absolute
>>> path to where both the MSI & the inifile reside - same negative results.
>>>
>>> Does anyone have an idea as to where I am screwing up...?
>>> Thanks, as always, for any pointers!
>>>
>>>
>>> 
>>> >> Id="MI_DirSearch"
>>> Path="C:\Wix_Installscripts\Release_3.1.3\Regular_Install\" Depth="0" 
>>> AssignToProperty="no">
>>>   
>>> 
>>>
>>> 
>>> 
>>> 
>>>
>>> 
>>> 
>>> 
>>> --
>>>  Learn the latest-
>>> -Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way 
>>> to master current
>>> and previous Microsoft technologies and advance your career. Get an 
>>> incredible 1,500+ hours of
>>> step-by-step tutorial videos with LearnDevNow. Subscribe today and save!
>>> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
>>> ___ WiX-users mailing list WiX-
>>> us...@lists.sourceforge.net 
>>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>>
>> --
>>  Le

Re: [WiX-users] using WixUI_Advanced

[Edwin Castro]

There must be a  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 UIRef
>
> MyProject.wxs: line 63:   
>
> Custom_Advanced.wxs: line 121: 
>
> Wix source:
> src/ext/UIExtension/wixlib/Common.wxs: line 20: 
>
> So should I comment out the WixUI_Common reference?
>
> On Thu, 2013-08-29 at 22:08 +, John Cooper wrote:
>> Well, since you've got both the standard and the custom file referenced in 
>> your error messages, it looks like you're linking in both UI's.  Find the 
>> duplicate UIRef element and remove it.
>>
>> --
>> John Merryweather Cooper
>> Build & Install Engineer -- ESA
>> Jack Henry & Associates, Inc.(r)
>> Shawnee Mission, KS  66227
>> Office:  913-341-3434 x791011
>> jocoo...@jackhenry.com
>> www.jackhenry.com
>>
>>
>>
>>
>> -Original Message-
>> From: jo...@msli.com [mailto:jo...@msli.com] 
>> Sent: Thursday, August 29, 2013 4:47 PM
>> To: General discussion for Windows Installer XML toolset.
>> Subject: Re: [WiX-users] using WixUI_Advanced
>>
>> Has anyone had success copying WixUI_Advanced.wxs to a Custom_Advanced.wxs 
>> and using it in your msi installer?
>>
>> I end up with lots of errors like these:
>>
>>  [exec] 
>> C:\cygwin\home\build\current\EUROPA\Source\wix_project\Custom_Advanced.wxs(37)
>>  : error LGHT0091 : Duplicate symbol 
>> 'CustomAction:WixSetDefaultPerUserFolder' found. This typically means that 
>> an Id is duplicated. Check to make sure all your identifiers of a given type 
>> (File, Component, Feature) are unique.
>>  [exec] 
>> E:\delivery\Dev\wix37_public\src\ext\UIExtension\wixlib\WixUI_Advanced.wxs(37)
>>  : error LGHT0092 : Location of symbol related to previous error.
>>  [exec] 
>> E:\delivery\Dev\wix37_public\src\ext\UIExtension\wixlib\WixUI_Advanced.wxs(38)
>>  : error LGHT0091 : Duplicate symbol 
>> 'CustomAction:WixSetDefaultPerMachineFolder' found. This typically means 
>> that an Id is duplicated. Check to make sure all your identifiers of a given 
>> type (File, Component, Feature) are unique.
>>  [exec] 
>> C:\cygwin\home\build\current\EUROPA\Source\wix_project\Custom_Advanced.wxs(38)
>>  : error LGHT0092 : Location of symbol related to previous error.
>>  [exec] 
>> C:\cygwin\home\build\current\EUROPA\Source\wix_project\Custom_Advanced.wxs(37)
>>  : error LGHT0091 : Duplicate symbol 
>> 'CustomAction:WixSetDefaultPerUserFolder' found. This typically means that 
>> an Id is duplicated. Check to make sure all your identifiers of a given type 
>> (File, Component, Feature) are unique.
>>  [exec] 
>> E:\delivery\Dev\wix37_public\src\ext\UIExtension\wixlib\WixUI_Advanced.wxs(37)
>>  : error LGHT0092 : Location of symbol related to previous error.
>>
>> I copied WixUI_Advanced.wxs to my project directory as Custom_Advanced.wxs, 
>> and changed
>> From:
>> < 
>> To:
>>> 
>> And in my Product element I added 
>> 
>>
>> What Am I missing?  I'm following the Wix 3.6: A Developer's guide to
>> windows Installer XML.
>>
>> On Thu, 2013-08-29 at 09:31 -0700, jo...@msli.com wrote:
>>> In my wix msi I am giving the user a choice of per-user vs.
>>> system-wide.  
>>>
>>> What is the best way to indicate a nested directory structure in
>>> ApplicationFolderName?
>>>
>>> Examples do not show how to do a nested directory structure.  
>>>
>>> My directory structure looks like this, where the product is nested
>>> inside a folder named for the company, as there are many other products.
>>> 
>>> 
>>>  
>>>   
>>>
>>>
>>>   
>>>  
>>> 
>>>
>>> In  I added
>>>  
>>>
>>> Can ApplicationFolderName look like this, where I spell out the directory 
>>> nesting?
>>>  >> Value="$(var.MyCompanyName)\$(var.MyProductName) $(var.Version)" />
>>>
>>> Is this the right way to do it or is there something better?
>>>
>>> Additionally, the dialog does not look exactly like a drop in
>>> replacement for the simple radio selection bettween per-user vs
>>> system-wide provided in the  Visual Studio Setup Project.  Is there a
>>> way to get that behavior?
>>>
>>>
>>>
>>> NOTICE: This email may contain confidential information.  Please see 
>>> http://www.meyersound.com/confidential/ for our complete policy.
>>>
>>> --
>>> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
>>> Discover the easy way to master current and previous Microsoft technologies
>>> and advance your career. Get an incredible 1,500+ hours of step-by-step
>>> tutorial videos with LearnDevNow. Subscribe today and save!
>>> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
>>> ___
>>> WiX-users mailing list
>>> WiX-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] FileSearch issues

[Edwin Castro]

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".





  

  

  

  

  

  


The Path value in your example is hard coded and that seems wrong to me.
Even if you can guarantee that the MSI will ALWAYS reside at that
location I believe that caching by Windows Installer will cause problems
for you.

My vague memory tells me that others have attempted this and couldn't
reliably determine where the MSI was located in other to find a
companion file located in the same directory.

An obvious workaround is to provide the path to the companion file via a
public property.

--
Edwin G. Castro

On 8/29/13 10:04 AM, K Peters wrote:
> Hi,
>
> I am still struggling with my FileSearch - no matter what I try,
> it always pops up the "File does not exist next to MSI" message.
> I have tried using "SourceDir" as well as the absolute path to where both
> the MSI & the inifile reside - same negative results.
>
> Does anyone have an idea as to where I am screwing up...?
> Thanks, as always, for any pointers!
>
>
> 
>   Id="MI_DirSearch"
>Path="C:\Wix_Installscripts\Release_3.1.3\Regular_Install\"
>Depth="0"
>AssignToProperty="no">
> Id="MI_FileSearch"
> Name="Master.ini" />
>   
>  
>
>  
>   
>  
>
>  
>   
>  
> --
> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> Discover the easy way to master current and previous Microsoft technologies
> and advance your career. Get an incredible 1,500+ hours of step-by-step
> tutorial videos with LearnDevNow. Subscribe today and save!
> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>


--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] 64 bit version of MS build cannot find the WIX toolset

[Edwin Castro]

MSBuild uses the AssemblySearchPaths property to determine the locations
where it searches for assembly references. See
http://msdn.microsoft.com/en-us/library/vstudio/bb629394.aspx

You could either set the HintPath for the reference OR you could add the
location of Microsoft.Deployment.WindowsInstaller.dll to
AssemblySearchPaths with something like this:


  
C:\Program Files (x86)\WiX Toolset v3.6\bin;
$(AssemblySearchPaths)
  


Note that you could possibly shadow other assemblies you depend on if
they exist in WiX's bin directory (or whatever appropriate directory you
use).

My guess as to why 32-bit MSBuild (on the command line, not through
Visual Studio) is that AssemblySearchPaths must be getting set with
32-bit only path. Perhaps something like C:\Program Files\WiX Toolset
v3.6\bin which would only resolve for 32-bit processes... You can use
the /verbose:diagnostic command line option to show you property values
and a lot of other stuff you never cared about too!


On 8/27/13 11:59 AM, John Cooper wrote:
> That doesn't look right.  Bearing in mind that we're still using WiX 3.6 RTM, 
> my HintPath looks like:
>
> <Reference Include="Microsoft.Deployment.WindowsInstaller, 
> Version=3.0.0.0, Culture=neutral, PublicKeyToken=ce35f76fcda82bad, 
> processorArchitecture=MSIL">
>   <HintPath>..\..\..\..\..\Program Files (x86)\WiX Toolset 
> v3.6\bin\Microsoft.Deployment.WindowsInstaller.dll</HintPath>
> </Reference>
>
> I don't think you're going to resolve an assembly without a hint path unless 
> it's in the GAC.
> --
> John Merryweather Cooper
> Build & Install Engineer -- ESA
> Jack Henry & Associates, Inc.(r)
> Shawnee Mission, KS  66227
> Office:  913-341-3434 x791011
> jocoo...@jackhenry.com
> www.jackhenry.com
>
>
>
>
> -Original Message-
> From: Skildum, Mathew [mailto:mathew.skil...@aspect.com] 
> Sent: Tuesday, August 27, 2013 1:45 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] 64 bit version of MS build cannot find the WIX 
> toolset
>
> The Microsoft.Deployment.WindowsInstaller assembly is located in the default 
> installation location.  No customization has been done to the system or the 
> projects.
>
> Here is the project file section that lists the above assembly refference:
>   
> 
> 
>   3.5
> 
> 
>   False
>   
> ..\..\Assemblies\Powershell\System.Management.Automation.dll
>   True
> 
> 
> 
>   
>
> Mat Skildum
>
>
>
>
> -Original Message-
> From: Edwin Castro [mailto:0ptikgh...@gmx.us]
> Sent: Tuesday, August 27, 2013 1:13 PM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] 64 bit version of MS build cannot find the WIX 
> toolset
>
> 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 them manually, correct?
>
> --
> Edwin G. Castro
>
>
> --
> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> Discover the easy way to master current and previous Microsoft technologies 
> and advance your career. Get an incredible 1,500+ hours of step-by-step 
> tutorial videos with LearnDevNow. Subscribe today and save!
> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
> --
> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> Discover the easy way to master current and previous Microsoft technologies 
> and advance your career. Get an incredible 1,500+ hours of step-by-step 
> tutorial videos with LearnDevNow. Subscribe today and save!
> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> NOTICE: This electronic mail message and any files transmitted with it are 
> intended
> exclusively for the individual or entity to which it is addressed. The 
> message, 
> together with any attachment, may contain confidential and/or privileged 
> information.
> Any unaut

Re: [WiX-users] 64 bit version of MS build cannot find the WIX toolset

[Edwin Castro]

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 them manually, correct?

--
Edwin G. Castro


--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] 64 bit version of MS build cannot find the WIX toolset

[Edwin Castro]

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: The type or namespace name 'Session' 
> co
> uld not be found (are you missing a using directive or an assembly reference?)
>   CustomAction.cs(12,23): error CS0246: The type or namespace name 
> 'ActionResul
> t' could not be found (are you missing a using directive or an assembly 
> referen
> ce?) 

These are C# compile errors. It appears you might be missing a reference
to a DTF assembly. Or perhaps the assembly reference you already has an
incorrect HintPath and can't be found...?

--
Edwin G. Castro


--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Environment variable "ProjectPath" is expanded, possible to turn off?

[Edwin Castro]

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
WixProjectFile which is set to $(ProjectPath) in wix2010.targets.

The source code for the Light MSBuild task shows that the -wixprojectfile
argument is appended to the command line only if WixProjectFile is NOT
null. Ironically, I expected WixProjectFile to always have a value because
ProjectPath is defined as follows

$(MSBuildProjectFile)
$(MSBuildProjectDirectory)\
$(ProjectDir)$(ProjectFileName)

The MSBuildProjectFile and MSBuildProjectDirectory properties are reserved
properties set by MSBuild automatically. I expected that unless
ProjectFileName and ProjectDir were set explicitly to nothing, then
ProjectPath should be set to
$(MSBuildProjectDirectory)\$(MSBuildProjectFile) which should always
resolve to a value.

In any case, because MSBuild exposes environment variables just like
regular properties you should avoid setting environment variables that
match properties used by wix2010.targets like the build event macros.



On Sun, Jul 21, 2013 at 8:47 AM, Andreas Jönsson <
andreas.jons...@noventus.se> wrote:

> Thanks for the reply but I'm not sure if I understand you correctly. Why
> would the value of an environment variable called ProjectPath influence
> Visual Studio's build event macro $(ProjectPath)?
>
> I also can't find any reference to either ProjectPath or $(ProjectPath)
> in the WiX project files so I don't see why anything is expanded at all.
> If I remove the environment variable ProjectPath, the generated command
> line becomes just:
>
> "... -wixprojectfile obj\Release\Product.wixobj"
>
> I.e the build event macro $(ProjectPath) is not getting expanded.
>
>  > Those properties are build event macros
> (http://msdn.microsoft.com/library/42x5kfw4.aspx) and are thus reserved.
>  >
>  > > Date: Sat, 20 Jul 2013 21:35:12 +0200
>  > > From: andreas.jonsson@...
>  > > To: wix-users@...
>  > > Subject: [WiX-users] Environment variable "ProjectPath" is
> expanded, possible to turn off?
>  > >
>  > > Hello,
>  > >
>  > > We have converted one of our installer projects to WiX and it seems to
>  > > work well. However, on our development machines we have an environment
>  > > variable, ProjectPath, which is completely unrelated to WiX. When the
>  > > project is built from Visual Studio (2012), this environment
> variable is
>  > > expanded in Light's command line:
>  > >
>  > > 1>C:\Program Files (x86)\WiX Toolset v3.7\bin\Light.exe -out
>  > >
>
> C:\BUILD\tools\BuildMgr\trunk\Nov.BuildMgr.WixInstall\bin\Release\BuildmanagerSetup.msi
>
>  > > -pdbout
>  > >
>
> C:\BUILD\tools\BuildMgr\trunk\Nov.BuildMgr.WixInstall\bin\Release\BuildmanagerSetup.wixpdb
>
>  > > -cultures:null -ext "C:\Program Files (x86)\WiX Toolset
>  > > v3.7\bin\\WixUIExtension.dll" -contentsfile
>  > >
> obj\Release\Nov.BuildMgr.WixInstall.wixproj.BindContentsFileListnull.txt
>  > > -outputsfile
>  > >
> obj\Release\Nov.BuildMgr.WixInstall.wixproj.BindOutputsFileListnull.txt
>  > > -builtoutputsfile
>  > >
>
> obj\Release\Nov.BuildMgr.WixInstall.wixproj.BindBuiltOutputsFileListnull.txt
>
>  > > -wixprojectfile \\DEUS\COMMON\PROJECT obj\Release\Product.wixobj
>  > > 1>light.exe(0,0): error LGHT0281: The -wixprojectfile option
> requires a
>  > > file, but the provided path is a directory: \\DEUS\COMMON\PROJECT
>  > >
>  > > The offending part is "-wixprojectfile \\DEUS\COMMON\PROJECT
>  > > obj\Release\Product.wixobj" (I have ProjectPath set to
>  > > \\DEUS\COMMON\PROJECT). The current work-around is to remove the
>  > > environment variable when building an install project, but this is
> a bit
>  > > clunky. Is there a better solution?
>  > >
>  > > Andreas Jönsson
>  > >
>  > >
>
> --
>  > > See everything from the browser to the database with AppDynamics
>  > > Get end-to-end visibility with application monitoring from AppDynamics
>  > > Isolate bottlenecks and diagnose root cause in seconds.
>  > > Start your free trial of AppDynamics Pro today!
>  > >
>  > > ___
>  > > WiX-users mailing list
>  > > WiX-users@...
>  > > https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> --
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/l

Re: [WiX-users] elevated CustomAction with Impersonate = no and Execute="deferred"

[Edwin Castro]

On Fri, Jul 19, 2013 at 8:35 AM, Chen, Jianxin  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 or after
> InstallFinalize). All actions that occur outside the installation
> transaction.”
>
>
I must have pressed enter too quickly. The last sentence should read: All
actions that occur outside the installation transaction do *not* execute
elevated.

You want to schedule the CustomAction between InstallInitialize and
InstallFinalize.

 Is there an easy way to grant some user different access permission to
> different folders during Wix installation process?
>

Yes, use PermissionEx. This is always preferred to you writing your own
custom action for granting permissions.


-- 
Edwin G. Castro
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Understanding WiX elevation and BHO

[Edwin Castro]

On Wed, Jul 17, 2013 at 8:15 AM, Dana Epp  wrote:

>  Execute
> ="deferred"
> ExeCommand='/install="[INSTALLFOLDER]$(var.Our.App.TargetFileName)"
> /privileges=admin /returnExitCode=false' Impersonate="yes" />
>

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 or after
InstallFinalize). All actions that occur outside the installation
transaction.




-- 
Edwin G. Castro
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] C# custom action to grant builtin user the installation folder full control

[Edwin Castro]

Deferred custom actions must be scheduled between InstallInitialize and
InstallFinalize to execute within the installation transaction and thus
elevated.

Prefer to use 
PermissionExinstead
of writing your own custom action.

Reconsider giving builtin\users full control of your target installation
folder. This is a huge security hole that will allow attackers to inject
arbitrary code into your application by copying a file to the application's
directory.



On Tue, Jul 16, 2013 at 10:59 AM, Chen, Jianxin <
jianxin.c...@bakerhughes.com> wrote:

> Hi, Experts,
>
> I created a C# custom action to grant the builtin\users full control of
> the installation target folder, but I have to run the "setup.exe as
> administrator" to make it work.
>
> If I just double-click the setup.exe, my custom action does not have the
> permission to change the folder.
>
> I have tried to use
>
> 1  Execute="deferred" Impersonate="no" Return="check"
>  BinaryKey="GrantFullAccessToFolder.CA.dll" DllEntry="
> GrantFullAccessToFolder "/>
>
> ...
> NOT
> Installed
>
>
>
> 2InstallPrivileges="elevated"  InstallScope="perMachine" />
>
>
> They does not work!
>
> Any questions?
>
> Thanks!
>
> JC
> ___
> Jianxin Chen | Senior Software Engineer
> Baker Hughes | Software / Intelligent Production Systems
> jianxin.c...@bakerhughes.com
> Office: +1 713.934.4136
> 14990 Yorktown Plaza Drive, Houston, 77040
> http://www.bakerhughes.com | Advancing
> Reservoir Performance
>
>
> --
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>



-- 
Edwin G. Castro
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] *Package Permanent attribute

[Edwin Castro]

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  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 understand. :-)
>
> Alain
>
> -Original Message-
> From: Wesley Manning [mailto:wmann...@dynagen.ca]
> Sent: May 31, 2013 15:41
> To: afor...@cmu.edu; General discussion for Windows Installer XML toolset.
> Subject: RE: [WiX-users] *Package Permanent attribute
>
> Just means burn will not try to uninstall it. The package will also appear
> in ARP.
>
> -Original Message-
> From: Alain Forget [mailto:afor...@cmu.edu]
> Sent: May-31-13 4:37 PM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] *Package Permanent attribute
>
> Can someone please clarify the effect of the Permanent attribute for a
> package (e.g. MsiPackage, ExePackage)?
>
> The documentation (
> http://wix.sourceforge.net/manual-wix3/wix_xsd_msipackage.htm) says,
> "Specifies whether the package can be uninstalled. The default is 'no'."
>
> Making a package impossible to uninstall seems extremely frustrating for a
> user, and in my own MsiPackage, when Permanent='yes', I can still uninstall
> it, so...I don't think I understand what it does.
>
> Alain
>
> ***
> Alain Forget, Ph.D.
> Postdoctoral Researcher
> CyLab, Carnegie Mellon University
> afor...@cmu.edu
> http://cups.cs.cmu.edu/~aforget/
> ***
>
>
>
>
>
> --
> Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free
> troubleshooting tool designed for production Get down to code-level detail
> for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap2
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
>
> --
> Get 100% visibility into Java/.NET code with AppDynamics Lite
> It's a free troubleshooting tool designed for production
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap2
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>



-- 
Edwin G. Castro
--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Putting File in TempFolder - Nothing Happens

[Edwin 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 wrote:

> >From your InstallExecuteSequence code it looks like the Custom Actions
> should be called after the file is written to TempFolder. InstallFiles
> should be long before your Custom Actions but I would double check by
> opening the generated MSI in InstEd! or Orca (or any other package which
> you can interrogate MSIs) & checking the sequence in the
> InstallExecuteSequence table. If that looks OK then I've no idea why it's
> not finding it. I would try putting some more logging into your Custom
> Action to double check the path to the db-package.bak is exactly as you
> expect it to be.
>
> Have you checked the C:\Users\Tom\AppData\Local\Temp\ directory after
> install for the existence of the db-package.bak file?
>
> Palbinder Sandher
> Software Platform Engineer
> T: +44 (0) 141 945 8500
> F: +44 (0) 141 945 8501
> http://www.iesve.com
>
> **Design, Simulate + Innovate with the **
> Integrated Environmental Solutions Limited. Registered in Scotland No.
> SC151456
> Registered Office - Helix Building, West Of Scotland Science Park, Glasgow
> G20 0SP
> Email Disclaimer
>
>
>
> -Original Message-
> From: Tom - [mailto:mittegetm...@hotmail.com]
> Sent: 28 May 2013 14:47
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Putting File in TempFolder - Nothing Happens
>
> True. The custom action uses:
> TempDir = session.GetTargetPath("TempFolder");
>
> According to the msiexec-log:
>
> MSI (c) (70:88) [14:19:49:505]: Dir (target): Key: TempFolder , Object:
> C:\Users\Tom\AppData\Local\Temp\
>
> And according to my log-messages from within the custom action that does
> GetTargetPath:
>
> MYDBLOG - Begin read parameter 'TempFolder'
> MYDBLOG - End read parameter 'TempFolder' with value
> 'C:\Users\Tom\AppData\Local\Temp\'
>
> That's why I was thinking the problem is the file isn't written to the
> Temp-folder. Regarding the order of things, I was thinking these custom
> actions, albeit after the directory-declarations, were run before the file
> is written to Temp. Which may very well be the case as I'm not very
> gracefully finding my way through the pitfalls. Directly after the
> feature-tag that includes the component/file, I've got the installsequence:
>
> 
>   NOT
> Installed
>   NOT
> Installed
>   NOT
> Installed
>   (NOT
> UPGRADINGPRODUCTCODE) AND (REMOVE="ALL")
> 
>
> 
> 
> 
> 
>   
> 
>
> Cheers,
>
> Tom
>
> > From: pally.sand...@iesve.com
> > To: wix-users@lists.sourceforge.net
> > Date: Tue, 28 May 2013 13:21:00 +
> > Subject: Re: [WiX-users] Putting File in TempFolder - Nothing Happens
> >
> > Which Temp directory are you looking in?
> > The TempFolder property page on MSDN says Windows Installer uses the
> > GetTempPath function to retrieve the path
> > ->http://msdn.microsoft.com/en-us/library/aa372067.aspx
> > GetTempPath retrieves the first valid path stored in certain
> > environment variables in the order TMP, TEMP & USERPROFILE ->
> > http://msdn.microsoft.com/en-us/library/aa364992.aspx
> > Your custom action should be calling GetTempPath to ensure it gets the
> same path as the TempFolder property.
> >
> > You haven't pasted the WiX for your Custom Action. When is it being
> called?
> >
> > Palbinder Sandher
> > Software Platform Engineer
> > T:
> > +44 (0) 141 945 8500
> > F:
> > +44 (0) 141 945 8501
> > http://www.iesve.com
> >
> > **Design, Simulate + Innovate with the **
> > Integrated Environmental Solutions Limited. Registered in Scotland No.
> > SC151456 Registered Office - Helix Building, West Of Scotland Science
> > Park, Glasgow G20 0SP Email Disclaimer
> >
> >
> > -Original Message-
> > From: Tom - [mailto:mittegetm...@hotmail.com]
> > Sent: 28 May 2013 13:33
> > To: wix-users@lists.sourceforge.net
> > Subject: [WiX-users] Putting File in TempFolder - Nothing Happens
> >
> > Good afternoon,
> >
> > I am creating a database installation. First I try to migrate a database
> from SQL 2005 to SQL 2008, but should no database be on a SQL 2005 on the
> machine, I am installing a new one. To make this happen, I thought I'll put
> a backup file into the TempFolder and reference that file in my custom
> action to restore it. So far so good but it's not working. It's not working
> because it can't find the backup-file in the TempFolder. The XML that I've
> got is:
> >
> > 
> >   
> > 
> >Source='SetupContent\db-package.bak' KeyPath='yes' />
> > 
> >   
> >   
> > 
> >   
> >   
> > 
> >   
> > 
> >
> > 
> >  Level="1">
> >   
> > 
> >
> > Either that XML is messed up, or my custom action runs before the file
> has been placed in the TempFolder. Reading the logs or looking in the
> folders, I can't figure out which. Anyon

Re: [WiX-users] Is is possible to change default database port?

[Edwin Castro]

On Mon, May 13, 2013 at 11:20 AM, John Cooper wrote:

> 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
--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] When are elevated permissions dropped?

[Edwin Castro]

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 wrote:

> To illustrate a problem I'm having with a real project, I created a test
> script that runs a custom action that requires elevated privileges during
> uninstalls.  If I configure it to run before "InstallFinalize" (deferred,
> no impersonation), the uninstall fails to complete.  The event log says "A
> program run as part of the setup did not finish as expected" and indicates
> the program being called by the custom action.  Changing it to run after
> "DeleteServices" works.  I think that this indicates a problem with
> permissions.  Shouldn't the elevated permissions remain before
> "InstallFinalize"?
>
> Here's the script.  The custom actions and the install execute sequence
> are the interesting parts:
>
> 
> http://schemas.microsoft.com/wix/2006/wi";>
>   Name="Foo2"
>Language="1033"
>Version="1.0.0.0"
>Manufacturer="Foo"
>UpgradeCode="55369FED-96BF-4D95-99E4-E7D746A54C62">
>   Compressed="yes"
>  InstallScope="perMachine" />
>
> 
> 
> Privileged
>
>   Title="FooInstaller"
>  Level="1">
>   
> 
>
>Execute="deferred"
>   Directory="INSTALLFOLDER"
>   ExeCommand="[SystemFolder]netsh.exe http add urlacl
> url=http://+:49260/Foo2/ user=\Everyone"
>   Impersonate="no"
>   Return="check" />
>Execute="deferred"
>   Directory="INSTALLFOLDER"
>   ExeCommand="[SystemFolder]netsh.exe http delete urlacl
> url=http://+:49260/Foo2/";
>   Impersonate="no"
>   Return="check" />
>
> 
>   
>  Before="InstallFinalize">
>  Before="InstallFinalize">
> 
>   
>
>   
> Name="SourceDir">
>   
> Name="Foo2" />
>   
> 
>   
>
>   
>  Directory="INSTALLFOLDER">
>   
>Name="HelloFile.txt"
>   Source="hello.txt" />
>   
> 
>   
> 
>
> --
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and
> their applications. This 200-page book is written by three acclaimed
> leaders in the field. The early access version is available now.
> Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>



-- 
Edwin G. Castro
--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Heat with file path longer than 260 chars report an error

[Edwin Castro]

That character limit on paths is imposed by .NET. :-(


On Fri, May 3, 2013 at 10:56 AM, Marco Tognacci  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 (with the name and the full subdirectories path)Is
> there any way to harvest a folder with may subdirectories as the single
> filepath is longer than 260 chars?
>
>
> --
> Get 100% visibility into Java/.NET code with AppDynamics Lite
> It's a free troubleshooting tool designed for production
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap2
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>



-- 
Edwin G. Castro
--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to use PostBuild event code to include configuration in msi name (eg MyInstaller Test.msi)

[Edwin Castro]

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  wrote:

> Yeah, changing the TargetName should just be a matter of editing the
> .wixproj to include another MSBuild property. This is really about MSBuild
> though functionality, not the WiX toolset.
>
>
> On Fri, Apr 5, 2013 at 4:54 AM, j2associates 
> wrote:
>
> > Hello Rob,
> >
> > Thanks for the reply.
> >
> > We have our Wix project in the same solution as the application and just
> > create the msi when the solution is built by Visual Studio. We are not
> > doing
> > anything in Wix with the command line, everything is done via Visual
> > Studio.
> >
> > I do not think it is possible to set the TargetName from within a wxs
> file.
> >
> > Our solution also contains a web services project with different
> endpoints
> > depending upon the configuration being compiled. So if a particular build
> > is
> > going to be released to testing, we build twice, once for Test and once
> for
> > Lab and send both msi files to Test. Once it has passed Test, the Lab msi
> > is
> > sent to the Lab. This process ensures both msi files were created against
> > the same application code base.
> >
> > Are we missing something obvious here?
> >
> >
> >
> > --
> > View this message in context:
> >
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-use-PostBuild-event-code-to-include-configuration-in-msi-name-eg-MyInstaller-Test-msi-tp7584890p7584912.html
> > Sent from the wix-users mailing list archive at Nabble.com.
> >
> >
> >
> --
> > Minimize network downtime and maximize team effectiveness.
> > Reduce network management and security costs.Learn how to hire
> > the most talented Cisco Certified professionals. Visit the
> > Employer Resources Portal
> > http://www.cisco.com/web/learning/employer_resources/index.html
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
>
> --
> Minimize network downtime and maximize team effectiveness.
> Reduce network management and security costs.Learn how to hire
> the most talented Cisco Certified professionals. Visit the
> Employer Resources Portal
> http://www.cisco.com/web/learning/employer_resources/index.html
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>



-- 
Edwin G. Castro
--
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Consume MSDeploy Staged Web Site Output in a WIX Installer

[Edwin Castro]

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
harvesting a project that referenced other projects where the other
projects were not harvested.

Here is how I would change the Condition:





On Fri, Mar 15, 2013 at 5:51 AM, chennam wrote:

> Hi Edwin,
>
> Thanks for the reply ..
>
> Yes we would like check-in the Heat fragments into over TFS and manage that
> file components when ever we add new files to the Main project and make WIX
> project setup also part of daily builds.
>
> Can you specify how and where to specify the condition to check for the
> file
> as you said?
>
> Another thing that strikes me is even though I specified the
>
> True not sure why heat.exe is run?
>
> Thanks In advance.
>
>
>
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Consume-MSDeploy-Staged-Web-Site-Output-in-a-WIX-Installer-tp7584362p7584373.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> --
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>



-- 
Edwin G. Castro
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Consume MSDeploy Staged Web Site Output in a WIX Installer

[Edwin Castro]

On Thu, Mar 14, 2013 at 2:09 PM, chennam wrote:

> 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() but then it
occurred to me that you will probably commit this file to source control
otherwise you'd be generating it on every build... Why not run Heat
directly the one time?

-- 
Edwin G. Castro
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users