Interoperation calling COM

[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

 

[Peter Duniho]

Hi!

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

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 ?

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 Duniho]

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

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

 

[Tony Johansson]

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

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

 

[Alberto Poblacion]

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.

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.

 

[Tony Johansson]

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.

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.

Good explained !!

//Tony

 

[Peter Duniho]

[...]

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

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.

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