Re: [WiX-users] Bootstrapper manifest
Hi Rob, we do also have the need of an elevated BA. Our BA collects all the information required for the installation in a kind of setup wizard. robmen wrote Your BootstrapperApplication should not be modifying machine state at all. The elevation is needed, because we want to check for the existence of a certain website in IIS via Microsoft.Web.Administration namespace, to either display an information that the website already exists or to request some data (like apppool user and ports) from the user. Without elevation an UnauthorizedAccessException is thrown. Is there a way to achieve this? Best regards Christian -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Bootstrapper-manifest-tp7582666p7589444.html Sent from the wix-users mailing list archive at Nabble.com. -- 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=60134791iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] [WIX-users] Patch in Wix 3.6 is empty. warning PYRO1079: The cabinet '***.cab' does not contain any files
Hello Bob, Bob Arnson-6 wrote Then please file a bug with sufficient detail to reproduce the problem. There is already a bug filed: https://sourceforge.net/p/wix/bugs/3244/ Unfortunately it was marked as expected behavior although this scenario was working in v3.5 and is not working any more since v3.6. Bob Arnson-6 wrote Obviously, WiX needs two different files to be able to diff them... That makes sense especially if WiX currently does not support to extract the files from the baseline MSIs. But I thought there may be some information contained in the wixpdb files, e.g. a CRC code, which gives a hint that the file was modified. So maybe our only chance is to wait for the diff-feature for MSI files. Best regards Christian -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/WIX-users-Patch-in-Wix-3-6-is-empty-warning-PYRO1079-The-cabinet-cab-does-not-contain-any-files-tp7335788p7587229.html Sent from the wix-users mailing list archive at Nabble.com. -- 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=48808831iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] [WIX-users] Patch in Wix 3.6 is empty. warning PYRO1079: The cabinet '***.cab' does not contain any files
Hi Guys, we are using the way of building patches as described in WiX help Patch Building Using Purely WiX, meaning that we are building the delta from the wixpdb's using torch. The only difference to the sample is that the files for the different versions are always in the same location during build of the baseline msi's. We are using a source control tool. Hence it's just not possible to place the files in another directory for each version. Since WiX 3.6 we get the mentioned warning of empty cabinet file. It looks like WiX 3.6 has some optimization in it to avoid checking for differences in files originated from the same location. That was definitely working with WiX 3.5. We are really looking forward to a solution for this issue. Christian Hennig -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/WIX-users-Patch-in-Wix-3-6-is-empty-warning-PYRO1079-The-cabinet-cab-does-not-contain-any-files-tp7335788p7587027.html Sent from the wix-users mailing list archive at Nabble.com. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Managed CustomActions not compiling with latest WiX 3.6 version
Hello, today I upgraded from WiX 3.6 Beta to version 3.6.2603.0. Now none of my managed custom actions is compileable any more. There are two problems: 1) the reference to Microsoft.Deployment.WindowsInstaller seems to be ok on the first glimpse but none of it's types is available and in the properties of the reference Version is 0.0.0.0 and Runtime Version is empty 2) for each of my CAs the following compiler error is generated: The ReadRegistry task was not found. Check the following: 1.) The name of the task in the project file is the same as the name of the task class. 2.) The task class is public and implements the Microsoft.Build.Framework.ITask interface. 3.) The task is correctly declared with UsingTask in the project file, or in the *.tasks files located in the c:\WINNT\Microsoft.NET\Framework\v4.0.30319 directory I already tried a Repair installation but that doesn't change anything. (I had the same problem with version 3.6.2520.0) Best Regards -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Managed-CustomActions-not-compiling-with-latest-WiX-3-6-version-tp7273033p7273033.html Sent from the wix-users mailing list archive at Nabble.com. -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn - Moving payload to Cache Directory
I faced the same problem with the .Net 4.0 prerequisite. It seems that the
package is actually downloaded, even though it is not uninstalled.
Here is my package declaration:
ExePackage
Id=Netfx4Full
Cache=no
Compressed=no
PerMachine=yes
Permanent=yes
Vital=yes
SourceFile=$(var.PrerequisiteLocation)\dotNetFramework\dotNetFx40_Full_x86_x64.exe
DownloadUrl=http://go.microsoft.com/fwlink/?LinkId=164193;
DetectCondition=Netfx4FullVersion AND (NOT VersionNT64 OR
Netfx4x64FullVersion) /
And here is an excerpt from the log file:
[166C:1BB0][2012-02-01T14:44:03]: Detect 24 packages
[166C:1BB0][2012-02-01T14:44:03]: Setting string variable
'Netfx4x64FullVersion' to value '4.0.30319'
[166C:1BB0][2012-02-01T14:44:03]: Setting string variable
'Netfx4FullVersion' to value '4.0.30319'
...
[166C:1BB0][2012-02-01T14:44:03]: Condition 'Netfx4FullVersion AND (NOT
VersionNT64 OR Netfx4x64FullVersion)' evaluates to true.
[166C:1BB0][2012-02-01T14:44:03]: Detected package: Netfx4Full, state:
Present, cached: No
[166C:1BB0][2012-02-01T14:44:03]: Detect complete, result: 0x0
[166C:1BB0][2012-02-01T14:44:03]: Plan 24 packages, action: Uninstall
...
[166C:1BB0][2012-02-01T14:44:03]: Planned package: Netfx4Full, state:
Present, default requested: Absent, ux requested: Absent, execute: None,
rollback: Install, cache: Yes, uncache: Yes, dependency: Register
...
[166C:1BB0][2012-02-01T14:44:03]: Plan complete, result: 0x0
[166C:1BB0][2012-02-01T14:44:03]: Apply begin
[166C:198C][2012-02-01T14:44:04]: Download engine HTTP 200 HEAD to
http://go.microsoft.com/fwlink/?LinkId=164193
[166C:198C][2012-02-01T14:44:10]: Download engine HTTP 200 GET to
http://go.microsoft.com/fwlink/?LinkId=164193
[1BC4:2A2C][2012-02-01T14:48:28]: Moving payload from working path
'C:\Users\ADMINI~1\AppData\Local\Temp\2\{c2fb7e96-b16a-4628-8d82-a939c450ac29}\Netfx4Full'
to path 'C:\ProgramData\Package
Cache\58DA3D74DB353AAD03588CBB5CEA8234166D8B99\dotNetFx40_Full_x86_x64.exe'
...
[1BC4:1E7C][2012-02-01T14:48:32]: Removing cached package:
58DA3D74DB353AAD03588CBB5CEA8234166D8B99, from path: C:\ProgramData\Package
Cache\58DA3D74DB353AAD03588CBB5CEA8234166D8B99\
[1BC4:1E7C][2012-02-01T14:48:32]: Removing cached package:
{E824C6A7-F3B1-4CB0-B820-2CC14C9F86DA}v2.4.9.5, from path:
C:\ProgramData\Package Cache\{E824C6A7-F3B1-4CB0-B820-2CC14C9F86DA}v2.4.9.5\
[1BC4:1E7C][2012-02-01T14:48:32]: Removing bundle dependency key:
{c2fb7e96-b16a-4628-8d82-a939c450ac29}
[1BC4:1E7C][2012-02-01T14:48:32]: Removing cached bundle:
{c2fb7e96-b16a-4628-8d82-a939c450ac29}, from path: C:\ProgramData\Package
Cache\{c2fb7e96-b16a-4628-8d82-a939c450ac29}\
[166C:1BB0][2012-02-01T14:48:32]: Apply complete, result: 0x0 restart: No
[166C:1BB0][2012-02-01T14:48:55]: Shutting down, exit code: 0x0
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-Moving-payload-to-Cache-Directory-tp7237441p7243219.html
Sent from the wix-users mailing list archive at Nabble.com.
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Burn: package ref-counting not working
Hi folks, as I read in the WiX 3.6 Beta release notes, burn does support package ref-counting now, which according to my understanding should guarantee, that shared packages are uninstalled only if all bundles sharing the packages were removed. Here is a little example: - install Bundle1(containing SharedPackage, Package1) - install Bundle2(containing SharedPackage, Package2) - uninstall Bundle1 -- results in removal of SharedPackage and Package1 I would expect that only Package1 gets removed. Am I just misunderstanding the feature or may I miss something in my bundle definitions? Best regards Christian -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-package-ref-counting-not-working-tp7183258p7183258.html Sent from the wix-users mailing list archive at Nabble.com. -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn: check for MSI existence and validity
Rob Mensching-7 wrote The BootstrapperApplication.xml should list all the payloads, so if you really want to do this upfront, your BA should be able to it (plus using the WixBundleOriginalPath variable). In the temporary folder I found a file BootstrapperApplicationData.xml. I guess this is what you mean. Indeed this file contains all my packages but it does neither contain the relative path of the package nor the package's SHA1 hash value. This is an example entry: WixPackageProperties Package=PACKAGEID Vital=no DisplayName=Example Package DownloadSize=7096832 PackageSize=7096832 InstalledSize=2804688 PackageType=Msi Permanent=no LogPathVariable=WixBundleLog_PACKAGEID RollbackLogPathVariable=WixBundleRollbackLog_PACKAGEID Compressed=no / -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-check-for-MSI-existence-and-validity-tp7158657p7175564.html Sent from the wix-users mailing list archive at Nabble.com. -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn: check for MSI existence and validity
In our MBA we implemented a setup wizard with a feature selection on the first step. My intention was to give a hint to the user in case of missing or invalid packages *before* he entered the necessary information and the installation actually begins. Rob Mensching-7 wrote 1. If a package cannot be found, you will get a source resolution callback. 2. At the very least Burn does a SHA1 hash of the files to verify they are correct before installing them for security reasons. If you digitally sign your payloads, Burn will verify the signatures instead of hashing (which ends up being the same thing basically). Unfortunately this does not happen until the installation started. It would be great if I could actively trigger those checks, e.g. via the IBootstrapperEngine interface. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-check-for-MSI-existence-and-validity-tp7158657p7172328.html Sent from the wix-users mailing list archive at Nabble.com. -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Burn: check for MSI existence and validity
Hi, We created several bootstrapper projects, which include some MSI packages with option Compressed='no'. As a result the MSIs have to be: 1) available on the file system at the right location (relative to the bootstrapper) and 2) available in the right version (which means it has to be exactly the same file which was used when the bootstrapper was built). Otherwise the bootstrapper fails to install. Is there a possibility to check those prerequisites from the managed bootstrapper UX library? 1) For checking the existence of the MSIs one would need the expected location of the packages relative to the bootstrapper. But in events like BootstrapperApplication.DetectPackageComplete there is no such information. 2) Here it would be useful to know what burn does to check if the MSI file is the one which was used during build. Is it a CRC check? Best regards Kryschan -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-check-for-MSI-existence-and-validity-tp7158657p7158657.html Sent from the wix-users mailing list archive at Nabble.com. -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Hidden Bundle Variables
jhennessey wrote: The bug is still open, see the submitter's comments: http://sourceforge.net/tracker/?func=detailaid=3302804group_id=105970atid=642714 http://sourceforge.net/tracker/?func=detailaid=3302804group_id=105970atid=642714 It would be great if any of the WiX developers can make a statement when this bug will be solved. I contacted the assigned developer but got no reply. Best regards Kryschan -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Hidden-Bundle-Variables-tp6605759p6903702.html Sent from the wix-users mailing list archive at Nabble.com. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Manifest for Burn Bootstrapper
Hi Rob, Rob Mensching-7 wrote: You're supposed to display UI and only elevate when the user does an action that requires it. I agree with that and I was searching for a while to find a programmatic way to reqest elevation from .Net so that I can force the BA to elevate right before it is trying to gather the information from IIS7. So I was exited to read about the IBootstrapperApplicationEngine-Elevate() method. But when i gave this a try I got a Win32Exception stating that this method is not implemented (I had no clue what it expects as hwndParent, so I tried it with the handle of my WPF window) -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Manifest-for-Burn-Bootstrapper-tp6605859p6610101.html Sent from the wix-users mailing list archive at Nabble.com. -- 10 Tips for Better Web Security Learn 10 ways to better secure your business today. Topics covered include: Web security, SSL, hacker attacks Denial of Service (DoS), private keys, security Microsoft Exchange, secure Instant Messaging, and much more. http://www.accelacomm.com/jaw/sfnl/114/51426210/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Hidden Bundle Variables
Hi! I recently upgraded to WiX 3.6.1908.0 to benefit from the hidden-feature of bundle variables. And indeed in my tests changes to hidden variables are logged without the values. But: when an MSI package is executed with such a hidden variable as parameter, the values are still logged in clear text (in arguments list). Is there something else to do besides setting the hidden attribute to yes on those variables? Best regards Kryschan -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Hidden-Bundle-Variables-tp6605759p6605759.html Sent from the wix-users mailing list archive at Nabble.com. -- 5 Ways to Improve Secure Unified Communications Unified Communications promises greater efficiencies for business. UC can improve internal communications as well as offer faster, more efficient ways to interact with customers and streamline customer service. Learn more! http://www.accelacomm.com/jaw/sfnl/114/51426253/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Manifest for Burn Bootstrapper
Hi! My bootstrapper application needs to gather some information from IIS and therefore needs to be elevated. Is it possible to embed a manifest requesting the level requireAdministrator into the bootstrapper? If yes how would this be done? Best regards Kryschan -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Manifest-for-Burn-Bootstrapper-tp6605859p6605859.html Sent from the wix-users mailing list archive at Nabble.com. -- 5 Ways to Improve Secure Unified Communications Unified Communications promises greater efficiencies for business. UC can improve internal communications as well as offer faster, more efficient ways to interact with customers and streamline customer service. Learn more! http://www.accelacomm.com/jaw/sfnl/114/51426253/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Unknown WiX variables in Bundle with WiX 3.6.1908.0
Hi, after upgrading to WiX version 3.6.1908.0 I get two errors when building a bootstrapper project using the ManagedBootstrapperApplicationHost: - The Windows Installer XML variable !(wix.WixMbaPrereqPackageId) is unknown. ... - The Windows Installer XML variable !(wix.WixMbaPrereqLicenseUrl) is unknown. ... When using WixStandardBootstrapperApplication.RtfLicense instead, the project builds. It was working in version 3.6.1817.0. Do I have to change something in my bundle or is this a bug. Best regards, Kryschan -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Unknown-WiX-variables-in-Bundle-with-WiX-3-6-1908-0-tp6574163p6574163.html Sent from the wix-users mailing list archive at Nabble.com. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Unknown WiX variables in Bundle with WiX 3.6.1908.0
Sorry but I still don't know what to do now to make my bootstrapper build again. Can you please give me a hint on that or do I have to wait for the documentation update? Best regards Kryschan Rob Mensching-7 wrote: Ug, sorry, I forgot to update the documentation about the breaking change. Yes, that is expected. Those WixVariables replace the MbaPreqNetfx Bundle/Variables used to indentify the prerequisite package and license. I'll get the documentation fixed before the next build. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Unknown-WiX-variables-in-Bundle-with-WiX-3-6-1908-0-tp6574163p6574924.html Sent from the wix-users mailing list archive at Nabble.com. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn bootstrapper as x64 exe
Kryschan wrote: I'm trying create a bootstrapper containing some 64bit MSI packages, which (of course) shall be installed on a x64 system. As the MSIs are installed in silent mode, my bootstrapper should gather the required information from the user, which also includes reading values from the windows registry. The problem is, that it seems to be not possible to compile the bootstrapper exe for x64 or at least Any CPU. Therefore on target machine it is run in WOW-mode (under 32bit) and hence can only access the 32bit registry. I am using Visual Studio 2010 together with WiX 3.6.1817.0. Am I missing something or is Burn not ment to run under 64bit? Can't anyone help me with this? I fear I will end up spawning a new process running under 64bit which then accesses the registry for my bootstrapper. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-bootstrapper-as-x64-exe-tp6495357p6528052.html Sent from the wix-users mailing list archive at Nabble.com. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
