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 :-
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 th
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 w
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 ot
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. Ho
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 act
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 I
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 t
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 featur
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-tf2
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, ProgramFil
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.),
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
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
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
generate
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 volunt
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-49AC
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" />
>
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
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 t
20 matches
Mail list logo
