Bugs item #1752713, was opened at 2007-07-12 16:37
Message generated for change (Comment added) made by dr_barnowl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=642714&aid=1752713&group_id=105970
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: candle
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Adrian Wilkins (dr_barnowl)
Assigned to: Nobody/Anonymous (nobody)
Summary: [EMAIL PROTECTED] is not mandatory
Initial Comment:
When using self-registration to generate registry keys for COM classes,
@Context will not appear for classes that are marked as PublicNotCreateable in
VB6 projects. Because instances can only be created by private code, the
execution context is not required. The self-registry of these classes does not
generate this element.
The absence of Context is however precluded by the validity checking code in
Compiler.cs, and the schema in wix.xsd, but because heat uses the self registry
routines to determine the content, it can generate Class elements with no
@Context when processing VB6 libraries with PublicNotCreateable classes, a
common construct in more advanced code (this is the closest you'll get to
having a dedicated "Interface" concept in VB6, for example).
Suggest:
* Change [EMAIL PROTECTED] to optional in schema
* Remove the following code from Compiler.cs
if (0 == context.Count)
{
this.core.OnMessage(WixErrors.ExpectedAttribute(sourceLineNumbers, node.Name,
"Context", classId));
}
Tested this on a local build and it seems to work fine for the discussed case.
----------------------------------------------------------------------
>Comment By: Adrian Wilkins (dr_barnowl)
Date: 2007-07-13 12:24
Message:
Logged In: YES
user_id=718275
Originator: YES
The method that heat uses to create elements for COM classes is to run
DllRegisterServer in a sandbox and then digest the contents. This would
appear to be what VB6 itself thinks should happen.
I created a simple DLL with two classes and a client application and
heat-ed the dll. Then I deleted the class entry for the PublicNotCreatable
class from the registry. The client application continued to function, the
VB6 IDE was happy to browse the class even when the source was not directly
loaded.
Running regsvr32 on the dll brings back the class entry. It's unlikely
that MS are going to fix this behaviour (if it is indeed broken and there
are no other reasons for it). My point of view is that it isn't harmful, so
don't "fix" it. The only way to get candle to compile it (as of 3106) is
to insert a bogus @Context. I tried adding an InprocServer32 key to my
non-creatable class, and it didn't seem to break the behaviour.
But I'd rather not
* risk that it causes some kind of subtle bug that I haven't detected
with rudimentary testing
* have to manually tweak a large number of my Class elements from heat
output
* have to use heat in it's "ignore COM" mode, because it makes install
authoring a lot more tedious - some of the DLLs I have to maintain have 30+
classes in them.
>> It's my view that
this should not be a space-separated list but instead just a standard
attribute - it's incredibly rare that you would register the same binary
for more than one of these
It can't be that rare, because the Class entry in the registry above my
test class does it - it registers both InprocServer32 and LocalServer32.
The type library belongs to a VB6 ActiveX EXE, which makes sense as you
need to be able to execute CreateObject calls for that class from both
inside and outside the process that it runs in. I would probably have
designed this as an element rather than an attribute - the present
space-separated design hints to me that someone assumed that a single
execution context was all that was required and then ran into problems.
----------------------------------------------------------------------
Comment By: Mike Dimmick (mikedimmick)
Date: 2007-07-12 21:29
Message:
Logged In: YES
user_id=1040952
Originator: NO
If it's PublicNotCreatable, why is the class registered with COM? It
shouldn't be, since COM cannot create it. Sounds like a bug in VB. The
class _interface_ has to be registered, so that the automation marshaller
can find the typelib in order to marshal calls across context boundaries
(COM+/MTS, cross-apartment, cross-process).
Class/@Context controls the key under which the binary appears:
InprocServer, InprocServer32, LocalServer, LocalServer32. It's my view that
this should not be a space-separated list but instead just a standard
attribute - it's incredibly rare that you would register the same binary
for more than one of these, because different things are expected:
respectively, a 16-bit DLL, a 32-bit or 64-bit PE DLL, a 16-bit New
Executable EXE, a 32-bit or 64-bit PE EXE.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=642714&aid=1752713&group_id=105970
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/wix-devs
