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] 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] 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] Wix Integer Variables
Cryptonomicon wrote: I am guessing that Package InstallerVersion=$(var.InstallVersion) Compressed=yes / and Component Id=Comp_StrawberryClassesDLL 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 ?define Is64=no type=enumerated? ?define InstallVersion=200 type=integer? 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] 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
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
[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: InstallExecuteSequence Custom Action=SetProp1 Sequence=10/ /InstallExecuteSequence 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 CustomAction Id=SetProp1 ... 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 CustomAction inside InstallExecuteSequence.wxs and a matching CustomActionRef 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] 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
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
[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] 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: Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Directory Id=MyApp64Folder Name=MyApp ... /Directory /Directory Directory Id=ProgramFiles64Folder Directory Id=MyAppFolder Name=MyApp ... /Directory /Directory /Directory 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
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] 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
Bob Arnson-6 wrote: Karim MacDonald wrote: would replace the Class 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 Class 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
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] 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 UIRef Id=WixUI_ErrorProgressText 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] 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.
RegistryValue Root=HKCR
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 RegistryValue elements that
would replace the Class 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 RegistryValue
element simply breaks the COM registration of that .NET component, and
adding a Server=mscoree.dll entry to the Class 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] 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.
RegistryValue Root=HKCR
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 RegistryValue elements that
would replace the Class 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):
RegistryValue Id=01D6FA3CBCF435AB820A49ACAF99F5F8_mscoree_overwrite
Root=HKCR
Key=CLSID\{01D6FA3C-BCF4-35AB-820A-49ACAF99F5F8}\InprocServer32
Value=mscoree.dll Type=string Action=write /
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):
Class Advertise=yes ... with no Server attribute
...
RegistryValue Root=HKCR
Key=CLSID\{01D6FA3C-BCF4-35AB-820A-49ACAF99F5F8}\InprocServer32
Name=InprocServer32 Value= Type=string Action=write /
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] 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
