Andreas Toenne of Heeg is going over the DotNet connect for VW. .NET is Microsoft's managed platform (their answer to J2EE). Huge, growing library of windows libraries and services. It's (in theory) the future development/deployment platform for Windows based applications. It is easier to work with than C++ - a big step up. Not as productive or simple as Smalltalk, but a step up for the C++ world. The .NET connect is our way of interfacing VW applications with a C# (or other CLR based) application. Most of this talk is demo again. The demo is a simple one - captures mouse clicks, and sends them to VisualWorks to chart.

First step - install the DotNet connect into the environment (load the parcel using the parcel manager). Second step - create (edit, compile) the C# application. There are already some pre-generated links for things like WindowsForms.

Next - start the wizard. The wizard allows you to adjust settings - what to import - the assembly or assemblies in question, for instance. The wizard imports all the methods/constructors (notifying you of problems along the way) - allows you to filter out any you don't need to hook to as well. What's generated is some C++ code that needs to be compiled (an nmake file is created as well).

Important here - you need not buy anything from MS here - you can download the free tools from MS (all command line). You can also, of course, work with VS itself.

Next - Load in the generated Smalltalk code (the wizard created that as well). Right now, this is a set of (load order important) .st files. By the next release, this step should be a lot simpler. What comes in is a namespace, some stub classes that are needed, and an external interface class that hooks to the DLL (generated in the step above).

Finally, we need to link up the events that are coming from the dotNet dll with your Smalltalk code - here you need to write some code. I'm sitting at the back of the room here, so I can't actually make out the code itself - there are demos shipping with VW 7.3 (including the NC). At this point, you often need to go back to the generated C interface and change the relevant API to be threaded.

There are a few choices for talking to a .NET application:

• Expensive
• Web Services
• Intrusive
• CORBA
• COM
• Direct (the DotNet Connect)
• Custom marshalling
• Communication via TCP or C calls
• proxy in the .NET world

The way in for us is through the unmanaged bridge that MS put in for all the existing C/C++ code out there. On the VW side, a proxy layer was built to manage that communication.

Limitations

• The CLR is a superset of C# or C++
• Not all legal types are importable
• Some illegal types are not detected
• No support for Mono at this point

The documentation covers all the limitations (I didn't get all of them down here). The performance is very good - method calls and returns are very fast.

Future steps:

• Next version: NConnect
• 100% integration with VisualStudio
• Project-Wizard generated solution
• DotNet GUI inside VisualWorks Windows (without any detour through COM)

You can see a high level view of this in our DotNet Whitepaper.