This is documentation for Mathematica 5, which was
based on an earlier version of the Wolfram Language.
View current documentation (Version 11.1)

Documentation / Mathematica / Add-ons & Links / .NET/Link / Part 1. Calling .NET from Mathematica: 'Installable .NET' /

Syntax

The Mathematica syntax for calling .NET methods and accessing fields is very similar to the syntax used in C# and Visual Basic .NET. The box below compares the Mathematica and C# ways of calling constructors, methods, properties, fields, static methods, static properties, and static fields. You can see that Mathematica programs that use .NET are written in almost exactly the same way as C# (or VB .NET) programs, except Mathematica uses [] instead of () for arguments and @ instead of the . (dot) as the "member access" operator.

An exception is that for static methods, Mathematica uses the context mark ` in place of the dot used by C# and VB. This parallels the usage in those languages also, as their use of the dot in this circumstance is really as a scope resolution operator (like :: in C++). Although Mathematica does not use this terminology, its scope resolution operator is the context mark. .NET namespace names map directly to Mathematica's hierarchical contexts.

C# and Mathematica syntax comparison.

You may already be familiar with @ as a Mathematica operator for applying a function to an argument: f @ x is equivalent to the more commonly used f[x]. .NET/Link does not usurp @ for some special operation—it is really just normal function application slightly disguised. This means that you do not have to use @ at all. The following are equivalent ways of invoking a method.

The first form preserves the natural mapping of the syntax of most .NET languages into Mathematica and will be used exclusively in this manual.

When you call methods, properties, or fields and get results back, .NET/Link automatically converts arguments and results to and from their Mathematica representations according to the table presented earlier.

In object-oriented languages, method and field names are scoped by the object on which they are called. In other words, when you write obj.Meth(), .NET languages know that you are calling the method named Meth that resides in obj's class, even though there may be other methods named Meth in other classes. .NET/Link preserves this scoping for Mathematica symbols so that there is never a conflict with existing symbols of the same name. When you write obj@Meth[], there is no conflict with any other symbols named Meth in the system—the symbol Meth used by Mathematica in the evaluation of this call is the one set up by .NET/Link for this class. Here is an example using a field. First, we create a Point object.

In[9]:=

The Point class has fields named X and Y, which hold its coordinates. A user's session might also have symbols named X or Y in it, however. Let us set up a definition for X that will tell us when it is evaluated.

In[10]:=

Now set a value for the field named X (this would be written as pt.X = 42 in C# or VB).

In[11]:=

You will notice that "gotcha" was not printed. There is no conflict between the symbol X in the Global` context that has the Print definition and the symbol X that is used during the evaluation of this line of code. .NET/Link protects the names of members on the right-hand side of @ so that they do not conflict with, or rely on, any definitions that might exist for these symbols in visible contexts. You will typically see a lot of Mathematica spelling warning messages in .NET/Link programming, as many .NET types have members with names similar to existing Mathematica symbols. Because the .NET names are scoped to the objects on which they operate, you can almost always ignore these warnings.

In summary, for nonstatic methods, properties, and fields, you never have to worry about name conflicts and shadowing, no matter what context you are in or what the $ContextPath is at the moment. This is not true for static members, however. Static methods and fields are called by their full name, without an object reference, so there is no object out front to scope the name. Here is a simple example of a static method call that invokes the .NET garbage collector. We need to call LoadNETType before we call a static method to make sure the class has been loaded.

In[12]:=

The name scoping issue is not usually a problem with static members because they are defined in their own contexts (GC` in this example). These contexts are usually not on $ContextPath, so you do not have to worry that there is a symbol of the same name in the Global` context or in a package that has been read. If there is already a context named GC` in your session, and it has its own function Collect, you can always avoid a conflict by using the fully-hierarchical context name that corresponds to the full type name for a static member.

In[14]:=

Getting Information About Types and Objects

It is often convenient to be able to quickly display information about the methods, properties, fields, and so on that exist in a given .NET type. .NET/Link provides the NETTypeInfo function to obtain this information.

Getting information about types.

NETTypeInfo will load the type if it has not already been loaded.

This will display a lot of information about the Process class.

NETTypeInfo["System.Diagnostics.Process"]

This will show just the properties and methods.

NETTypeInfo["System.Diagnostics.Process", {"Methods", "Properties"}]

This will show just properties with names that begin with "Peak".

NETTypeInfo["System.Diagnostics.Process", "Properties", "Peak*"]

The default behavior is to display the members in C# syntax. If you want to see them in Visual Basic .NET syntax, use the LanguageSyntax option.

NETTypeInfo["System.Diagnostics.Process", LanguageSyntax->"VisualBasic"]