Бизнес-робот
Бизнес
робот

Темы:

Архив:

Каталог рекламы и объявлений

Ящик для предложений: sales@blogslov.ru

WiX-devs Digest, Vol 14, Issue 21

Send WiX-devs mailing list submissions to


To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/wix-devs
or, via email, send a message with subject or body 'help' to


You can reach the person managing the list at


When replying, please edit your Subject line so it is more specific
than "Re: Contents of WiX-devs digest..."


Today's Topics:

1. Interface/Forward support (Adrian Wilkins)
2. PATCH: Critical fix for TypeLib versions and improvements for
VB6 outputs (Adrian Wilkins)


----------------------------------------------------------------------

Message: 1
Date: Fri, 13 Jul 2007 13:29:21 +0100
From: "Adrian Wilkins"
Subject: [WiX-devs] Interface/Forward support
To:
Message-ID:

Content-Type: text/plain; charset=ISO-8859-1; format=flowed

wix.xsd does not appear to have explicit support for the "Forward"
subkey of Interface. This is relatively common in VB6 DLLs. I believe
this to be the result of using "Preserve Compatibility" when
compiling, but I'm not certain. A little testing managed to provoke
the appearance of one of these keys in my first try... but I've since
not been able to reproduce it.

Having searched through the documentation for this key, it's not
surprising it's not there. I only know about it because heat distils
it out from some of my VB6 DLLs.

I thought of implementing this one of two ways -

* Add a "Forward" attribute to the Interface complextype in wix.xsd
and add the code to handle it to the compiler (and to the relevant
heat extension).
OR
* Allow nesting of Interface within Interface
* Add a private override for ParseInterfaceElement that passes the
parent value to the child.
* The nested Interface element adds a Forward key (value from
parent Interface) on compilation

The latter seems more elegant but if it's possible to forward an
interface in one file to one in another file then it may be worth
implementing both approaches. From what I can find, this seems to be a
VB6 specific thing and should only occur there.

.... The Interface element doesn't seem to support BaseInterface
either. This one appears to be an actual documented thing though.

http://msdn2.microsoft.com/en-us/library/ms680091(vs.80).aspx

I would expect to be able to have a BaseInterface that originated in a
seperate file though, so I would suggest.

* Add BaseInterface to the schema for Interface
* Allow nesting of Interface inside Interface to signify Forward for VB6 DLLs.

I'm presently having a bit of a hack at this right now, I'll let you
know how I get on.



------------------------------

Message: 2
Date: Fri, 13 Jul 2007 20:15:21 +0100
From: "Adrian Wilkins"
Subject: [WiX-devs] PATCH: Critical fix for TypeLib versions and
improvements for VB6 outputs
To:
Message-ID:

Content-Type: text/plain; charset="iso-8859-1"

The enclosed patch helps with the pain of making a VB6 installer as
follows. The changes are based on the outputs of the VB6
DllRegisterServer routine, because that's how the heat harvester
constructs it's output.

I started off using the old Visual Studio Installer 1.1 plugin for
VS6, but on hitting build, it runs smack into an installer advertising
issue and demands the VS2005 install disk for about 10 minutes PER
MODULE, every time. Oh the irony. This makes it unworkable (which is a
shame, because it's a nice enough tool for basic use once you've
worked out the kinks).

Points marked with "*", changes to the source code with ">"

The critical fix (unchecked this can cause bad things to happen).

* The version numbers in the version subkeys of TypeLib are expressed in hex.
* The version numbers in Class/VERSION keys are decimal.
* The compiler gets this correct and exports hex in the right places.
* The component mutator did NOT get this right (and the source said
so, in a TODO). This is bad.
* Both major and minor version numbers above 9 are common, esp in
VB6 development since the IDE has full command over the TypeLib
generation process.
* All versions above 9 are treated wrongly.
* Versions with chars [a-f] are exported as RegistryValue
elements instead of in the correct location in their TypeLib element.
* Versions without chars [a-f] but above 9 are incorrectly
treated as decimal.
* This means that version 0x10 will not supercede version 0x0f
correctly because heat will emit keys for 0x0f properly. Then it will
treat version 0x10 as decimal and set the TypeLib version attribute to
"10" and light will export it as version 0x0a.Oops.
* See bug 1752728
> Mutator now treats this key as hex always.
* This also means that sub-components of TypeLib elements are now
correctly indexed below a TypeLib where the version number had a char
[a-f]

And the minor improvements (mostly about reducing workload on the VB6 developer)

* Some VB6 COM classes register multiple execution contexts (ActiveX EXEs).
* The harvester does this correctly.
* Some VB6 COM classes do not register an execution context. This
occurs where the class has been marked "PublicNotCreatable". While the
class is thus totally unnecessary from a COM standpoint as the only
thing you need is the interface (and removing it's registration
appears to have no ill effects), this is "how it is" and VB6 is
unlikely to be fixed.
> Have made optional in wix.xsd and removed the
compiler check for it's presence.
* The VB self-register routine insists on registering several VB
components that can be presumed to be installed on Win2k and up
(TypeLibs from MSVBM60.dll, etc).
* These are not a part of the type library for the file.
* They have HELPDIR values directed at c:\windows\system32
> The harvester now detects this (checks to see if value is equal
to Environment.SystemDirectory) and sets the HelpDirectory attribute
correctly. This eliminates a spurious RegistryValue for each instance.
* Therefore you get spurious Class, RegistryValue and TypeLib
entries outside the File element.
* Because these are not marked as advertised and do not belong to
the file, candle treats the as errors. I thought about marking them as
advertised, but I think it causes problems, so....
> Added -componentfilerootsonly option to FinalizeHarvesterMutator.
This iterates through the children of components and removes all
non-file elements. Since the other changes in this patch roll all
remaining VB6 output into the File element, this has the effect of
eliminating the spare VB component elements. Note that in
circumstances where there are extra-file items that are desired, this
will eliminate them without warnings, but I encountered none of these
in my work with 30+ VB6 dlls encompassing hundreds of classes.
* VB6 DLLs register "Forward" keys in interfaces when an interface
has been deprecated and the application should forward calls to the
new interface. This may be the result of adding members to interfaces
without changing the , which is very normal in VB6
> wix.xsd changed to allow Interface elements to nest.
> Compiler treats an Interface element nested inside another to be
an interface that forwards to the parent interface.
> Mutator nests forwarded interfaces beneath their target.
* Browsing the MSDN documentation for the previous point, could not
find "Forward" subkey of Interface key, but did find "BaseInterface"
key which is not implemented by WiX tools.
> Implemented BaseInterface key in compiler and schema, even though
I didn't need it personally.

This has reduced my initial pain on generating VB6 install modules
down to a one-line process, from having to manually flick through all
the output removing junk. Having the right TypeLib versions also helps
when some of your codebase has version numbers in the 30's (decimal).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wix-patch.diff
Type: application/octet-stream
Size: 25868 bytes
Desc: not available

------------------------------

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

------------------------------

_______________________________________________
WiX-devs mailing list

https://lists.sourceforge.net/lists/listinfo/wix-devs


End of WiX-devs Digest, Vol 14, Issue 21
****************************************

2007 14 июля