Right, recompiling with no changes does not change the auto-generated
GUIDs. Note that auto-generated LIBIDs and CLSIDs are based off of the
assembly's version number, and by default, Visual Studio .NET projects
are marked with a version of "1.0.*" (inside AssemblyVersionAttribute).
This will cau
Note that if the optional parameters are System.Objects (VARIANTs), or
if you're willing to do a late-bound call, you can just pass
Type.Missing for each optional parameter instead of figuring out and
passing the default value for each one.
-Original Message-
From: Tom Archer [mailto:[EMA
That file is the primary Interop assembly (PIA) for ADO 2.7, and you
should redistribute it with your application.
-Original Message-
From: Steve Holak [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 25, 2002 1:36 PM
To: [EMAIL PROTECTED]
Subject: [DOTNET] ADO interop
I've done plenty
Yes. This applies to all Marshal methods that return interface pointers
as IntPtr types.
Adam
-Original Message-
From: Axel Heitland [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 25, 2002 9:09 AM
To: [EMAIL PROTECTED]
Subject: [DOTNET] Marshal::GetComInterfaceForObject
Can find it
Yes, that is a known bug in v1.0. Sorry for the headaches it caused
you! The /regfile option was mainly meant for informational purposes,
anyway, because if an assembly uses custom registration/unregistration
functions that information won't be captured in the file.
Adam
-Original Message-
Morningstar [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 23, 2002 10:45 AM
To: [EMAIL PROTECTED]
Subject: Re: [DOTNET] InterOp and Safearrays
From: Richard A Morningstar
The imported interop code was:
MethodA([in] Object marshal(SafeArray Variant) saUnks) ...;
This is correct?
Adam Nathan
You shouldn't be modifying the signature in this case because you're
treating a single VARIANT (that should contain an array of VARIANTs) as
an array of VARIANTs. You should be able to leave the imported Interop
assembly alone and still use the C# code you have below.
-Original Message-
Yes, this is a known bug. The easiest workaround, unfortunately, is to
change the input type libraries so the source interface is defined in
the same type library as the coclass. For instance, you could duplicate
the interface definition in typelib B, then optionally hack the produced
Interop as
EnumeratorViewOfEnumVariant implements an interface called
ICustomAdapter, which has a method called GetUnderlyingObject. So if
you use IEnumerator explicitly (rather than doing foreach) you can do
the following:
IEnumerator enumerator = comObj.GetEnumerator();
try
{
while (enumerator.MoveNext
Without modifying the Interop assembly, you could cast the object
exposing events to
System.Runtime.InteropServices.UCOMIConnectionPointContainer and handle
COM events the "raw way" instead of using delegates, but it's a
non-trivial amount of work.
Adam
-Original Message-
From: Barrie Gr
Sent: Tuesday, April 02, 2002 12:30 PM
To: Adam Nathan; [EMAIL PROTECTED]
Subject: RE: COM Interop: Not seeing COM Interfaces in OLEVIEW after
regasm?
Thanks for your very response and excellent answer. I can grok this but
why
is this (IDispatch) the default? I know you are just the messenger, b
public Decimal Amount
{
[return: MarshalAs(UnmanagedType.Currency)]
get { ... }
[param: MarshalAs(UnmanagedType.Currency)]
set { ... }
}
-Adam
-Original Message-
From: Sills, Adam [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 12, 2002 11:58 AM
To: [EMAIL PROTECTED]
Subject: Re:
> Now, I initially assumed it was that I hadn't generated a type library
and
> "early bound" my Object variables to the appropriate types. So I
exported
> the typelib, no more CreateObject, etc, and it's still slow (no
visible
> improvement).
Because .NET classes only expose their members via IDi
13 matches
Mail list logo
