Hi guys,
Thanks for the replies!
CAs only would be great for now, if we can get that to compile on x64 it’d be more tha enough. The toolset can still be x86 for quite some time IMO.
More or less related: is there any discussion or plan to create a completely new toolset for NanoServer packages (aka life after MSI)?
Alessandro
On 16 Jul 2015, at 19:33, Bob Arnson <bob@...<mailto:bob@...>> wrote:
CAs only or CAs+everything else?
_______________________________________________________________
FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/
From: Rob Mensching [mailto:rob@...]
Sent: Thursday, 16 July, 2015 12:19
To: WiX toolset developer mailing list <wix-devs@...<mailto:wix-devs@...>>
Subject: Re: [WiX-devs] x64 extensions binaries for Windows Server 2016 without WoW64
This is just work (mostly build system work at that). It should be done. Just need someone to step up. <smile/>
_______________________________________________________________
FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/
From: Blair Murri [mailto:osito@...]
Sent: Thursday, July 16, 2015 12:55 AM
To: wix-devs@...<mailto:wix-devs@...>
Subject: Re: [WiX-devs] x64 extensions binaries for Windows Server 2016 without WoW64
The ability to remove WoW64 has been there since Server 2008. Almost nobody removes it, since almost all workloads seem to require it (at least on some level).
In theory all of the current code should be able to be built 64-only (probably with some proj file changes), but some of the system DLLs that the packaging-time tools (light, etc) make use of are only supplied by MSFT in 32-bit form (even on 64-bit platforms), so creating MSIs requires the build machines, if 64-bit, to have WoW64 installed.
Sent from Windows Mail
From: Alessandro Pilotti<mailto:apilotti@...>
Sent: ‎Sunday‎, ‎July‎ ‎12‎, ‎2015 ‎4‎:‎45‎ ‎AM
To: wix-devs@...<mailto:wix-devs@...>
Hi guys,
Being this is my first email to the ML, let me start with a big thank you for your great work developing and maintaining the WiX toolset!
The upcoming Windows Server 2016 (Threshold) provides the option to avoid deploying the WoW64 32 bit subsystem, meaning that any x86 exe / dll won’t work.
To remove WoW64 from e.g. a TP2 installation:
Remove-WindowsFeature WoW64-Support
WiX extension DLLs (WixUIExtension, WixUtilExtension, etc) are provided in x86 form only in binary downloads, meaning that any attempt to deploy an MSI that uses any of them in the above use case will fail.
Do you guys plan to package x64 versions as well in upcoming releases?
For Wix 3.9, is there a way to build the extensions targeting x64 skipping the rest of the WiX build?
Thanks!
Alessandro
------------------------------------------------------------------------------
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-devs mailing list
WiX-devs@...<mailto:WiX-devs@...>
https://lists.sourceforge.net/lists/listinfo/wix-devs
------------------------------------------------------------------------------
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-devs mailing list
WiX-devs@...<mailto:WiX-devs@...>
https://lists.sourceforge.net/lists/listinfo/wix-devs

CAs only or CAs+everything else?
_______________________________________________________________
FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/
From: Rob Mensching [mailto:rob@...]
Sent: Thursday, 16 July, 2015 12:19
To: WiX toolset developer mailing list <wix-devs@...>
Subject: Re: [WiX-devs] x64 extensions binaries for Windows Server 2016 without WoW64
This is just work (mostly build system work at that). It should be done. Just need someone to step up. <smile/>
_______________________________________________________________
FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/
From: Blair Murri [mailto:osito@...]
Sent: Thursday, July 16, 2015 12:55 AM
To: wix-devs@...<mailto:wix-devs@...>
Subject: Re: [WiX-devs] x64 extensions binaries for Windows Server 2016 without WoW64
The ability to remove WoW64 has been there since Server 2008. Almost nobody removes it, since almost all workloads seem to require it (at least on some level).
In theory all of the current code should be able to be built 64-only (probably with some proj file changes), but some of the system DLLs that the packaging-time tools (light, etc) make use of are only supplied by MSFT in 32-bit form (even on 64-bit platforms), so creating MSIs requires the build machines, if 64-bit, to have WoW64 installed.
Sent from Windows Mail
From: Alessandro Pilotti<mailto:apilotti@...>
Sent: ‎Sunday‎, ‎July‎ ‎12‎, ‎2015 ‎4‎:‎45‎ ‎AM
To: wix-devs@...<mailto:wix-devs@...>
Hi guys,
Being this is my first email to the ML, let me start with a big thank you for your great work developing and maintaining the WiX toolset!
The upcoming Windows Server 2016 (Threshold) provides the option to avoid deploying the WoW64 32 bit subsystem, meaning that any x86 exe / dll won’t work.
To remove WoW64 from e.g. a TP2 installation:
Remove-WindowsFeature WoW64-Support
WiX extension DLLs (WixUIExtension, WixUtilExtension, etc) are provided in x86 form only in binary downloads, meaning that any attempt to deploy an MSI that uses any of them in the above use case will fail.
Do you guys plan to package x64 versions as well in upcoming releases?
For Wix 3.9, is there a way to build the extensions targeting x64 skipping the rest of the WiX build?
Thanks!
Alessandro
------------------------------------------------------------------------------
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-devs mailing list
WiX-devs@...<mailto:WiX-devs@...>
https://lists.sourceforge.net/lists/listinfo/wix-devs

This is just work (mostly build system work at that). It should be done. Just need someone to step up. <smile/>
_______________________________________________________________
FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/
From: Blair Murri [mailto:osito@...]
Sent: Thursday, July 16, 2015 12:55 AM
To: wix-devs@...
Subject: Re: [WiX-devs] x64 extensions binaries for Windows Server 2016 without WoW64
The ability to remove WoW64 has been there since Server 2008. Almost nobody removes it, since almost all workloads seem to require it (at least on some level).
In theory all of the current code should be able to be built 64-only (probably with some proj file changes), but some of the system DLLs that the packaging-time tools (light, etc) make use of are only supplied by MSFT in 32-bit form (even on 64-bit platforms), so creating MSIs requires the build machines, if 64-bit, to have WoW64 installed.
Sent from Windows Mail
From: Alessandro Pilotti<mailto:apilotti@...>
Sent: ‎Sunday‎, ‎July‎ ‎12‎, ‎2015 ‎4‎:‎45‎ ‎AM
To: wix-devs@...<mailto:wix-devs@...>
Hi guys,
Being this is my first email to the ML, let me start with a big thank you for your great work developing and maintaining the WiX toolset!
The upcoming Windows Server 2016 (Threshold) provides the option to avoid deploying the WoW64 32 bit subsystem, meaning that any x86 exe / dll won’t work.
To remove WoW64 from e.g. a TP2 installation:
Remove-WindowsFeature WoW64-Support
WiX extension DLLs (WixUIExtension, WixUtilExtension, etc) are provided in x86 form only in binary downloads, meaning that any attempt to deploy an MSI that uses any of them in the above use case will fail.
Do you guys plan to package x64 versions as well in upcoming releases?
For Wix 3.9, is there a way to build the extensions targeting x64 skipping the rest of the WiX build?
Thanks!
Alessandro
------------------------------------------------------------------------------
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-devs mailing list
WiX-devs@...<mailto:WiX-devs@...>
https://lists.sourceforge.net/lists/listinfo/wix-devs

The ability to remove WoW64 has been there since Server 2008. Almost nobody removes it, since almost all workloads seem to require it (at least on some level).
In theory all of the current code should be able to be built 64-only (probably with some proj file changes), but some of the system DLLs that the packaging-time tools (light, etc) make use of are only supplied by MSFT in 32-bit form (even on 64-bit platforms), so creating MSIs requires the build machines, if 64-bit, to have WoW64 installed.
Sent from Windows Mail
From: Alessandro Pilotti
Sent: ‎Sunday‎, ‎July‎ ‎12‎, ‎2015 ‎4‎:‎45‎ ‎AM
To: wix-devs@...
Hi guys,
Being this is my first email to the ML, let me start with a big thank you for your great work developing and maintaining the WiX toolset!
The upcoming Windows Server 2016 (Threshold) provides the option to avoid deploying the WoW64 32 bit subsystem, meaning that any x86 exe / dll won’t work.
To remove WoW64 from e.g. a TP2 installation:
Remove-WindowsFeature WoW64-Support
WiX extension DLLs (WixUIExtension, WixUtilExtension, etc) are provided in x86 form only in binary downloads, meaning that any attempt to deploy an MSI that uses any of them in the above use case will fail.
Do you guys plan to package x64 versions as well in upcoming releases?
For Wix 3.9, is there a way to build the extensions targeting x64 skipping the rest of the WiX build?
Thanks!
Alessandro
------------------------------------------------------------------------------
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-devs mailing list
WiX-devs@...
https://lists.sourceforge.net/lists/listinfo/wix-devs

We've known this has been coming and waiting for it to hit priority. A 64-bit Burn will be needed as well.
Probably something for someone to do for v4.0 and, probably, v3.11.
It isn't as easy as just building 64-bit DLLs.
_______________________________________________________________
FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/
-----Original Message-----
From: Alessandro Pilotti [mailto:apilotti@...]
Sent: Sunday, July 12, 2015 4:40 AM
To: WiX toolset developer mailing list
Subject: [WiX-devs] x64 extensions binaries for Windows Server 2016 without WoW64
Hi guys,
Being this is my first email to the ML, let me start with a big thank you for your great work developing and maintaining the WiX toolset!
The upcoming Windows Server 2016 (Threshold) provides the option to avoid deploying the WoW64 32 bit subsystem, meaning that any x86 exe / dll won’t work.
To remove WoW64 from e.g. a TP2 installation:
Remove-WindowsFeature WoW64-Support
WiX extension DLLs (WixUIExtension, WixUtilExtension, etc) are provided in x86 form only in binary downloads, meaning that any attempt to deploy an MSI that uses any of them in the above use case will fail.
Do you guys plan to package x64 versions as well in upcoming releases?
For Wix 3.9, is there a way to build the extensions targeting x64 skipping the rest of the WiX build?
Thanks!
Alessandro
------------------------------------------------------------------------------
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-devs mailing list
WiX-devs@...
https://lists.sourceforge.net/lists/listinfo/wix-devs

Found it. I was using the "Developer Command Prompt for VS 2015." It looks like some of the settings in there are still specific to .NET Framework 4.5.1.
I switched to the "MSBuild Command Prompt for VS 2015" and, although SHFB gives me a fat warning, everything builds.
--
John Merryweather Cooper
Senior Software Engineer | Integration Development Group | Enterprise Notification Service
Jack Henry & Associates, Inc.® | Lenexa, KS 66214 | Ext: 431050 | JoCooper@...<mailto:JoCooper@...>
________________________________
From: John Cooper
Sent: Sunday, July 12, 2015 7:16 AM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] Problem Building a Signed WiX 3.10 Build
The e-mail below is from an external source. Please do not open attachments or click links from an unknown or suspicious origin.
Ok, uninstalled Sandcastle and insured that %SHFBROOT% was undefined. even smoked the NuGet package in the package directory so it would be reinstalled just to make sure.
Good news: BE0032 is gone. Bad news is that it is replaced by a BE0071:
"c:\git\wix3-jmc\wix.proj" (default target) (1) ->
"c:\git\wix3-jmc\src\dtf\dtf.proj" (default target) (14) ->
"c:\git\wix3-jmc\src\dtf\Documents\Guide\dtfguide.helpproj" (default target) (39) ->
"c:\git\wix3-jmc\src\dtf\Documents\Reference\dtfref.shfbproj" (default target) (40) ->
(CoreBuildHelp target) ->
SHFB : error BE0071: Unable to locate information for the project framework version 'v4.0.30319' or a suitable redirected version on this system. See error number help topic for details. [c:\git\wix3-jmc\src\dtf\Documents\Reference\dtfref.shfbproj]
1 Warning(s)
1 Error(s)
--
John Merryweather Cooper
Senior Software Engineer | Integration Development Group | Enterprise Notification Service
Jack Henry & Associates, Inc.® | Lenexa, KS 66214 | Ext: 431050 | JoCooper@...<mailto:JoCooper@...>
________________________________
From: Rob Mensching [rob@...]
Sent: Sunday, July 12, 2015 3:13 AM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] Problem Building a Signed WiX 3.10 Build
The e-mail below is from an external source. Please do not open attachments or click links from an unknown or suspicious origin.
Try uninstalling Sandcastle and make sure all of its environment variables are removed from your build cmd prompt.
_______________________________________________________________
FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/
From: John Cooper [mailto:JoCooper@...]
Sent: Saturday, July 11, 2015 10:22 PM
To: WiX toolset developer mailing list (wix-devs@...)
Subject: Re: [WiX-devs] Problem Building a Signed WiX 3.10 Build
Well, I’ve learned somethings. There is a .NETFramework 4.5.3 section in the Frameworks.xml file of both the package and the Sandcastle I installed. However, both 4.5.3 sections have a bug in them that keeps them from being useful for making an otherwise suitable template for .NETFramework 4.6: The FSharp.Core assembly has a typo in it’s AssemblyVersion field—it has a ‘,’ (comma) where it should have a ‘.’ (period).
Replacing that allowed me to make a suitable section. I checked using ILDASM, and the AssemblyVersions and PublicKeys all look right.
But even after regeneration, and tweaking the .NETFramework.config file, I can’t make the BE0032 go away. Also tried with the NuGet Package—same issue. I can regenerate, but I can’t make BE0032 go away.
For now, I’m just suppressing Sandcastle documentation.
--
John Merryweather Cooper
Senior Software Engineer | Integration Development Group | Enterprise Notification Service
Jack Henry & Associates, Inc.® | Lenexa, KS 66214 | Ext: 431050 |JoCooper@...<mailto:JoCooper@...>
From: John Cooper
Sent: Saturday, July 11, 2015 8:58 PM
To: WiX toolset developer mailing list (wix-devs@...<mailto:wix-devs@...>)
Subject: Problem Building a Signed WiX 3.10 Build
1) My first attempt gave me a cryptic error about not being able to determine the Framework in src\dtf\Documents\Reference\dtfref.shfbproj. After a little rummaging, it seemed it might me helpful to install the latest SandCastle on my WiX build machine, so I did.
2) Now, there is less red, but I am left with how to solve:
SHFB : error BE0032. Reflection data files do not exist yet [D:\git\wix3-jmc\src\\dtf\Documents\Reference\dtfref.shfbproj]
This actually makes sense because, with VS 2015 RC CTP 6 installed, I also have .NET 4.6 RC. Looking at the files in SandCastle, it appears the last version it has reflection data for is .NET 4.5.1. I think there’s a way to redirect Sandcastle, but I’m not currently familiar enough with the product—something that will probably change.
Installed:
VS 2010
VS 2010 SDK
VS 2012
VS 2012 SDK
VS 2013
VS 2013 SDK
VS 2015
VS 2015 SDK
Sandcastle Help File Builder 15.1.12.0.
Anybody know how to fix this?
--
John Merryweather Cooper
Senior Software Engineer | Integration Development Group | Enterprise Notification Service
Jack Henry & Associates, Inc.® | Lenexa, KS 66214 | Ext: 431050 |JoCooper@...<mailto:JoCooper@...>
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 unauthorized review, use, printing, saving, copying, disclosure or distribution
is strictly prohibited. If you have received this message in error, please
immediately advise the sender by reply email and delete all copies.
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 unauthorized review, use, printing, saving, copying, disclosure or distribution
is strictly prohibited. If you have received this message in error, please
immediately advise the sender by reply email and delete all copies.
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 unauthorized review, use, printing, saving, copying, disclosure or distribution
is strictly prohibited. If you have received this message in error, please
immediately advise the sender by reply email and delete all copies.

Ok, uninstalled Sandcastle and insured that %SHFBROOT% was undefined. even smoked the NuGet package in the package directory so it would be reinstalled just to make sure.
Good news: BE0032 is gone. Bad news is that it is replaced by a BE0071:
"c:\git\wix3-jmc\wix.proj" (default target) (1) ->
"c:\git\wix3-jmc\src\dtf\dtf.proj" (default target) (14) ->
"c:\git\wix3-jmc\src\dtf\Documents\Guide\dtfguide.helpproj" (default target) (39) ->
"c:\git\wix3-jmc\src\dtf\Documents\Reference\dtfref.shfbproj" (default target) (40) ->
(CoreBuildHelp target) ->
SHFB : error BE0071: Unable to locate information for the project framework version 'v4.0.30319' or a suitable redirected version on this system. See error number help topic for details. [c:\git\wix3-jmc\src\dtf\Documents\Reference\dtfref.shfbproj]
1 Warning(s)
1 Error(s)
--
John Merryweather Cooper
Senior Software Engineer | Integration Development Group | Enterprise Notification Service
Jack Henry & Associates, Inc.® | Lenexa, KS 66214 | Ext: 431050 | JoCooper@...<mailto:JoCooper@...>
________________________________
From: Rob Mensching [rob@...]
Sent: Sunday, July 12, 2015 3:13 AM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] Problem Building a Signed WiX 3.10 Build
The e-mail below is from an external source. Please do not open attachments or click links from an unknown or suspicious origin.
Try uninstalling Sandcastle and make sure all of its environment variables are removed from your build cmd prompt.
_______________________________________________________________
FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/
From: John Cooper [mailto:JoCooper@...]
Sent: Saturday, July 11, 2015 10:22 PM
To: WiX toolset developer mailing list (wix-devs@...)
Subject: Re: [WiX-devs] Problem Building a Signed WiX 3.10 Build
Well, I’ve learned somethings. There is a .NETFramework 4.5.3 section in the Frameworks.xml file of both the package and the Sandcastle I installed. However, both 4.5.3 sections have a bug in them that keeps them from being useful for making an otherwise suitable template for .NETFramework 4.6: The FSharp.Core assembly has a typo in it’s AssemblyVersion field—it has a ‘,’ (comma) where it should have a ‘.’ (period).
Replacing that allowed me to make a suitable section. I checked using ILDASM, and the AssemblyVersions and PublicKeys all look right.
But even after regeneration, and tweaking the .NETFramework.config file, I can’t make the BE0032 go away. Also tried with the NuGet Package—same issue. I can regenerate, but I can’t make BE0032 go away.
For now, I’m just suppressing Sandcastle documentation.
--
John Merryweather Cooper
Senior Software Engineer | Integration Development Group | Enterprise Notification Service
Jack Henry & Associates, Inc.® | Lenexa, KS 66214 | Ext: 431050 |JoCooper@...<mailto:JoCooper@...>
From: John Cooper
Sent: Saturday, July 11, 2015 8:58 PM
To: WiX toolset developer mailing list (wix-devs@...<mailto:wix-devs@...>)
Subject: Problem Building a Signed WiX 3.10 Build
1) My first attempt gave me a cryptic error about not being able to determine the Framework in src\dtf\Documents\Reference\dtfref.shfbproj. After a little rummaging, it seemed it might me helpful to install the latest SandCastle on my WiX build machine, so I did.
2) Now, there is less red, but I am left with how to solve:
SHFB : error BE0032. Reflection data files do not exist yet [D:\git\wix3-jmc\src\\dtf\Documents\Reference\dtfref.shfbproj]
This actually makes sense because, with VS 2015 RC CTP 6 installed, I also have .NET 4.6 RC. Looking at the files in SandCastle, it appears the last version it has reflection data for is .NET 4.5.1. I think there’s a way to redirect Sandcastle, but I’m not currently familiar enough with the product—something that will probably change.
Installed:
VS 2010
VS 2010 SDK
VS 2012
VS 2012 SDK
VS 2013
VS 2013 SDK
VS 2015
VS 2015 SDK
Sandcastle Help File Builder 15.1.12.0.
Anybody know how to fix this?
--
John Merryweather Cooper
Senior Software Engineer | Integration Development Group | Enterprise Notification Service
Jack Henry & Associates, Inc.® | Lenexa, KS 66214 | Ext: 431050 |JoCooper@...<mailto:JoCooper@...>
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 unauthorized review, use, printing, saving, copying, disclosure or distribution
is strictly prohibited. If you have received this message in error, please
immediately advise the sender by reply email and delete all copies.
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 unauthorized review, use, printing, saving, copying, disclosure or distribution
is strictly prohibited. If you have received this message in error, please
immediately advise the sender by reply email and delete all copies.

Hi guys,
Being this is my first email to the ML, let me start with a big thank you for your great work developing and maintaining the WiX toolset!
The upcoming Windows Server 2016 (Threshold) provides the option to avoid deploying the WoW64 32 bit subsystem, meaning that any x86 exe / dll won’t work.
To remove WoW64 from e.g. a TP2 installation:
Remove-WindowsFeature WoW64-Support
WiX extension DLLs (WixUIExtension, WixUtilExtension, etc) are provided in x86 form only in binary downloads, meaning that any attempt to deploy an MSI that uses any of them in the above use case will fail.
Do you guys plan to package x64 versions as well in upcoming releases?
For Wix 3.9, is there a way to build the extensions targeting x64 skipping the rest of the WiX build?
Thanks!
Alessandro

Try uninstalling Sandcastle and make sure all of its environment variables are removed from your build cmd prompt.
_______________________________________________________________
FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/
From: John Cooper [mailto:JoCooper@...]
Sent: Saturday, July 11, 2015 10:22 PM
To: WiX toolset developer mailing list (wix-devs@...)
Subject: Re: [WiX-devs] Problem Building a Signed WiX 3.10 Build
Well, I've learned somethings. There is a .NETFramework 4.5.3 section in the Frameworks.xml file of both the package and the Sandcastle I installed. However, both 4.5.3 sections have a bug in them that keeps them from being useful for making an otherwise suitable template for .NETFramework 4.6: The FSharp.Core assembly has a typo in it's AssemblyVersion field-it has a ',' (comma) where it should have a '.' (period).
Replacing that allowed me to make a suitable section. I checked using ILDASM, and the AssemblyVersions and PublicKeys all look right.
But even after regeneration, and tweaking the .NETFramework.config file, I can't make the BE0032 go away. Also tried with the NuGet Package-same issue. I can regenerate, but I can't make BE0032 go away.
For now, I'm just suppressing Sandcastle documentation.
--
John Merryweather Cooper
Senior Software Engineer | Integration Development Group | Enterprise Notification Service
Jack Henry & Associates, Inc.(r) | Lenexa, KS 66214 | Ext: 431050 |JoCooper@...<mailto:JoCooper@...>
From: John Cooper
Sent: Saturday, July 11, 2015 8:58 PM
To: WiX toolset developer mailing list (wix-devs@...<mailto:wix-devs@...>)
Subject: Problem Building a Signed WiX 3.10 Build
1) My first attempt gave me a cryptic error about not being able to determine the Framework in src\dtf\Documents\Reference\dtfref.shfbproj. After a little rummaging, it seemed it might me helpful to install the latest SandCastle on my WiX build machine, so I did.
2) Now, there is less red, but I am left with how to solve:
SHFB : error BE0032. Reflection data files do not exist yet [D:\git\wix3-jmc\src\\dtf\Documents\Reference\dtfref.shfbproj]
This actually makes sense because, with VS 2015 RC CTP 6 installed, I also have .NET 4.6 RC. Looking at the files in SandCastle, it appears the last version it has reflection data for is .NET 4.5.1. I think there's a way to redirect Sandcastle, but I'm not currently familiar enough with the product-something that will probably change.
Installed:
VS 2010
VS 2010 SDK
VS 2012
VS 2012 SDK
VS 2013
VS 2013 SDK
VS 2015
VS 2015 SDK
Sandcastle Help File Builder 15.1.12.0.
Anybody know how to fix this?
--
John Merryweather Cooper
Senior Software Engineer | Integration Development Group | Enterprise Notification Service
Jack Henry & Associates, Inc.(r) | Lenexa, KS 66214 | Ext: 431050 |JoCooper@...<mailto:JoCooper@...>
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 unauthorized review, use, printing, saving, copying, disclosure or distribution
is strictly prohibited. If you have received this message in error, please
immediately advise the sender by reply email and delete all copies.

Well, I've learned somethings. There is a .NETFramework 4.5.3 section in the Frameworks.xml file of both the package and the Sandcastle I installed. However, both 4.5.3 sections have a bug in them that keeps them from being useful for making an otherwise suitable template for .NETFramework 4.6: The FSharp.Core assembly has a typo in it's AssemblyVersion field-it has a ',' (comma) where it should have a '.' (period).
Replacing that allowed me to make a suitable section. I checked using ILDASM, and the AssemblyVersions and PublicKeys all look right.
But even after regeneration, and tweaking the .NETFramework.config file, I can't make the BE0032 go away. Also tried with the NuGet Package-same issue. I can regenerate, but I can't make BE0032 go away.
For now, I'm just suppressing Sandcastle documentation.
--
John Merryweather Cooper
Senior Software Engineer | Integration Development Group | Enterprise Notification Service
Jack Henry & Associates, Inc.(r) | Lenexa, KS 66214 | Ext: 431050 |JoCooper@...<mailto:JoCooper@...>
From: John Cooper
Sent: Saturday, July 11, 2015 8:58 PM
To: WiX toolset developer mailing list (wix-devs@...)
Subject: Problem Building a Signed WiX 3.10 Build
1) My first attempt gave me a cryptic error about not being able to determine the Framework in src\dtf\Documents\Reference\dtfref.shfbproj. After a little rummaging, it seemed it might me helpful to install the latest SandCastle on my WiX build machine, so I did.
2) Now, there is less red, but I am left with how to solve:
SHFB : error BE0032. Reflection data files do not exist yet [D:\git\wix3-jmc\src\\dtf\Documents\Reference\dtfref.shfbproj]
This actually makes sense because, with VS 2015 RC CTP 6 installed, I also have .NET 4.6 RC. Looking at the files in SandCastle, it appears the last version it has reflection data for is .NET 4.5.1. I think there's a way to redirect Sandcastle, but I'm not currently familiar enough with the product-something that will probably change.
Installed:
VS 2010
VS 2010 SDK
VS 2012
VS 2012 SDK
VS 2013
VS 2013 SDK
VS 2015
VS 2015 SDK
Sandcastle Help File Builder 15.1.12.0.
Anybody know how to fix this?
--
John Merryweather Cooper
Senior Software Engineer | Integration Development Group | Enterprise Notification Service
Jack Henry & Associates, Inc.(r) | Lenexa, KS 66214 | Ext: 431050 |JoCooper@...<mailto:JoCooper@...>
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 unauthorized review, use, printing, saving, copying, disclosure or distribution
is strictly prohibited. If you have received this message in error, please
immediately advise the sender by reply email and delete all copies.

1) My first attempt gave me a cryptic error about not being able to determine the Framework in src\dtf\Documents\Reference\dtfref.shfbproj. After a little rummaging, it seemed it might me helpful to install the latest SandCastle on my WiX build machine, so I did.
2) Now, there is less red, but I am left with how to solve:
SHFB : error BE0032. Reflection data files do not exist yet [D:\git\wix3-jmc\src\\dtf\Documents\Reference\dtfref.shfbproj]
This actually makes sense because, with VS 2015 RC CTP 6 installed, I also have .NET 4.6 RC. Looking at the files in SandCastle, it appears the last version it has reflection data for is .NET 4.5.1. I think there's a way to redirect Sandcastle, but I'm not currently familiar enough with the product-something that will probably change.
Installed:
VS 2010
VS 2010 SDK
VS 2012
VS 2012 SDK
VS 2013
VS 2013 SDK
VS 2015
VS 2015 SDK
Sandcastle Help File Builder 15.1.12.0.
Anybody know how to fix this?
--
John Merryweather Cooper
Senior Software Engineer | Integration Development Group | Enterprise Notification Service
Jack Henry & Associates, Inc.(r) | Lenexa, KS 66214 | Ext: 431050 |JoCooper@...<mailto:JoCooper@...>
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 unauthorized review, use, printing, saving, copying, disclosure or distribution
is strictly prohibited. If you have received this message in error, please
immediately advise the sender by reply email and delete all copies.

Hi all,
This may sound like a silly question, but I'm trying to get started on working against some of the bugs list. I'm looking at the source code for the UpdateMediaOnOneDisk method (InstallPackage class), and the intellisense isn't working for some of the types. It's also not allowing me to view the definition. Is it just that the document cache hasn't been built yet?
System details are Windows 8.1 Pro, and Visual Studio Professional 2013. Has anyone else experienced this problem before?
Sorry if this is a bit of a newbie question. If there's a place that would be better suited for this sort of thing, please point me in the right direction.
Regards,
Brian

That relies on the person deciding to merge the PR to not do so until after a certain date, while a branch that people base on would seem to help make that easier and less prone to mistakes, not to mention people can start piling on each other's commit history if they would happen to pull dependent work. It's a fairly common Git workflow when you have multiple trains.
Heath Stewart
Software Engineer
Visual Studio Deployment Experience, Microsoft
http://blogs.msdn.com/heaths
From: Rob Mensching [mailto:rob@...]
Sent: Wednesday, July 8, 2015 4:34 PM
To: WiX toolset developer mailing list <wix-devs@...>
Subject: Re: [WiX-devs] New branch for wix311?
You can submit pull requests against wix3/develop. That will become v3.11 after v3.10 moves to master.
_______________________________________________________________
FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/
From: Heath Stewart [mailto:Heath.Stewart@...]
Sent: Wednesday, July 8, 2015 2:41 PM
To: WiX toolset developer mailing list
Subject: [WiX-devs] New branch for wix311?
Since we're trying to lock down 3.10, can we open a branch for proposed 3.11 work? I found a bug in DTF I'd like to fix in privates at least to unblock some automation. I can always rebase later, but figured if there's bugs we know aren't release-blocking for 3.10 we could start queueing them up for 3.11.
Heath Stewart
Software Engineer
Visual Studio Deployment Experience, Microsoft
http://blogs.msdn.com/heaths

You can submit pull requests against wix3/develop. That will become v3.11 after v3.10 moves to master.
_______________________________________________________________
FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/
From: Heath Stewart [mailto:Heath.Stewart@...]
Sent: Wednesday, July 8, 2015 2:41 PM
To: WiX toolset developer mailing list
Subject: [WiX-devs] New branch for wix311?
Since we're trying to lock down 3.10, can we open a branch for proposed 3.11 work? I found a bug in DTF I'd like to fix in privates at least to unblock some automation. I can always rebase later, but figured if there's bugs we know aren't release-blocking for 3.10 we could start queueing them up for 3.11.
Heath Stewart
Software Engineer
Visual Studio Deployment Experience, Microsoft
http://blogs.msdn.com/heaths

Since we're trying to lock down 3.10, can we open a branch for proposed 3.11 work? I found a bug in DTF I'd like to fix in privates at least to unblock some automation. I can always rebase later, but figured if there's bugs we know aren't release-blocking for 3.10 we could start queueing them up for 3.11.
Heath Stewart
Software Engineer
Visual Studio Deployment Experience, Microsoft
http://blogs.msdn.com/heaths

Bob flagged 10 but I may port a couple more, so let's just say an even dozen.
Heath Stewart
Software Engineer
Visual Studio Deployment Experience, Microsoft
http://blogs.msdn.com/heaths
From: Rob Mensching [mailto:rob@...]
Sent: Tuesday, July 7, 2015 10:05 AM
To: WiX toolset developer mailing list <wix-devs@...>
Subject: Re: [WiX-devs] Marking WIPs as Complete
1. If we were to add something to the frontmatter it'd probably be better to actually put the WiX release instead of just "completed". The current process means don't have to go back and update documents again... but <shrug/>
2. Could do that. How many documents are there?
_______________________________________________________________
FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/
From: Heath Stewart [mailto:Heath.Stewart@...]
Sent: Monday, July 6, 2015 4:29 PM
To: wix-devs@...<mailto:wix-devs@...>
Subject: [WiX-devs] Marking WIPs as Complete
Rob,
>From our convo at https://github.com/wixtoolset/site/pull/53, you mentioned that WIPs can be completed. I take it that's just by way of checking the issue ID against the release. What about adding a Complete: true|false YAML header as well for quick identification?
Along the same lines, should I create feature at http://wixtoolset.org/issues to track all the docs I'll be importing and just have them reference the same number?
Heath Stewart
Software Engineer
Visual Studio Deployment Experience, Microsoft
http://blogs.msdn.com/heaths

1. If we were to add something to the frontmatter it'd probably be better to actually put the WiX release instead of just "completed". The current process means don't have to go back and update documents again... but <shrug/>
2. Could do that. How many documents are there?
_______________________________________________________________
FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/
From: Heath Stewart [mailto:Heath.Stewart@...]
Sent: Monday, July 6, 2015 4:29 PM
To: wix-devs@...
Subject: [WiX-devs] Marking WIPs as Complete
Rob,
>From our convo at https://github.com/wixtoolset/site/pull/53, you mentioned that WIPs can be completed. I take it that's just by way of checking the issue ID against the release. What about adding a Complete: true|false YAML header as well for quick identification?
Along the same lines, should I create feature at http://wixtoolset.org/issues to track all the docs I'll be importing and just have them reference the same number?
Heath Stewart
Software Engineer
Visual Studio Deployment Experience, Microsoft
http://blogs.msdn.com/heaths