Re: [WiX-users] WiX 3.6 beta and virus checker
Can you open a bug with this information in it? I'm not exactly sure what we'll do about it but we should at least track the issue. Yes I will do when I'm back in work. I am a bit surprised nobody has seen this; I would have thought that there would be many other corporate users with Trend OfficeScan and a similar config. Done (bug #3431068, http://sourceforge.net/tracker/?func=detailaid=3431068group_id=105970atid=642714) I wrote my own program to make a similar change in the registry and nothing happened, so I'm not sure why the burn engine 'provokes' Trend in that way. Pete -- RSA#174; Conference 2012 Save $700 by Nov 18 Register now#33; http://p.sf.net/sfu/rsa-sfdev2dev1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Managed bootstrapper application issue
Hi all, I have this issue regarding the Managed Bootstrapper application : - If I don't have .NET Framework 4 on Windows XP, it installs it and then run my .NET WPF Installation Interface. - If I don't have .NET Framework 4 on Windows 7, it installs it and then displays again the bootstrapper application instead of displaying my .NET WPF Installation Interface. If I close the installer and run it again, it loads successfully my WPF Installation Interface. In the log, the only information I have is : Loading prerequisite bootstrapper application because managed host could not be loaded. Any idea ? Thanks, Nicolas Penin -- RSA#174; Conference 2012 Save $700 by Nov 18 Register now#33; http://p.sf.net/sfu/rsa-sfdev2dev1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Question about wix fragments and componentgroupref markup
Hello, I am very new to Wix, having transitioned from Install Shield. I did run into an issue(or probably my mistake) with Wix fragments. I used heat.exe to generate 6 different Wix fragments. In each of these Wix fragments, i used the same Id for ComponentGroup. Later on, i wanted to include all of the components in these 6 different Wix fragments in Product.wxs and associate them with the *** same** *feature. However, i hit an issue as follows: error LGHT0091: Duplicate symbol (I do not have the complete message) I am using wix v 3.5. To get around this issue, i changed the ComponentGroup id's in all of the 6 different wix fragments to be unique,after which things worked as expected. Could anyone kindly clarify, if this is the expected behavior? Is there anything i could do to have the same ComponentGroup id being used in different wix fragments and then use them in Product.wxs? Thanks, Kiran Hegde -- RSA#174; Conference 2012 Save $700 by Nov 18 Register now#33; http://p.sf.net/sfu/rsa-sfdev2dev1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Question about wix fragments and componentgrouprefmarkup
Yes, that's expected. The point of the Id attribute is to distinguish between different ComponentGroups and so you can't have the same ID twice in one installer. If it helps, you can set the component group ID that heat creates using the -cg switch on the command line. -Original Message- From: Kiran Hegde [mailto:kirann.he...@gmail.com] Sent: 02 November 2011 10:29 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Question about wix fragments and componentgrouprefmarkup Hello, I am very new to Wix, having transitioned from Install Shield. I did run into an issue(or probably my mistake) with Wix fragments. I used heat.exe to generate 6 different Wix fragments. In each of these Wix fragments, i used the same Id for ComponentGroup. Later on, i wanted to include all of the components in these 6 different Wix fragments in Product.wxs and associate them with the *** same** *feature. However, i hit an issue as follows: error LGHT0091: Duplicate symbol (I do not have the complete message) I am using wix v 3.5. To get around this issue, i changed the ComponentGroup id's in all of the 6 different wix fragments to be unique,after which things worked as expected. Could anyone kindly clarify, if this is the expected behavior? Is there anything i could do to have the same ComponentGroup id being used in different wix fragments and then use them in Product.wxs? Thanks, Kiran Hegde - - RSA#174; Conference 2012 Save $700 by Nov 18 Register now#33; http://p.sf.net/sfu/rsa-sfdev2dev1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. -- RSA#174; Conference 2012 Save $700 by Nov 18 Register now#33; http://p.sf.net/sfu/rsa-sfdev2dev1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] VB6 Component Questions - JSBtnBar.ocx
Right, finally got round to implementing what you mentioned, Thank-You for your response, all is pretty much well, though the application is not loading fully, the COM components appear to be reasonably happy with their new home. -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 08 October 2011 17:31 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] VB6 Component Questions - JSBtnBar.ocx 0. heat is not perfect. Sometimes (particularly for complex COM goo like old VB requires) you have to fix it up yourself. 1. I take the heat output and clean it so it doesn't look so messy. Then I include that cleaned up file in my setup like I'd include any file I wrote from scratch. 2. heat did not correctly associate the TypeLib with the File it needs. Try nesting the TypeLib element under the File it belongs to. 3. It looks like heat got confused and tried to put a File Property reference in there instead of a Directory reference. Change those values to point to the correct Directory/@Id. 4. Personally, when getting that deep into COM goo, I spend a little time on MSDN refreshing my memory of all the registration. Then I go make sure all the registration is correct. COM can get complex quickly, but if you keep it simple the Class, ProgId, TypeLib and Interface elements make it look really pretty (better than tons of RegistryX elements smile/). On Mon, Oct 3, 2011 at 2:13 AM, David Birch (XStream Software) dav...@vale2000.com wrote: Hi all. I have one very old installer file and 2 patches created with vb6 and InstallShield. My task is to form a single, shiny new installer, without using any of the original source code (which is AWOL). I've started with a fresh XP virtual machine, using DefenseWall (a host intrusion protection system) I have identified the files that the original installer installed. A lot of it was put into the SystemFolder. I've copied it all into a subfolder in my project named SystemFolder, which itself is a child of assets. Then I've gone ahead and run `heat dir assets\SystemFolder -gg -sfrag -template fragment -svb6 -out vb6file.wxs`. I have tried copying and pasting all the components from vb6file.wxs between Directory Id=SystemFolder /Directoryof an existing (an up until that point, functional project) but am receiving a few errors, that I've been unable to troubleshoot. Firstly, and perhaps most importantly, what is the correct way to include the output file? Second, the errors begin with ... The typelib element is non-advertised and therefor require a parent File element ... which appears to originate with a component by the name of JSBtnBar.ocx. I also have 3 lots of ... The TypeLib/@HelpDirectory attribute's value, '!filBFDE46EC343B0E499B5B2D6EA1A0CC52', is not a legal identifier. Identifiers may contain ASCII characters A-Z, a-z, digits, underscores (_), or periods (.). Every identifier must begin with either a letter or an underscore. ... with various differing value's. Also, throughout the file, there are many '!fil...' RegistryValue/@Value 's that aren't mentioned, that look a little unwelcoming to my untrained eye. Please cast your expert eyes over this and point me in the right direction (help!). Kind regards, David Birch -- 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-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- 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-d2dcopy2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- RSA#174; Conference 2012 Save $700 by Nov 18 Register now#33; http://p.sf.net/sfu/rsa-sfdev2dev1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Struggling with a bootstrapper application for .NET prerequisites installation
Hi,
I have some problems with using the new burn feature. I want to create
a bootstrapper that checks for a particular .NET version and then
eventually installs the missing prerequisite before it installs my own
application.
If have two problems:
(1) The DetectCondition for my .NET Webinstaller ExePackage doesn't
work as I want it to work
I try to check the exact complete version number of the installed .NET
package. As I'm targetting .NET 3.0, I want to check if the installed
version is 3.0.30729.5420. Maybe my attempt is a little bit naive, but
from reading the documentation I couldn't find why this shouldn't work:
?xml version=1.0 encoding=UTF-8?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
xmlns:util=http://schemas.microsoft.com/wix/UtilExtension;
Bundle Name=FoobarBootstrapper Version=1.0.0.0
Manufacturer=FooBar UpgradeCode=B8B07D94-4E16-4942-8EE1-3342C5CC22CD
BootstrapperApplicationRef
Id=WixStandardBootstrapperApplication.RtfLicense /
util:RegistrySearch Id=FindDotNet30InstallRegValue Root=HKLM
Key=SOFTWARE\Microsoft\NET Framework Setup\NDP\v3.0\Setup
Value=InstallSuccess Variable=DotNet30InstallRegValue /
util:RegistrySearch Id=FindDotNet30Version Root=HKLM
Key=SOFTWARE\Microsoft\NET Framework Setup\NDP\v3.0\Setup Value=Version
Variable=DotNet30Version /
Chain
ExePackage Id=DotNet3.0 Cache=no Compressed=no Vital=yes
PerMachine=yes Name=DotNet3.0 SourceFile=DotNetFx3Setup.exe
DetectCondition=DotNet30InstallRegValue=1 AND
DotNet30Version=3.0.30729.5420/
MsiPackage Id=ClientInstall Cache=no Compressed=no
Name=FoobarInstall SourceFile=foobar.msi Vital=yes /
/Chain
/Bundle
/Wix
This is the result I get in the log file on a system that has the
desired version installed:
[0BBC:11CC][2011-11-02T12:47:18]: Setting string variable
'DotNet30InstallRegValue' to value '1'
[0BBC:11CC][2011-11-02T12:47:18]: Setting string variable 'DotNet30Version'
to value '3.0.30729.5420'
[0BBC:11CC][2011-11-02T12:47:18]: Detected related bundle:
{732f16dc-46cd-4f24-8b55-a5c4f0e9b03e}, scope: PerMachine, version: 1.0.0.0,
operation: None
[0BBC:11CC][2011-11-02T12:47:18]: Error 0x8007000d: Failed to parse condition
DotNet30InstallRegValue=1 AND DotNet30Version=3.0.30729.5420. Unexpected
character at position 47.
I also tried without the AND condition, just with the second half of
my condition, but the result is the same.
Does anybody have an idea what might be wrong here?
(2) Uninstalling always tries to remove .NET
If I just check for the presence of .NET 3.0 without checking the exact
version, I can successfully install my application on a computer where
.NET 3.0 is already installed. But when I try to uninstall the
bootstrapper, it always tries to uninstall .NET 3.0 also. As this is not
possible on Windows 7 (at least not that way), the whole uninstall
process fails and I can't uninstall my application.
Can someone explain me what I'm doing wrong here?
TIA,
Mathias
--
RSA#174; Conference 2012
Save $700 by Nov 18
Register now#33;
http://p.sf.net/sfu/rsa-sfdev2dev1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Shortcuts in the All Users Start Menu
Hi,
I have a wix project that places a shortcut in a subfolder in the users start
menu, when I change the source to set the ALLUSERS property to 1 I get the
shortcut in the correct place but the permissions of the shortcut are incorrect
resulting in users not having access to the shortcut. Only system and the
installer service account have permissions for the shortcut.
Below are the parts that I use to install the shortcut onto the start menu.
Directory Id=TARGETDIR Name=SourceDir
Directory Id=StartMenuFolder
Directory Id=MyProgramFolder Name=PROGRAM
/Directory
/Directory
/Directory
DirectoryRef Id=MyProgramFolder
Component Id=ProgramFolderShortcut Guid={GUID}
Shortcut Id=ProgramProgramFolderShortcut
Name=Program
Description=Program UI
Target=[INSTALLLOCATION]Program.exe/
RemoveFolder Id=MyProgramFolder On=uninstall/
RegistryValue Root=HKCU Key=Software\Company\ProgramUI
Name=installed Type=integer Value=1 KeyPath=yes/
/Component
/DirectoryRef
I hope someone has a solution for me
--
RSA#174; Conference 2012
Save $700 by Nov 18
Register now#33;
http://p.sf.net/sfu/rsa-sfdev2dev1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Localized Product Version
So what is the correct usage of Localizable=no as an attribute of String? Are loc files not effectively just a string table, which are conveniently localizable? I too use localised version numbers, the reason being we release the same software in different markets/countries under different names, some of which started at version 1 relatively recently. For example, our website creation software was version 11 in the UK, but under a different name as version 4 in the Netherlands. To acheive this I used (in WiX 2) a different product version in the Dutch (localized?) string table (1043.wxl). Perhaps this error reported by candle could be moved to a warning, allowing people like me to build despite the version info not complying with the x.x.x.x convention? Or add a new switch in the candle.exe call to allow for this error to be ignored? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Localized-Product-Version-tp2386947p6955742.html Sent from the wix-users mailing list archive at Nabble.com. -- RSA#174; Conference 2012 Save $700 by Nov 18 Register now#33; http://p.sf.net/sfu/rsa-sfdev2dev1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Localized Product Version
We also reference the same localized string to write the version number to the registry so we can query it as a potential launch condition for other products, ie. This package will only install if so and so is version x or above. Hardcoding it requires a synchronized change in several places rather than a single wxl file. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Localized-Product-Version-tp2386947p6955974.html Sent from the wix-users mailing list archive at Nabble.com. -- RSA#174; Conference 2012 Save $700 by Nov 18 Register now#33; http://p.sf.net/sfu/rsa-sfdev2dev1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Error with InstallUtilLib.dll: CoreBindToRuntimeHost path not found error.
Hi, I have a merge module that was authored using the VisualStudio 2010 installer and this MSM installs a windows server and has a custom action that registers the service using the InstallUtil program. However, when I use that MSM in a MSI authored using WiX 3.5, I get the following error on installation: Error 1001. InstallUtilLib.dll: CorBindToRuntimeHost (hr=0x80070003): The system cannot find the path specified. .Net4 is already installed on the machine. When the MSM was included in a MSI authored using the VS2010 installer tool the problem did not occur. I needed to move from the VS2010 installer to a WiX installer to allow for more flexibility. Any ideas as to what the cause of this is? -- RSA#174; Conference 2012 Save $700 by Nov 18 Register now#33; http://p.sf.net/sfu/rsa-sfdev2dev1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Patch with a simple file change
[Sorry if you got this twice, I think I botched posting via Nabble the previous time] Hi, I tried the patching example given at http://wix.sourceforge.net/manual-wix3/wix_patching.htm but I changed it so the source-path points to a single file in both versions (1.0 vs 1.1), and I just change the file contents of the text file between building each installer. In other words, I compile the 1.0 installer, change the text file, compile the 1.1 installer, then make the MSP. This is more like what I'd be doing at work. The problem is, if I use the file contents given in the tutorial or anything similar (old: This is version 1.0, new: This is version 1.1) then it misses the file in the patch. It doesn't even include it in the CAB (I get an empty CAB warning). If I make the new value file drastically different (e.g. add a sentence or two more) then it detects the change and puts the file into the patch. Apparently this only happens using pyro/torch, and not when going the patchwiz rout. Anyone know, is this simply a known characteristic of the hashing algorithm used to detect changes? Is there a workaround to have it do a better comparison (perhaps an exact comparison)? I don't want a config file to be missed someday because it only differed slightly from the previous version. Thanks. - John Burak -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patch-with-a-simple-file-change-tp6956231p6956231.html Sent from the wix-users mailing list archive at Nabble.com. -- RSA#174; Conference 2012 Save $700 by Nov 18 Register now#33; http://p.sf.net/sfu/rsa-sfdev2dev1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Error with InstallUtilLib.dll: CoreBindToRuntimeHost path not found error.
I have heard that there is an issue with VS 2010 merge modules where they always install files to the Module Retargetable Folder instead of the intended one. That may have something to do wth it. Other issues may occurr when InstallUtilLib.dll is 32-bit and you attempt to use it on a 64-bit system. If there is any way you can re-build that merge module, you should do it. Even in the dubious world of using installer classes to install services you never needed to run InstallUtil.exe. The setup will call installer class custom actions without running InstallUtil.exe. There's nothing that special about .NET services, so if possible convert that merge module to WiX and use the built-in ServiceInstall elements that populate the ServiceInstall table in the MSI file. Phil From: Aled Hughes [trestlemon...@gmail.com] Sent: Wednesday, November 02, 2011 10:34 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Error with InstallUtilLib.dll: CoreBindToRuntimeHost path not found error. Hi, I have a merge module that was authored using the VisualStudio 2010 installer and this MSM installs a windows server and has a custom action that registers the service using the InstallUtil program. However, when I use that MSM in a MSI authored using WiX 3.5, I get the following error on installation: Error 1001. InstallUtilLib.dll: CorBindToRuntimeHost (hr=0x80070003): The system cannot find the path specified. .Net4 is already installed on the machine. When the MSM was included in a MSI authored using the VS2010 installer tool the problem did not occur. I needed to move from the VS2010 installer to a WiX installer to allow for more flexibility. Any ideas as to what the cause of this is? -- RSA#174; Conference 2012 Save $700 by Nov 18 Register now#33; http://p.sf.net/sfu/rsa-sfdev2dev1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users *** Confidentiality Notice: This e-mail, including any associated or attached files, is intended solely for the individual or entity to which it is addressed. This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify the sender immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person. This email comes from a division of the Invensys Group, owned by Invensys plc, which is a company registered in England and Wales with its registered office at 3rd Floor, 40 Grosvenor Place, London, SW1X 7AW (Registered number 166023). For a list of European legal entities within the Invensys Group, please go to http://www.invensys.com/en/legal/default.aspx. You may contact Invensys plc on +44 (0)20 3155 1200 or e-mail recept...@invensys.com. This e-mail and any attachments thereto may be subject to the terms of any agreements between Invensys (and/or its subsidiaries and affiliates) and the recipient (and/or its subsidiaries and affiliates). -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Heat -generate
David L. Beckwith wrote: Yes, unfortunately that is what the custom action in the msi is doing. I could have sworn I tried the payloads under the BootstapperApplication element, but I'll check again. Rob Mensching-7 wrote: I'm a little confused. Are you saying the custom action is using the current working folder to find files? If so, that won't work out most of the time or rather it will work in very limited situations. If you want Payloads cached with the bootstrapper, you can add additional Payload elements under the BootstrapperApplication element. If you don't want them compressed mark them Compressed=no. I remember why this did not work. The dlls need to be in the location of the bootstrapper, not the cache location. Argh! I've given up this approach. The real solution here is a change in the MSI which I have no control. Another possibility is to use the bootstrapper that comes with this install which I suspect changes the working directory. I tried this a while ago but couldn't figure out how to create folders and designate which payload goes to what folder for burn. I also wasn't sure if an msi payload would be harvested like it is in an msiPackage. The other four chained packages work great! -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Heat-generate-tp6909632p6956991.html Sent from the wix-users mailing list archive at Nabble.com. -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Handling MSI with size more than 2GB using multiple embedded Media/Cab file
Hi, I have an MSI Installer which is generated using Wix and the size of MSI is 2GB so I have written multiple media tags having multiple embedded cab files, no error are shown during generation of MSI. But when I try to install MSI I am getting an error saying the system cannot open the device or file specified. Media Id=1 Cabinet=contents.cab EmbedCab=yes CompressionLevel=none / Media Id=2 Cabinet=contents2.cab EmbedCab=yes CompressionLevel=none / Can someone please suggest how to resolve this issue? Thanks Regards Narasimha Reddy -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Error with InstallUtilLib.dll: CoreBindToRuntimeHost path not found error.
Indeed, ideally the merge module should be rebuilt. At the moment that isn't possible, however with a bit of help from 'dark' and installation log files I've found what appears to be a solution to the problem. MSMs built with Visual Studio Deployment tool which use this InstallUtil (which installs services) require the some additional support files and properties to be set-up - basically it seems a .config file is required for the custom action that calls InstallUtil, and this config file is specified in the property VSDFxConfigFile. Here's the custom action from the msm: CustomAction Id=_A4F7837B_2392_4158_813E_D7618531FAEA.install.SetProperty Property=_A4F7837B_2392_4158_813E_D7618531FAEA.install Value=/installtype=notransaction /action=install /LogFile= quot;[#_F3A6C070A322F89D287883E856E3F8EA.809DF207E0AD42C087209A70CE3641DD]quot; quot;[VSDFxConfigFile]quot; / So to provide that config file [VSDFxConfigFile], I used dark to extract two binary files from a MSI created using VS Deployment tool: * VSDNETCFG - this is the app.config file * MSVBDPCADLL - a custom action DLL that reads various VSDxxx properties and sets the VSDFxConfigFile property Once I had those files, I added these lines in to my Wix project file (that references the merge module). Binary Id=VSDNETCFG SourceFile=SupportFiles\VSDNETCFG/ Binary Id=MSVBDPCADLL SourceFile=SupportFiles\MSVBDPCADLL/ Property Id=VSDFrameworkVersion Value=v4.0 / Property Id=VSDFrameworkProfile Value=Client / Property Id=VSDNETMSG Value=This setup requires the .NET Framework version [1]. Please install the .NET Framework and run this setup again. / Property Id=VSDNETURLMSG Value=This setup requires the .NET Framework version [1]. Please install the .NET Framework and run this setup again. The .NET Framework can be obtained from the web. Would you like to do this now? / CustomAction Id=DIRCA_CheckFX Return=check BinaryKey=MSVBDPCADLL DllEntry=CheckFX / CustomTable Id=_VsdLaunchCondition Column Id=Condition PrimaryKey=yes Type=string Width=255 Category=Condition Description=Expression which must evaluate to TRUE in order for install to commence. Modularize=Condition / Column Id=Description Type=string Width=255 Localizable=yes Category=Formatted Description=Localizable text to display when condition fails and install must abort. Modularize=Property / Column Id=Url Type=string Width=0 Category=Text Description=URL to navigate to when condition fails and install must abort. / Row Data Column=ConditionVSDFXAvailable/Data Data Column=Description[VSDNETURLMSG]/Data Data Column=Url http://go.microsoft.com/fwlink/?LinkId=131000/Data /Row /CustomTable Then in InstallExecuteSequence / InstallUISequence I call that custom action: InstallExecuteSequence Custom Action=DIRCA_CheckFX Sequence=2 / /InstallExecuteSequence At least this stops the error 1001 occurring (I've not yet verified that the service installed by the MSM is actually working!) On 2 November 2011 19:34, Wilson, Phil phil.wil...@invensys.com wrote: I have heard that there is an issue with VS 2010 merge modules where they always install files to the Module Retargetable Folder instead of the intended one. That may have something to do wth it. Other issues may occurr when InstallUtilLib.dll is 32-bit and you attempt to use it on a 64-bit system. If there is any way you can re-build that merge module, you should do it. Even in the dubious world of using installer classes to install services you never needed to run InstallUtil.exe. The setup will call installer class custom actions without running InstallUtil.exe. There's nothing that special about .NET services, so if possible convert that merge module to WiX and use the built-in ServiceInstall elements that populate the ServiceInstall table in the MSI file. Phil From: Aled Hughes [trestlemon...@gmail.com] Sent: Wednesday, November 02, 2011 10:34 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Error with InstallUtilLib.dll: CoreBindToRuntimeHost path not found error. Hi, I have a merge module that was authored using the VisualStudio 2010 installer and this MSM installs a windows server and has a custom action that registers the service using the InstallUtil program. However, when I use that MSM in a MSI authored using WiX 3.5, I get the following error on installation: Error 1001. InstallUtilLib.dll: CorBindToRuntimeHost (hr=0x80070003): The system cannot find the path specified. .Net4 is already installed on the machine. When the MSM was included in a MSI authored using the VS2010 installer tool the problem did not occur. I needed to move from the VS2010 installer to a WiX installer to allow for more flexibility. Any ideas as to what the cause of this is?
[WiX-users] .NET 4 Prereq using burn
I was looking at the wix installer for help on using burn however the .net 4 prerequisite isn't working for me. It says it can't find the source file when I have specified the download url. Is there something I am missing? Dieter Lunn http://ubiety.ca -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Heat -generate
OK, I'm back where I started. Basically, heat does not create a PayloadGroup with -generate. If that option was available this thread would probably not be here. The help says: Specify what elements to generate, one of: components, container, payloadgroup, layout (default is components). However, it only produces components. The default is the only option which means there is no option. So here is my next harvest question... I know the external files are automatically harvested in the msiPackage element. Is there a way to get this from heat? Or is there an option with dark? I'm at that point where I manually created payloads that the legacy setup needs. It includes an msi that needs 135 other external files. It is error prone attempting to do this by hand at the least and a chore regardless. David L. Beckwith wrote: David L. Beckwith wrote: Yes, unfortunately that is what the custom action in the msi is doing. I could have sworn I tried the payloads under the BootstapperApplication element, but I'll check again. Rob Mensching-7 wrote: I'm a little confused. Are you saying the custom action is using the current working folder to find files? If so, that won't work out most of the time or rather it will work in very limited situations. If you want Payloads cached with the bootstrapper, you can add additional Payload elements under the BootstrapperApplication element. If you don't want them compressed mark them Compressed=no. I remember why this did not work. The dlls need to be in the location of the bootstrapper, not the cache location. Argh! I've given up this approach. The real solution here is a change in the MSI which I have no control. Another possibility is to use the bootstrapper that comes with this install which I suspect changes the working directory. I tried this a while ago but couldn't figure out how to create folders and designate which payload goes to what folder for burn. I also wasn't sure if an msi payload would be harvested like it is in an msiPackage. The other four chained packages work great! -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Heat-generate-tp6909632p6957400.html Sent from the wix-users mailing list archive at Nabble.com. -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] .NET 4 Prereq using burn
On 02-Nov-11 17:37, Dieter Lunn wrote: I was looking at the wix installer for help on using burn however the .net 4 prerequisite isn't working for me. It says it can't find the source file when I have specified the download url. Is there something I am missing? You still need to specify a local source, so WiX can get size and hash information. -- sig://boB http://joyofsetup.com/ -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn Chain Packages and Upgrading
On 01-Nov-11 21:35, Phong wrote: When I say fail, I mean the Chain_version2.exe will kick off the Chain_version1.exe (from cache, to do the uninstall?) and wait for users to click through the Chain_version1.exe steps of uninstall. Burn (at least in the current version) asks the older bundle to uninstall itself with the -quiet switch, which shouldn't show UI or prompt the user. That's up to the bootstrapper application to handle correctly. -- sig://boB http://joyofsetup.com/ -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Localized Product Version
On 02-Nov-11 11:43, Gareth wrote: So what is the correct usage of Localizable=no as an attribute of String? It might be helpful to quote a message you're replying to, especially when it's 2.5 years old.g @Localizable is ignored; it's documentation for people doing the loc work. Perhaps this error reported by candle could be moved to a warning, allowing people like me to build despite the version info not complying with the x.x.x.x convention? Or add a new switch in the candle.exe call to allow for this error to be ignored? Sure, please file a feature request. -- sig://boB http://joyofsetup.com/ -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Managed bootstrapper application issue
On 02-Nov-11 04:45, Nicolas Penin wrote: I have this issue regarding the Managed Bootstrapper application : Which version of WiX are you using? In the log, the only information I have is : Loading prerequisite bootstrapper application because managed host could not be loaded. Is there an error code? -- sig://boB http://joyofsetup.com/ -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Missing files in http://wix.sourceforge.net/releases/
On 31-Oct-11 09:00, Albert van Peppen wrote: When will the next (weekly release?) version appear on Codeplex? Not for a while. We want people to use the beta, after all. And at the moment, we need to figure out how to automate the weekly drops; I'm not sure we want to put them all on Codeplex. And is it possible to mention a buildnumber of the beta available? I updated the release notes. -- sig://boB http://joyofsetup.com/ -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Struggling with a bootstrapper application for .NET prerequisites installation
On 02-Nov-11 07:55, Mathias Bauer wrote:
[0BBC:11CC][2011-11-02T12:47:18]: Setting string variable
'DotNet30InstallRegValue' to value '1'
[0BBC:11CC][2011-11-02T12:47:18]: Setting string variable 'DotNet30Version'
to value '3.0.30729.5420'
[0BBC:11CC][2011-11-02T12:47:18]: Detected related bundle:
{732f16dc-46cd-4f24-8b55-a5c4f0e9b03e}, scope: PerMachine, version: 1.0.0.0,
operation: None
[0BBC:11CC][2011-11-02T12:47:18]: Error 0x8007000d: Failed to parse condition
DotNet30InstallRegValue=1 AND DotNet30Version=3.0.30729.5420. Unexpected
character at position 47.
Try putting a v in front of the version number; Burn then treats it
explicitly as a version.
(2) Uninstalling always tries to remove .NET
Add @Permanent=yes to the ExePackage.
--
sig://boB
http://joyofsetup.com/
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patch with a simple file change
On 02-Nov-11 13:44, john.burak wrote: Anyone know, is this simply a known characteristic of the hashing algorithm used to detect changes? It's not a hash: If two files are the same length, the binder does a byte-by-byte comparison. If you can repro this with a simple case, please file a bug. -- sig://boB http://joyofsetup.com/ -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Shortcuts in the All Users Start Menu
On 02-Nov-11 09:10, Kjartan Þór Kjartansson wrote: I have a wix project that places a shortcut in a subfolder in the users start menu, when I change the source to set the ALLUSERS property to 1 I get the shortcut in the correct place but the permissions of the shortcut are incorrect resulting in users not having access to the shortcut. Only system and the installer service account have permissions for the shortcut. That's expected: It's in a per-machine location so normal users can't modify them. -- sig://boB http://joyofsetup.com/ -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Heat -generate
On 02-Nov-11 19:28, David L. Beckwith wrote: I know the external files are automatically harvested in the msiPackage element. Is there a way to get this from heat? No, they're entirely separate processes. Or is there an option with dark? Not that I know of. -- sig://boB http://joyofsetup.com/ -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Handling MSI with size more than 2GB using multiple embedded Media/Cab file
On 02-Nov-11 17:25, Reddy, Narasimha wrote: I have an MSI Installer which is generated using Wix and the size of MSI is2GB so I have written multiple media tags having multiple embedded cab files, no error are shown during generation of MSI. I'm not sure you'll be able to get an .msi bigger than 2gb working. Try it with the cabinets external. -- sig://boB http://joyofsetup.com/ -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn Chain Packages and Upgrading
Thanks Bob, I do have my own custom bootstrapper application. Is there a hook that I can use so that if the bootstrapper app was called to Uninstall with the -quiet switch, I can just call Engine.Plan(Uninstall), then exit before my UI code loads? Thanks, Phong On Wed, Nov 2, 2011 at 6:14 PM, Bob Arnson b...@joyofsetup.com wrote: On 01-Nov-11 21:35, Phong wrote: When I say fail, I mean the Chain_version2.exe will kick off the Chain_version1.exe (from cache, to do the uninstall?) and wait for users to click through the Chain_version1.exe steps of uninstall. Burn (at least in the current version) asks the older bundle to uninstall itself with the -quiet switch, which shouldn't show UI or prompt the user. That's up to the bootstrapper application to handle correctly. -- sig://boB http://joyofsetup.com/ -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] .NET 4 Prereq using burn
Ok. I shall download and add it then. Dieter Lunn http://ubiety.ca On Wed, Nov 2, 2011 at 8:27 PM, Bob Arnson b...@joyofsetup.com wrote: On 02-Nov-11 17:37, Dieter Lunn wrote: I was looking at the wix installer for help on using burn however the .net 4 prerequisite isn't working for me. It says it can't find the source file when I have specified the download url. Is there something I am missing? You still need to specify a local source, so WiX can get size and hash information. -- sig://boB http://joyofsetup.com/ -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
