I had a few spare minutes today, so I decided to try compiling one of my C# apps under Rotor. (This app is what generates the API quickrefs in books like C# in a Nutshell.)
I tried just typing make, but I had a call to MessageBox.Show() that won’t compile under Rotor. When I commented that out (as well as the using System.Windows.Forms; line), I was amazed that the whole app compiled without a single error, warning, or tongue of flame ejecting from my Macintosh’s Firewire port.
What was even more surprising was that it was able to run without a single error; I asked it to reflect over System.dll, mscorlib.dll, and System.Xml.dll, and it gave me an XML document that I ran through our production tools, giving me this lovely PDF.
So even though Rotor includes only a subset of the .NET Framework Class Library, it’s a pretty useful subset!
| Learn more about Rotor in the upcoming Shared Source CLI Essentials (sample chapters are available online). |
Somehow, I managed to write a somewhat complex application that only used the types in the SSCLI. How lucky is that?
Re: OS X !
>> or tongue of flame ejecting from my Macintosh's Firewire port.
I'm so used to the spotlight on OS X apps running non-standard Mac stuff that I had to read the above line twice, then check the headline for an "on OS X!" double zinger! Nope, sounds like it's becoming standard procedure...
What about other CLR ports?
Have you tried this with Mono, or an of the other open source CLR implementations. It would be nice to see some anecdotal evidence of these projects' current state of usefullness.
Simon Hibbs
What about other CLR ports?
I didn't have any luck with Mono; it choked on code similar to this:
MethodAttributes attrs;
// ...
switch (attrs & MethodAttributes.Abstract) {
case 0:
It told me that the constant value '0' could not be converted to System.Reflection.MethodAttributes. I might be doing something dodgy here, but it works OK under Rotor and the CLR.
When I get some more time, I'll see if I can port it to Mono.