Re: [WiX-users] Moving existing MSI based setup to WiX roadmap
Stas Klyachkovsky wrote: > > Could somebody share his/her experience w/ such conversion? > Provided you're starting from an InstallShield MSI project, it's actually fairly straight-forward to do - should take you about a week to port a mid-complexity (I know, what sort of definition is that :-) setup. Some thoughts: * InstallScript needs to be ported to C++-or-similar custom actions (CAs). Better off if you have no InstallScript in the first place, but provided the InstallScript is non-GUI, this is perfectly doable. * Any existing InstallScript-controlled GUI will need to be redesigned. This will be a fun task for non-trivial GUIs, and, unless you have the time/inclination to do it, IMO it's a good reason to *not* port an IS installer to WiX. One option is to write the installer-wizard GUI separately from the installer itself. * Automated component-info extraction is harder to do in WiX (I'm thinking COM object & directory harvesting here), although more flexible (i.e. *you* get to write some of the .wxs-creation code). * WiX's pre-processor means your single-source project can build both 32-bit and 64-bit installers, woohoo! cheers, Karim -- View this message in context: http://www.nabble.com/Moving-existing-MSI-based-setup-to-WiX-roadmap-tp15569833p15596175.html Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] wix 3.0 : what should I use instead of "AssemblyRegisterComInterop" ?
Michal Peled wrote: > > I need to get my installation to register a .NET assembly in the way > that "regasm /tlb" does. > > I saw an example for such a thing in Rob's blog, using the > "[EMAIL PROTECTED]" attribute (set to "yes"). > Hi Michal, You can use heat with a -scom flag to extract the assembly's COM information as registry keys, the down side being that it'll need to be done whenever the assembly changes. cheers, Karim -- View this message in context: http://www.nabble.com/wix-3.0-%3A-what-should-I-use-instead-of-%22AssemblyRegisterComInterop%22---tp15264475p15267858.html Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall a Website
I'll probably not use the WiX CAs to install my website (I'm sorely tempted to!), purely because I'm worried about the possible fragility and don't want to risk it in a production environment. An alternative method that I've used is to create a new metabase property, specifically for tracking my web-site. It works fine (means that users can fiddle with web-site port etc. to their heart's content, and keeps the web-related info in one place: IIS), although any minute now I'm expecting someone to tell me how unwittingly evil I am... :0) If WiX were to follow this approach then only mad metabase-hackers would be able to ruin things (in which case, good luck to 'em). Karim Mike Dimmick-2 wrote: > > To add to Rob's extremely terse answer ;) the IIS custom actions use the > IP > address/port/Host header tuple to discover the internal website ID for the > site. Unfortunately there's no special place to store in the metabase that > the website/virtual directory was installed by WiX - not even a field that > we can repurpose, because all the fields accessible through the metabase > API > are editable in the UI and can therefore be broken by the user. > > Windows Installer does not persist values that properties acquire during > installation. The only thing it remembers is the key path of every > component > that's installed, and I'm not sure that it sets the directory properties > to > match. Any property whose value can be changed which you rely on during > maintenance or uninstall must be persisted somehow by you and reloaded > appropriately. > > That said, I think WiX is going to have to bite the bullet here and > actually > record the site ID in the registry somewhere. I would propose HKLM/HKCU > (depending on value of ALLUSERS)\Software\Microsoft\Windows Installer > XML\Properties\{component GUID} as a suitable location. We might want to > record the product code as well in case the same website component is > installed to different locations by different products. While it would be > nice to use the Registry table to do this, I fear it would cause problems > with multiple definitions of components (assuming you added the new value > to > the same component that contained the website). > > I realise this goes against the WiX philosophy of only installing exactly > what the source says - it's remarkably clean in that respect - but right > now > the IIS custom actions seem very fragile. > > -- > Mike Dimmick > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Rob > Mensching > Sent: 21 December 2007 11:10 > To: Meyrignac, Jean-Charles > Cc: wix-users@lists.sourceforge.net > Subject: Re: [WiX-users] Uninstall a Website > > What is the value for your PORT property during uninstall? > > Meyrignac, Jean-Charles wrote: >> >> I have a weird bug while uninstalling a website on Windows XP, using >> the MSI installer: when the application is uninstalled, *IIS is >> completely* *broken*. >> >> Here is the part installing my web site: >> > > > > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > -- View this message in context: http://www.nabble.com/Uninstall-a-Website-tp14378768p15140981.html Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wix Integer Variables
Cryptonomicon wrote: > > I am guessing that > > > and > > Guid="C4AB05E7-BE8D-40F2-891F-583750779D05" DiskId="1" Win64=$(var.Is64)> > > will cause pain grief and misery? > Not for me it didn't :) I tried this (actually: Win64="$(var.Win64)"), got the squiggly blue lines and gave up for other things. Then a while later I actually thought about it and tried pressing Compile. Sure enough it all works fine! Makes it all very easy to have a single source for compiling up 32-/64-bit installers. I also have a Guid="$(var.Guid)" line (referring to a fragment-local Guid variable) in each 32-/64-bit component, as I think otherwise there's scope for messing up component rules. Cryptonomicon wrote: > > or is there a variation on > > > > > I have missed? > Getting rid of the squiggly blue lines would be even better so I'd be interested in an answer to this too! -K -- View this message in context: http://www.nabble.com/Wix-Integer-Variables-tf4730515.html#a13528211 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Heat with self-registration dlls!
Sajo Jacob wrote: > > Thanks! that explains the exe's but how about the dlls with this issue? > 64-bit DLLs? I don't know how heat.exe even manages to load and call DllRegisterServer on 64-bit DLLs (it's a 32-bit .exe in the WiX download), but it definitely doesn't produce what you'd expect. However, running heat against the 32-bit version of the DLL produces the right output, and the resultant Component can then simply be marked as Win64="yes". Karim -- View this message in context: http://www.nabble.com/Heat-with-self-registration-dlls%21-tf4727548.html#a13526933 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] What's the right way to use InstallExecuteSequence from a fragment?
Bob Arnson-6 wrote: > > That's be design: Light is a "smart linker," so it brings in only those > fragments that are referenced. There are a number of *Ref elements that > create such references but not a sequence reference. That's a little odd > -- usually, you'd want to include a custom action with any scheeduling, > so CustomActionRef does the trick. > > You can use another *Ref, like PropertyRef, too. > Thanks for the info guys. I guess I may reorganise the project in this way in future, but until then I'll just forcefully include the fragment with obviously-named dummy custom-actions and refs :) Karim -- View this message in context: http://www.nabble.com/What%27s-the-right-way-to-use-InstallExecuteSequence-from-a-fragment--tf4698457.html#a13473820 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] What's the right way to use InstallExecuteSequence from a fragment?
Hello, This may be a misunderstanding of how WiX is supposed to work. Basically... I have a Fragment file, InstallExecuteSequence.wxs, that contains only an InstallExecuteSequence node: My problem is that this sequence doesn't by default get included within anything I build. E.g.: candle InstallExecuteSequence.wxs candle SequenceTest.wxs (<= generated by Votive, with an appropriate node). light -out test.msi InstallExecuteSequence.wixobj SequenceTest.wixobj + look at test.msi in orca => InstallExecuteSequence table doesn't contain the SetProp1 CA. The workaround is easy enough: stick a dummy inside InstallExecuteSequence.wxs and a matching in SequenceTest.wxs, but does anyone know the proper way to get InstallExecuteSequence.wixobj linked into test.msi, or am I missing something..? thanks for any help, Karim -- View this message in context: http://www.nabble.com/What%27s-the-right-way-to-use-InstallExecuteSequence-from-a-fragment--tf4698457.html#a13431009 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Easy WiX way for a custom action to call multiple utility DLLs?
Rob Mensching-5 wrote: > > I'm admittedly hardcore about this but IMHO custom actions should be > native code DLLs that have as few dependencies as physically possible > (certainly should have no dependency on WTL). Statically linking the > CRT then use as few DLLs from the system provides the highest > probability that the code will work in the most number of environments. > Agreed, although I think that Aris was just giving his WTL app as an example of static linking seeming not to work properly, as opposed to actually using WTL within a CA (off the top my head, I can't think when you'd want to do this). It's OT but wrt your WTL prob Aris, might you have missed some other dependency? (Depends.exe v. handy here). Aris Green-2 wrote: > > Try embedding the other DLL as a custom resource using the .rc file. > Extract the DLL first thing when the CA is called. Use delayload linker > option or > LoadLibrary to call the function in the extracted DLL. I've done this > before. > Not what I was looking for, but thanks for the tip Aris: I hadn't considered this approach. -- View this message in context: http://www.nabble.com/Easy-WiX-way-for-a-custom-action-to-call-multiple-utility-DLLs--tf4683485.html#a13425076 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] wix 2.0 to 3.0 - COM registration
Strele Franz-2 wrote: > > You can use the 'undocumented' "-scom" switch with heat.exe to generate > only RegistryKey/RegistryValue-entries (instead of Class/ProgId/...). > Many thanks Stele, for both posts: the -scom switch works perfectly & I can use it guilt-free! I wonder if there's a feature-request for heat.exe to automatically use -scom for .NET COM libs..? :0) Karim -- View this message in context: http://www.nabble.com/wix-2.0-to-3.0---COM-registration-tf4682182.html#a13408895 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] wix 2.0 to 3.0 - COM registration
Nitin Chaudhari wrote: > > All my DLL's are .net assembly but they can be registered as COM. > Sorry, I should've looked more closely at your registry entries. FWIW, here's my take on the problem: http://www.nabble.com/heating-COM-componnents-and-getting-LGHT0130-on-generated-registry-data-tf2815472.html#a13239912 http://www.nabble.com/heating-COM-componnents-and-getting-LGHT0130-on-generated-registry-data-tf2815472.html#a13239912 I think that the problem is shared between heat.exe and candle.exe, and came to the conclusion that unless WiX is tweaked to specifically consider COM-registerable .NET assemblies then large numbers of registry keys end up being the cleanest solution. -- View this message in context: http://www.nabble.com/wix-2.0-to-3.0---COM-registration-tf4682182.html#a13384750 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] x64 and ProgramFilesFolder vs. ProgramFiles64Folder
Geoff Finger-2 wrote: > > The specific problem in this case is the x64 installer was working > just fine but someone pointed out that one of the files was 32 bit and > thus should be installed to "Program Files (x86)" instead of the > normal Program Files folder. > On 64-bit Windows, ProgramFiles64Folder will evaluate to "Program Files" & ProgramFilesFolder to "Program Files (x86)". AFAIK you need to duplicate your directory hierarchies: it won't happen automatically: ... ... Geoff Finger-2 wrote: > > I have " InstallerVersion="200" Compressed="yes" Platforms="x64"" in > the Package element, and "Win64="yes"" for all the components (except > the one that's _supposed_ to end up in the x86 folder of course.) > This sounds right. -Karim -- View this message in context: http://www.nabble.com/x64-and-ProgramFilesFolder-vs.-ProgramFiles64Folder-tf4680463.html#a13383179 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Easy WiX way for a custom action to call multiple utility DLLs?
If my CA in MyCA.dll needs to call a fn in MyUtils.dll then I'm currently expecting to have to write a separate pair of CAs that pull MyUtils.dll out of the Binary table and then delete it at end-of-setup. InstallShield provides just such a handy pair of Custom Actions (ISSETUPFILESEXTRACT & co.), and I was wondering if there's any WiX equivalent? tia, Karim -- View this message in context: http://www.nabble.com/Easy-WiX-way-for-a-custom-action-to-call-multiple-utility-DLLs--tf4683485.html#a13382997 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] wix 2.0 to 3.0 - COM registration
Not a direct answer, but if you run WiX 3.0's heat.exe against your 32-bit COM DLLs then it'll generate the right Class, AppID, Interface etc. output. -- View this message in context: http://www.nabble.com/wix-2.0-to-3.0---COM-registration-tf4682182.html#a13382551 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Re gistering 64-bit Assembly
peteyates wrote: > > fatal error LGHT0003: primary key 'regF857F4F67D6475833875D0C4140FEA > 99' in column 'Registry' are duplicated in table 'Registry' > Caused by your .wixobj file containing two elements that refer to the same key+value. Look at the appropriate .wixobj file to figure out the exact cause of the error. peteyates wrote: > > I have also been trying to use heat to generate a fragment, but when i > try to compile the MSI I get an error from Candle as follows: > > error CNDL0005 : The Component element contains an unexpected child > element 'RegistryValue'. > > The output does not contain a parent Registry element. > Prob. Heat generates Wixv3-style Registry entries, which Wixv2 light.exe doesn't like..? peteyates wrote: > > I am sure I am missing something simple, but if anyone can advise how I > can register a 64-bit assembly in WIX 2 I would be very grateful. > Tallow probably isn't creating valid .wxs output from regasm's output - run it directly against your assembly with the -c option. -- View this message in context: http://www.nabble.com/Registering-64-bit-Assembly-tf4647422.html#a13282325 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] heating COM componnents and getting LGHT0130 on generated registry data
Karthik wrote: > > The problem is that autogenerated Id is not unique. It should be simple to > write a temporary postprocessor that goes through and adds Id="[unique > value]" to each RegistryValue element. > Thank you for your reply Karthik. I don't think this is the problem, as each generated Id seems to be unique to a given registry path+value. This seems sensible, as you wouldn't normally want to be writing from the reg-table to the same reg-value twice in the same setup. -- View this message in context: http://www.nabble.com/heating-COM-componnents-and-getting-LGHT0130-on-generated-registry-data-tf2815472.html#a13250236 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] heating COM componnents and getting LGHT0130 on generated registry data
Bob Arnson-6 wrote: > > Karim MacDonald wrote: >>> would replace the element, or if this particular Heat bug (think >>> I >>> saw it logged but can't find it now!) is likely to be fixed any time >>> soon? > > So far, nobody's volunteered to maintain Heat so the bug isn't likely to > fixed soon. > I may see if I can fix this particular bug on my own system. I don't know how patch submissions work, but naively expect that I might then be able to submit a patch for inclusion at some date? Bob Arnson-6 wrote: > > Both are bad because they violate component rules. > Could you be more specific about which rules they break please Bob? I've checked MSDN and although the same registry value is being written to twice, I can't see a component rule problem as long as this all happens within one component. Bob Arnson-6 wrote: > > Is it not enough to remove the mscoree.dll InprocServer32 value? > Unfortunately the mscoree.dll value is correct & not the problem: it's needed so that COM knows to prod .NET when the object is CoCreated. The root problem (I think) is that Heat is wrongly guessing the content of that registry value when it doesn't need to. A clean work-around would be a short dark.exe segue and then ditch the element from the authored code (I might do this). -- View this message in context: http://www.nabble.com/heating-COM-componnents-and-getting-LGHT0130-on-generated-registry-data-tf2815472.html#a13250119 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] heating COM componnents and getting LGHT0130 on generated registry data
Karim MacDonald wrote: > > > Eric Hybner wrote: >> >> Thanks Bob. FWIW, the problem appears to be with a default value. >> Removing the following registry value gets me past the issue for now. >> >> > Key="CLSID\{01D6FA3C-BCF4-35AB-820A-49ACAF99F5F8}\InprocServer32" >> Value="mscoree.dll" Type="string" Action="write" /> >> > > Does anyone know if there is a workaround to this problem that is better > than manually writing all of the appropriate elements that > would replace the element, or if this particular Heat bug (think I > saw it logged but can't find it now!) is likely to be fixed any time soon? > Found a couple of alternatives, neither of them nice: 1. Give a unique Id to the mscoree RegistryValue (which will result in the value being overwritten by two separate Registry table entries): 2. Advertise the component (=> the reg-entries will be written by the RegisterClassInfo action I think) and then forcefully zero its Darwin descriptor (WriteRegistryValues occurs after RegisterClassInfo by default): ... I've no idea which of these is better or worse; comments gratefully received... -- View this message in context: http://www.nabble.com/heating-COM-componnents-and-getting-LGHT0130-on-generated-registry-data-tf2815472.html#a13239912 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] heating COM componnents and getting LGHT0130 on generated registry data
Hello, Eric Hybner wrote: > > Thanks Bob. FWIW, the problem appears to be with a default value. > Removing the following registry value gets me past the issue for now. > > Key="CLSID\{01D6FA3C-BCF4-35AB-820A-49ACAF99F5F8}\InprocServer32" > Value="mscoree.dll" Type="string" Action="write" /> > Does anyone know if there is a workaround to this problem that is better than manually writing all of the appropriate elements that would replace the element, or if this particular Heat bug (think I saw it logged but can't find it now!) is likely to be fixed any time soon? It looks like Heat is being too keen in assuming that the harvested registry keys can be mapped to COM registration. Removing the mscoree element simply breaks the COM registration of that .NET component, and adding a Server="mscoree.dll" entry to the element (which seems like the right thing to do) results in LGHT0094. cheers, Karim -- View this message in context: http://www.nabble.com/heating-COM-componnents-and-getting-LGHT0130-on-generated-registry-data-tf2815472.html#a13239208 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to display text in /qb! dialog
A little late for a reply but... Ben Greenberg-3 wrote: > > I have both Product/@Language and Package/@Languages set to 1033. When I > open the package in Orca, I can see that Language is set to 1033 in the > Property table. But I still get the blank window behavior. > I'm using WiX 3.0.2925.0 and was having exactly the same problem: the default installer produced by the Votive Visual Studio wizard displaying no progress text. I finally discovered that I needed to: 1. Add a reference to WixUIExtension to my visual studio project (or you can use the -ext command-line flag). 2. Insert a element. 3. View the Linker project properties and add en-US to the Cultures text-box. After that it all works fine :) -- View this message in context: http://www.nabble.com/How-to-display-text-in--qb%21-dialog-tf4314011.html#a13231575 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Explanation for why you can't have both a 32-bit and 64-bit installer
OneReallyCoolApplication wrote: > > I am supposed to create a MSI package using WiX that can detect whether > the computer it's on has 32-bit or 64-bit architecture, and install > different files for each. > I believe that this is possible (using the VersionNT64 property) *provided you're not trying to install 64-bit files or install into the 64-bit-specific parts of the registry or file-system*. As soon as you need to start making 64-bit reg/file-system changes then you need a 64-bit MSI, and of course this won't run on 32-bit windows. It *is* possible to conditionally compile a 32- or 64-bit MSI from a single set of source, but you need to be careful with things like component codes. -- View this message in context: http://www.nabble.com/Explanation-for-why-you-can%27t-have-both-a-32-bit-and-64-bit-installer-tf4549274.html#a12999699 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users