This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: DotNet Connect for VisualWorks
Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants
Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml
Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general.
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)
Previous Topic
