"TJ" <microsoft.support@tjworld.org> wrote in message
news:eS935JjZFHA.3220@TK2MSFTNGP14.phx.gbl...
> In C# how do you achieve pass-by-reference property declarations in the
> Type Library?
>
> I am writing a COM Class Library that must mimick an existing library for
> which the only information is the TypeLib. I'm using Visual Studio .NET
> 2003.
>
> The original library provides simple authentication services, from Access
> and MS-SQL OLEDB providers. The enhancement I'm creating provides support
> for ODBC and will be a drop-in replacement.
>
> The original library was written in Visual Basic 6, and declares an
> interface with property setter methods that take pointers as arguments, as
> this extract shows:
>
> dispinterface _DBLink {
> methods:
> [id(0x60030006)] VARIANT_BOOL CheckUser([in, out] BSTR* User, [in, out]
> BSTR* Password);
> [id(0x68030008), propput] void LoginClassField([in, out] BSTR* rhs);
>
> I've created an identical COM Class Library in C#, but the arguments to
> the property setter methods are passed-by-value, and it isn't possible to
> use the C# "ref" or "out" modifier on Properties.
>
> dispinterface _DBLink {
> methods:
> [id(0x60020006)] VARIANT_BOOL CheckUser([in, out] BSTR* User, [in, out]
> BSTR* Password);
> [id(0x60020008), propput] void LoginClassField([in] BSTR rhs);
>
> [id(0x60020009)] void set_LoginClassField([in, out] BSTR* value);
>
> code:
> public interface _DBLink {
> bool CheckUser(ref string User, ref string Password);
> string LoginPassField { set; }
>
> void set_LoginClassField(ref string value);
>
> // ... rest of code
> }
>
> As you can see, although I can define the Property setters as methods, the
> TypeLib would then no longer declare them as "propput".
>
> Any ideas?
>
> TJ.
>

"TJ" <microsoft.support@tjworld.org> wrote in message
news:eXGEAyvZFHA.2984@TK2MSFTNGP15.phx.gbl...
> Nicholas, thanks for that suggestion, it offers some progress but further
> confusion. I have further questions if anyone can help?
>
> I'd been using Object Viewer stand-alone so it wasn't showing me C#
> specific code matching the VB6 COM Type Library. As soon as I added the
> external COM's TLB to my C# solution and ran Object Viewer on it, it
> showed:
>
> IDL: [id(0x68030008), propput] void LoginClassField([in, out] BSTR* rhs);
> C# prototype: public abstract new System.IntPtr LoginClassField [ set ]
>
> I didn't know about the IntPtr structure. I've now redefined my Interface
> this way:
>
> public interface _DBLink
> {
> [DispId(0x68030008)] IntPtr LoginClassField{ set; }
> // ...
> }
> public class DBLink : _DBLink {
> public IntPtr LoginClassField {
> set {
> _LoginClassField = Marshal.PtrToStringBSTR(value);
> Marshal.FreeBSTR(value);
> }
> }
> // ...
> }
>
> Now I'm concerned that when viewed in Object Viewer the IDL looks
> different in other ways:
>
> public System.IntPtr LoginClassField [ set ]
>
> and when used to view the resulting Type Library (from the build) shows:
> [id(0x68030008), propput] void LoginClassField([in] long rhs);
>
> So although the C# property declaration seems to match, the IDL looks
> further away than it was. I've now got a long instead of a BSTR*
>
> I tried to use [MarshalAs(UnmanagedType.LPStr)] as per the documentation,
> but as for many things Property-related, the compiler won't accept it.
>
> [DispId(0x68030008), MarshalAs(UnmanagedType.LPStr)] IntPtr
> LoginClassField{ set; }
>
> Is it possible to manually apply the propputref attribute to a C# method
> so I could do something along the lines of this ?
>
> [ BindAs( BindFlags.PutRefDispProperty ) ] public void
> set_LoginClassField(ref string value)
>
> which, if there is a way to control the Bind, would result in something
> like this in the IDL:
>
> [propputref] void LoginClassField( [in, out] BSTR* value)
>

> HOWEVER, having got this far I've now convinced myself I've taken the
> wrong route, since the COM object I'm creating needs to be a drop-in
> replacement for an existing COM object, and may be deployed on
> systems that don't have the .Net framework installed.

> Thinking of switching to C++, but it seems that Visual Studio .Net 2003
> won't let me create a classic COM library, only a .net assembly!

> I'll be glad when I've got this finished and can go back to Java and
> Eclipse IDE! I only started on this C# / Microsoft programming 2 days
> ago to provide ODBC functionality to the application that uses DBLink,
> so it can share a common user database with a J2EE web application.

"TJ" <microsoft.support@tjworld.org> wrote in message
news:Oy%233a65ZFHA.1148@tk2msftngp13.phx.gbl...
> Thanks Chad, your articles have moved me on somewhat.
>
> Working out what was wrong with the syntax of the Object Viewer IDL was a
> pain, but then I had yet more joy solving "cl.exe not found" and
> "oaidl.idl not found" errors from MIDL, along with others.
>
> Solutions were to add to the environmental variables for the location of
> midl.exe, cl.exe (wasn't even in the Visual Studio 2003 .Net folder
> structure), and the library .tbl files used by MIDL.
>
> PATH=%PATH%;C:\Program Files\Microsoft\Visual Studio .NET
> 2003\Common7\IDE;
> PATH=%PATH%;C:\Program Files\Microsoft\Visual Studio .NET 2003\Vc7\bin;
> INCLUDE=C:\Program Files\Microsoft\SDK\include\
>
> *Note: I always edit my Microsoft applications install folder to be
> "\Program Files\Microsoft\<application>" rather than "\Program
> Files\Microsoft <application>" so as to stop the multiplication of
> "Microsoft..." folders in the "Program Files" folder.
>
> In the revised class IDL file express the full path for the importlib()
> statement:
>
> // TLib : // TLib : Common Language Runtime Library :
> {BED7F4EA-1A96-11D2-8F08-00A0C9A6186D}
> importlib("C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\mscorlib.tlb");
>
> HOWEVER, having got this far I've now convinced myself I've taken the
> wrong route, since the COM object I'm creating needs to be a drop-in
> replacement for an existing COM object, and may be deployed on systems
> that don't have the .Net framework installed.
>
> What a pain, as the code in the library itself is complete!
>
> I was investigating [ ComRegisterFunctionAttribute ] & [
> ComUnregisterFunctionAttribute ] thinking I could create a component that
> would work in a .Net and classic environment, but I think maybe I
> misunderstood the documentation and that my component will only work in
> the .Net environment, even when called by a classic COM client.
>
> Thinking of switching to C++, but it seems that Visual Studio .Net 2003
> won't let me create a classic COM library, only a .net assembly!
> Investigating Visual Basic (*spits!) it looks like that still allows the
> creation of classic COM libraries - grrr!!
>
> I'll be glad when I've got this finished and can go back to Java and
> Eclipse IDE! I only started on this C# / Microsoft programming 2 days ago
> to provide ODBC functionality to the application that uses DBLink, so it
> can share a common user database with a J2EE web application.
>
> TJ.
>