Com Interop generating wrong cases for interfaces

  • Thread starter Thread starter Conor Maguire
  • Start date Start date
C

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
 
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.
 
Thanks Mattias,

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

regs,
Conor
 
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
 
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 said:
Thanks Mattias,

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

regs,
Conor
Click to expand...
 
Peter,

See my response to Mattias.

And thanks for your help and your quick response.

regs,
Conor

Conor Maguire said:
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" said:
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.
Click to expand...
Click to expand...
 
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.
 
Back
Top