Com Interop generating wrong cases for interfaces

[Conor Maguire]

Folks,

We have a C# method which we register as part of a class for COM Interop:

public void send(string contents, string filepath ,string filename)

{

}

The type library produced for the assembly contains the following method
information:

void send(

[in] BSTR contents,

[in] BSTR FilePath,

[in] BSTR FileName);

Notice how the original parameters filename and filepath have been changed
to FileName and FilePath.

This is breaking all of our COM bindings in a significant amount of XLANG
schedules as the parameter messages need re-created. We cannot afford to do
this.

Also notice how the parameter signiature has not been changed.

Builds over 2 weeks have been fine through VS.NET, because older DLLS from
our SourceSafe database actually compile for InterOp correctly using
TBLEXP.exe - i.e. the com interfaces get generated with lowercase letters.

Very confused! Can anyone suggest a solution for this, as we now cannot
deploy new codebases to production.

Thanks in advance,

Conor

[Mattias Sjögren]

>Notice how the original parameters filename and filepath have been changed

to FileName and FilePath.

This is most likely due to a "feature" in the oleaut typelib
generation code. See

BUG: MIDL Changes the Case of Identifier in Generated Type Library
http://support.microsoft.com/?kbid=220137

Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[Peter Huang [MSFT]]

Hi Conor,

Maybe I have missing something, but based on my test, I can not reproduce
the problem.

I have a class as below.
using System;
using System.Runtime.InteropServices;
namespace TestCapicalizeParameter
{
[ClassInterface(ClassInterfaceType.AutoDual)]
public class Class1
{
public Class1()
{
}
public void send(string contents, string filepath ,string filename)
{
}
}
}

After I check the Register for COM Interop in the project setting, I will
get the typelib as below.

[id(0x60020004)]
void send(
[in] BSTR contents,
[in] BSTR filepath,
[in] BSTR filename);
NOTE: the filepath and filename are not capitalized.

I tested on VS.NET 2003(.NET framework 1.1).

If I have any misunderstanding, please feel free to post here.
Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

[Conor Maguire]

Thanks Mattias,

I'll hunt through the project classes to see where there may be another
signature similiar causing the problem.

regs,
Conor

"Mattias Sjögren" <ma********************@mvps.org> wrote in message
news:e%***************@tk2msftngp13.phx.gbl...

Notice how the original parameters filename and filepath have been
changed
to FileName and FilePath.

This is most likely due to a "feature" in the oleaut typelib
generation code. See

BUG: MIDL Changes the Case of Identifier in Generated Type Library
http://support.microsoft.com/?kbid=220137

Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[Conor Maguire]

Thanks Peter.

I think, referring to Mattias's email alongside yours, we may have another
signature in there that has for some reason caused the compiler to reach it
first (I think we re-strucutured some classes), even though it will not be
marked as requiring a class interface for COM as it is dotnet only. Then
perhaps it is compiling our method that is marked for COM interface
generation, incorrectly.

If this is the case, interop is a bit of a minefield. Surely if my method
is dotnet only, the compiler should just ignore it completely.

I will report back my findings at some stage today.

Thanks,
Conor

""Peter Huang" [MSFT]" <v-******@online.microsoft.com> wrote in message
news:BS**************@TK2MSFTNGXA03.phx.gbl...

Hi Conor,

Maybe I have missing something, but based on my test, I can not reproduce
the problem.

I have a class as below.
using System;
using System.Runtime.InteropServices;
namespace TestCapicalizeParameter
{
[ClassInterface(ClassInterfaceType.AutoDual)]
public class Class1
{
public Class1()
{
}
public void send(string contents, string filepath ,string filename)
{
}
}
}

After I check the Register for COM Interop in the project setting, I will
get the typelib as below.

[id(0x60020004)]
void send(
[in] BSTR contents,
[in] BSTR filepath,
[in] BSTR filename);
NOTE: the filepath and filename are not capitalized.

I tested on VS.NET 2003(.NET framework 1.1).

If I have any misunderstanding, please feel free to post here.
Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no
rights.

[Conor Maguire]

Mattias,

That was the problem - thanks a lot - saved us a load of days there.

We had added a new COM method in a class that was higher up alphabetically
in the project. Although this had a different signature, it did have
parameter names that were Pascal cased. This meant that the compiler
changed every other occurrance of these parameter names in each of the other
COM methods.

This breaks the COM bindings in our existing methods calls in the
case-sensitive message naming world of XLANG.

Thanks again for all your help.

regs,
Conor

"Conor Maguire" <Th****@newsgroup.nospam> wrote in message
news:O4**************@tk2msftngp13.phx.gbl...

Thanks Mattias,

I'll hunt through the project classes to see where there may be another
signature similiar causing the problem.

regs,
Conor

"Mattias Sjögren" <ma********************@mvps.org> wrote in message
news:e%***************@tk2msftngp13.phx.gbl...

>Notice how the original parameters filename and filepath have been
>changed
to FileName and FilePath.

This is most likely due to a "feature" in the oleaut typelib
generation code. See

BUG: MIDL Changes the Case of Identifier in Generated Type Library
http://support.microsoft.com/?kbid=220137

Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[Conor Maguire]

Peter,

See my response to Mattias.

And thanks for your help and your quick response.

regs,
Conor

"Conor Maguire" <Th****@newsgroup.nospam> wrote in message
news:uc*************@TK2MSFTNGP12.phx.gbl...

Thanks Peter.

I think, referring to Mattias's email alongside yours, we may have another
signature in there that has for some reason caused the compiler to reach
it first (I think we re-strucutured some classes), even though it will not
be marked as requiring a class interface for COM as it is dotnet only.
Then perhaps it is compiling our method that is marked for COM interface
generation, incorrectly.

If this is the case, interop is a bit of a minefield. Surely if my method
is dotnet only, the compiler should just ignore it completely.

I will report back my findings at some stage today.

Thanks,
Conor

""Peter Huang" [MSFT]" <v-******@online.microsoft.com> wrote in message
news:BS**************@TK2MSFTNGXA03.phx.gbl...

Hi Conor,

Maybe I have missing something, but based on my test, I can not reproduce
the problem.

I have a class as below.
using System;
using System.Runtime.InteropServices;
namespace TestCapicalizeParameter
{
[ClassInterface(ClassInterfaceType.AutoDual)]
public class Class1
{
public Class1()
{
}
public void send(string contents, string filepath ,string filename)
{
}
}
}

After I check the Register for COM Interop in the project setting, I will
get the typelib as below.

[id(0x60020004)]
void send(
[in] BSTR contents,
[in] BSTR filepath,
[in] BSTR filename);
NOTE: the filepath and filename are not capitalized.

I tested on VS.NET 2003(.NET framework 1.1).

If I have any misunderstanding, please feel free to post here.
Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no
rights.

[Peter Huang [MSFT]]

Hi Conor,

Thanks for your feedback and thanks for Mattias's knowledge sharing in the
community.

If you still have any concern, please feel free to post here.

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.