Interoperation calling COM

  • Thread starter Thread starter Tony Johansson
  • Start date Start date
T

Tony Johansson

Hi!

Below I have two code snippets the first one is done in VB and the second is
done in C#.
I do know why the C# version is getting compile error because I have
discussed that issue in a thread before.
But how can the VB version work without passing any parameter ?
I mean the underlaying Dll that is being called from VB is the same as the
one that is called from C# and
to have this statement NewExcelApp.Worksheets.Add();
in C# gave compile error.
So what I don't understand is how the support for Optional parameter that VB
has make it work ?

Here I have one VB code snippet.
Imports Microsoft.Office.Core
Imports Microsoft.Office.Interop.Excel
Dim NewExcelApp As New Microsoft.Office.Interop.Excel.Application
'This works fine
NewExcelApp.Worksheets.Add()

//C#
using Microsoft.Office.Core;
using Microsoft.Office.Interop.Excel; //Must have Office installed
Application NewExcelApp = new Application();
//This will not compile
NewExcelApp.Worksheets.Add();

//Tony
 
Tony said:
Hi!

Below I have two code snippets the first one is done in VB and the second is
done in C#.
Click to expand...

Neither are using COM interop per se, actually. There may be COM
underneath, but the interop assembly is a regular .NET assembly.
I do know why the C# version is getting compile error because I have
discussed that issue in a thread before.
But how can the VB version work without passing any parameter ?
I mean the underlaying Dll that is being called from VB is the same as the
one that is called from C# and
to have this statement NewExcelApp.Worksheets.Add();
in C# gave compile error.
So what I don't understand is how the support for Optional parameter that VB
has make it work ?
Click to expand...

Can you rephrase the question? VB.NET has a variety of features that C#
doesn't have, including support for optional parameters. Though, in
that particular case, the latest version of C#, 4.0 delivered with
VS2010, does in fact now have optional parameter support.

Have you tried the C# example in VS2010? It works fine there without
the optional argument.

Pete
 
Peter said:
[...]
Have you tried the C# example in VS2010? It works fine there without
the optional argument.
Click to expand...

Or, to be specific: it compiles fine. You'll get a run-time exception
if you don't ensure there's an active workbook already present (e.g. by
calling NewExcelApp.Workbooks.Add()).

But the optional argument stuff works fine in C# 4.0.

Pete
 
Peter Duniho said:
Neither are using COM interop per se, actually. There may be COM
underneath, but the interop assembly is a regular .NET assembly.


Can you rephrase the question? VB.NET has a variety of features that C#
doesn't have, including support for optional parameters. Though, in that
particular case, the latest version of C#, 4.0 delivered with VS2010, does
in fact now have optional parameter support.

Have you tried the C# example in VS2010? It works fine there without the
optional argument.

Pete
Click to expand...

This question is just to understand how all this works.
I mean the underlaying Dll that is used by both VB and C# is the same how
can VB work when not passing any parameter.
What I says is that I assume that the underlaying Dll that is called require
that all parameter is passed but in the case with VB
the compiler do some trick to make it work. is that correct understod.

//Tony
 
Tony Johansson said:
I mean the underlaying Dll that is used by both VB and C# is the same how
can VB work when not passing any parameter.
What I says is that I assume that the underlaying Dll that is called
require that all parameter is passed but in the case with VB
the compiler do some trick to make it work. is that correct understod.
Click to expand...

Yes, in the case of VB the compiler does the trick. If you compile the
following code:

Dim NewExcelApp As New Microsoft.Office.Interop.Excel.Application
NewExcelApp.Worksheets.Add()

and then use ILDASM to disassemle the compiled VB code you will find the
following:

.locals init ([0] class
[Microsoft.Office.Interop.Excel]Microsoft.Office.Interop.Excel.Application
NewExcelApp)
IL_0000: nop
IL_0001: newobj instance void
[Microsoft.Office.Interop.Excel]Microsoft.Office.Interop.Excel.ApplicationClass::.ctor()
IL_0006: stloc.0
IL_0007: ldloc.0
IL_0008: callvirt instance class
[Microsoft.Office.Interop.Excel]Microsoft.Office.Interop.Excel.Sheets
[Microsoft.Office.Interop.Excel]Microsoft.Office.Interop.Excel._Application::get_Worksheets()
IL_000d: ldsfld class [mscorlib]System.Reflection.Missing
[mscorlib]System.Reflection.Missing::Value
IL_0012: ldsfld class [mscorlib]System.Reflection.Missing
[mscorlib]System.Reflection.Missing::Value
IL_0017: ldsfld class [mscorlib]System.Reflection.Missing
[mscorlib]System.Reflection.Missing::Value
IL_001c: ldsfld class [mscorlib]System.Reflection.Missing
[mscorlib]System.Reflection.Missing::Value
IL_0021: callvirt instance object
[Microsoft.Office.Interop.Excel]Microsoft.Office.Interop.Excel.Sheets::Add(object,

object,

object,

object)

As you can see, the compiler is adding the "Missing.Value" parameters before
making the call into the assembly.

The C# compiler (3.0 or below) doesn't know how to do this, so you need to
add these values explicitly.
 
Alberto Poblacion said:
Tony Johansson said:
I mean the underlaying Dll that is used by both VB and C# is the same how
can VB work when not passing any parameter.
What I says is that I assume that the underlaying Dll that is called
require that all parameter is passed but in the case with VB
the compiler do some trick to make it work. is that correct understod.
Click to expand...

Yes, in the case of VB the compiler does the trick. If you compile the
following code:

Dim NewExcelApp As New Microsoft.Office.Interop.Excel.Application
NewExcelApp.Worksheets.Add()

and then use ILDASM to disassemle the compiled VB code you will find the
following:

.locals init ([0] class
[Microsoft.Office.Interop.Excel]Microsoft.Office.Interop.Excel.Application
NewExcelApp)
IL_0000: nop
IL_0001: newobj instance void
[Microsoft.Office.Interop.Excel]Microsoft.Office.Interop.Excel.ApplicationClass::.ctor()
IL_0006: stloc.0
IL_0007: ldloc.0
IL_0008: callvirt instance class
[Microsoft.Office.Interop.Excel]Microsoft.Office.Interop.Excel.Sheets
[Microsoft.Office.Interop.Excel]Microsoft.Office.Interop.Excel._Application::get_Worksheets()
IL_000d: ldsfld class [mscorlib]System.Reflection.Missing
[mscorlib]System.Reflection.Missing::Value
IL_0012: ldsfld class [mscorlib]System.Reflection.Missing
[mscorlib]System.Reflection.Missing::Value
IL_0017: ldsfld class [mscorlib]System.Reflection.Missing
[mscorlib]System.Reflection.Missing::Value
IL_001c: ldsfld class [mscorlib]System.Reflection.Missing
[mscorlib]System.Reflection.Missing::Value
IL_0021: callvirt instance object
[Microsoft.Office.Interop.Excel]Microsoft.Office.Interop.Excel.Sheets::Add(object,

object,

object,

object)

As you can see, the compiler is adding the "Missing.Value" parameters
before making the call into the assembly.

The C# compiler (3.0 or below) doesn't know how to do this, so you need to
add these values explicitly.
Click to expand...

Good explained !!

//Tony
 
Tony said:
[...]
Have you tried the C# example in VS2010? It works fine there without the
optional argument.
Click to expand...

This question is just to understand how all this works.
I mean the underlaying Dll that is used by both VB and C# is the same how
can VB work when not passing any parameter.
What I says is that I assume that the underlaying Dll that is called require
that all parameter is passed but in the case with VB
the compiler do some trick to make it work. is that correct understod.
Click to expand...

Yes. The DLL itself already has the information regarding what the
default value for the call should be. VB.NET has always been able to
interpret this information and include it if you leave it out.

Prior to C# 4.0, the C# compiler wasn't able to make use of this
information because the language specification didn't support it. For
C# 4.0, the language now supports optional parameters. The C# compiler
now is able to take advantage of the information that was in the DLL all
along, and insert the default parameter values when you don't provide them.

Pete
 
Back
Top