You are browsing the archive for Mono.

What is Gendarme?

October 11, 2012 in .NET, Elements, Mono

New in Oxygene 5.2 is Gendarme Code Analysis, which is a deeply integrated, extensible rule-based system to find concerns in .NET (and Mono) applications and libraries. The name comes from the Mono Project’s Gendarme which it is based on. It is modified to integrate nicely with the Oxygene Language and Visual Studio IDE, providing improved and customized rules that make sense to Oxygene developers.

Why Use Gendarme?

One of our goals with Oxygene is to help you write better code. Gendarme helps you detect “concerns” which may represent potential bugs or just code that is less maintainable. For example, concerns include code duplication, potentially undisposed resources, bad practices, or inconsistent naming, to name just a few. Gendarme is also extensible, allowing you to create rules specific to your project or team. All of these concerns are reported during the build process through our “Inline Error” system. This helps you correct the concerns sooner, before they propagate through your project.

How to Use Gendarme?

Gendarme can be enabled or disabled on a per project basis. To enable Gendarme Code Analysis for your project, simply go to Project Properties.

Solution Explorer - Project Properties (Alt+Enter)

Once you are in Project Properties, scroll down to the bottom of the Build options. There is a default ruleset that is provided with Oxygene, but you can also define your own.

Gendarme build options

The default ruleset is an XML file that is installed at "C:\Program Files (x86)\RemObjects Software\Oxygene\bin\Gendarme\rules.xml" by default. Take a look at the ruleset and you will find it is pretty self-explanatory.

The Minimum Severity option allows you to filter defects below the specified severity level: audit, low, medium, high or critical. The Minimum Confidence option prevents false positives by filtering defects below the specified confidence level: low, normal, high or total. You also have the option of specifying custom config and ignore files.

Also in the "C:\Program Files (x86)\RemObjects Software\Oxygene\bin\Gendarme" folder is the command line version of Gendarme. This is a customized version of the one available directly from the Mono Project.

Once enabled, you will see blue “Inline Error” indicators during builds that mark one or more concerns. Clicking on a line provides the Fix-It Panel, where you can ignore an individual concern or all occurrences of the concern for the entire project.

Gendarme concerns in code

Selecting either of the Ignore options will add an entry to the CodeAnalysis.ignore file (which gets created if it didn’t already exist) in the Properties folder of your project. This file will be referenced from the project properties page under Ignore File. The format is simple enough; each entry is two lines. The first line is the rule and the second line specifies when to ignore it.

Gendarme Rules

Gendarme returns defects in different categories. Each of the categories are defined in a different rule assembly. The following rule assemblies are used in Gendarme for Oxygene:

  • BadPractice
  • Concurrency
  • Correctness
  • Design (+Generic & LINQ)
  • Exceptions
  • Globalization
  • Interoperability (+COM)
  • Maintainability
  • Naming
  • Performance
  • Portability
  • Security (+CAS)
  • Serialization
  • Smells
  • User Interface (UI)

Here are a few rule examples to show you what Gendarme can do for you right away. There are a lot more in store for you though. (You can read about the full set and see some examples in the Gendarme documentation.)


These rules check for bad practices that can result in code not behaving the way you expect it to. Frequently these problems will hide bugs, or introduce bugs later on.


This rule checks for exception objects which are created but not raised, not returned, and not passed to another method as an argument. This quite often obscures a bug that is easily missed unless you specifically test for the exception.

Bad example:

method MissingRaise(arg: Object);
  if not assigned(arg) then begin
    new ArgumentNullException('arg')

Good example:

method WithRaise(arg: Object);
  if not assigned(arg) then begin
    raise new ArgumentNullException('arg')


This rule checks for calls to Type.GetInterface that look like they query if a type is supported, i.e. the result is only used to compare against nil. The problem is that only assembly qualified names uniquely identify a type, so if you just use the interface name or even just the name and namespace, you may get unexpected results.

Bad example:

if sometype.GetInterface('IConvertible') <> nil then begin
  // then the type can be assigned to IConvertible
  // but what if there is another IConvertible in there ?!?

Good example:

if typeOf(IConvertible).IsAssignableFrom(sometype) then begin
  // then the type can be assigned to IConvertible
  // without a doubt!


This rule ensures that Equals(object) methods return false when the object parameter is nil.

Bad example:

method SomeClass.Equals(obj: Object): Boolean;
  // this would throw a NullReferenceException instead of returning false
  exit ToString().Equals(obj.ToString())

Good example:

method SomeClass.Equals(obj: Object): Boolean;
  if not assigned(obj) then begin
    exit false
  exit ToString().Equals(obj.ToString())


These rules report concerns on code that can be improved for better performance.


This rule fires if multiple casts are done on the same value, for the same type. Casts are expensive, so reducing them by changing the logic or caching the result can help performance.

Bad example:

for each o: Object in list do begin
  // first cast (is)
  if o is ICollection then begin
  // second cast (as) if item implements ICollection

Good example:

for each o: Object in list do begin
  // a single cast (as) per item
  var c: ICollection := (ICollection(o));
  if c <> nil then begin


These are rules related to design principles.


This rule fires if a type contains externally visible fields. It is safer to use a property instead which allows you to change the implementation without breaking binary compatibility with other assemblies.

Bad example:

  Foo = public class
    var Value: Integer;

Good example:

  Foo = public class
    property Value: Integer;

When to use Gendarme?

You can, and should, start using Gendarme on your existing Oxygene for .NET projects right away. You may be surprised at the concerns that exist even in shipping projects, and they may even help you discover and fix problem bugs. To keep the number of reported concerns to a manageable level, turn Gendarme on early in the development cycle, before the concerns propagate too far through your project. So be sure to download the latest Oxygene and put Gendarme code analysis to use today!

Profile photo of marc

by marc

Choosing the Best Toolchain for each Platform

February 4, 2012 in .NET, Android, ASP.NET, Cocoa, Data Abstract, Delphi, Elements, iOS, Java, JavaScript, Mac, Metro, Mono, MonoTouch, non-tech, Oxygene, Platforms, RemObjects, Visual Studio, Windows, Windows Phone, Xcode

Four or five years ago, the software world was simple: if you were a commercial software developer, you were developing for Windows. But this has changed drastically with the advent of mobile platforms such as iOS and Android, the steadily increasing market share of Macs, and the establishment of new development paradigms such as rich web applications hosted in browsers.

Here at RemObjects, I field the majority of so called “sales related” emails (that is, emails that aren’t technical support requests handled by our excellent support team and the product developers) myself — and as this century gets older, I see more and more requests asking what tools and toolchains to pick for different platforms. “Can I develop for both Windows Phone 7 and Android with Oxygene and share code?” — “Which version of Data Abstract is best for targeting iOS?” — “Should I use Oxygene for .NET with MonoDroid or Oxygene for Java for my Android app?”.

There are a lot of great development tool chains for the different platforms out there — be they Xcode/Cocoa, Visual Studio/.NET, Delphi, JavaScript — and sometimes the decision does not seem easy, because here at RemObjects we provide editions of most of our products for various development platforms, and often more than one choice can be applied to a specific platform need.

To help make heads and tails of this, we created a small graphical overview chart on our website that gives insight into which language/framework/product combinations we support on any given platform and — more importantly IMHO — which combination we recommend.*

[*And that recommendation might not always be what you think — for example, I often get looked at weirdly when I recommend Xcode over our own Oxygene (plus Mono) for Mac development. But development tools, even versatile ones such as Oxygene, or Delphi, or Visual Studio, are not and should not be Jacks of all Trades, and thus no single tool, no matter how great (and we happen to think Oxygene is pretty great ;) can be the best choice for all scenarios. We acknowledge and honor that.]

You can find this overview matrix — which will be ever-expanding as time goes by and the development world around us changes — at; i’m also including a static screenshot of it, below.

May it help you to choose the best set of tools for your needs!

Oxygene by Example – Command line parsing

December 23, 2011 in .NET, Cooper, Elements, Mono, Oxygene, Uncategorized, Wiki

This is second article in my blog post series “Oxygene by Example”.

While working with command line arguments in Prism is quite simple, the “Main” method has an array of string that holds the value, it can become quite complex when having to parse options too. When having to work with those, it’s easiest to use the NDesk for Oxygene file. It’s a single file that can be added to any project (no need for a separate dll library). It was originally written in C# by Jonathan Pryor, we ported it to Oxygene so it can be embedded in an Oxygene project too.

The first step is to add NDesk.Options to the uses list, this is where the classes are defined. A general console application entry point looks like:

class method ConsoleApp.Main(arguments: array of String): Integer;
  var lSourceUri: String;
  var lDestinationUri: String;
  var lSomeOption: Boolean;
  var lShowHelp: Boolean;
  var lOptionSet := new OptionSet(); 
  var lFiles: sequence of String;
  lOptionSet.Add("s|source=", "{filename or url} of source object", v -> begin lSourceUri := v end );
  lOptionSet.Add("d|destination=", "{filename or url} of destination object", v -> begin lDestinationUri := v end );
  lOptionSet.Add("o|someoption", "some binary option", v -> begin lSomeOption := assigned(v) end );
  lOptionSet.Add("h|?", "show help", v -> begin lShowHelp := assigned(v); end );
    lFiles := lOptionSet.Parse(arguments);
    on  Exception  do
      lShowHelp := true;
  if  (lShowHelp)  then begin
    exit 1;
  end else  begin
    Console.WriteLine('Options supplied:');
    Console.WriteLine('Source: ' + lSourceUri);
    Console.WriteLine('Destination: ' + lDestinationUri);
    Console.WriteLine('Some option: ' + iif(lSomeOption,'ON','OFF'));
    for each el in lFiles do Console.WriteLine('Argument: '+el);

The OptionSet class is the main class for the options parser, first you have to define the different options by using the “Add” method. The first parameter defines what option it maps to. in “s|source=”, there are two bindings for this option, “s” and “source”, the | just separates them. The “=” is used to denote that the option takes a parameter. “s” is a single letter option, to use it one can use “MyApp -ssourcefile.text”, or “MyApp –source sourcefile.text”, the short options do not have a space, and a single dash, the long options have a space and two dashes.

The second parameter for Add is the description, when writing out the option list it will print this (see below), the last parameter is a delegate that gets called when it’s triggered. This delegate (in the cases above we use anonymous methods) has one parameter with the value passed. From these anonymous methods we set the options we define in the variables above it, that way we can read them later on.

The last step is lOptionSet.Parse(arguments), this will return a list of “rest” parameters, anything that’s not an option (or parameter to an option) will be in this list. It will raise an exception when there’s an error parsing arguments. We set the lShowHelp to true in this case, so we can later write the options to the console with WriteOptionDescriptions.

Using the Ndesk.Options classes makes parsing parameters a lot easier than doing it manually. The OptionSet classes have a lot more features, all of which are documented at the top of the source file Options.pas.

The original version of this article can be found in our wiki.

Profile photo of marc

by marc

Dogfooding the new “Oxygene 5” Compiler

July 19, 2011 in .NET, Bugs 7, Data Abstract, Elements, Linux, Mac, Mono, Oxygene, Windows

Here at RemObjects, we’ve always been great fans of so-called “dogfooding” – the act of using your own products early on in the beta cycle. As you know, we create developer products, and nothing helps us drive and test those more than actually using the products ourselves actively. For example, creating “Bugs”, the Mac (and later iOS) version of the client for our internal bug tracking system (which I plan to write more about soon, as well) is what largely drove the development of Data Abstract for Xcode from “early alpha” up to way past its initial release.

As I’ve talked about in the past few blog posts, we’re gearing up towards a major new release of our compiler, with the upcoming Prism XE2 release (Soon™) and Project “Cooper” (later this fall). Both of these product releases mark the availability of a brand new compiler, the “Oxygene 5” compiler.

Oxygene 5 is not just an incremental update to the old compiler code base (not that there is anything wrong with that), but for various reasons, we actually went and rewrote the entire thing from scratch. Literally, there’s not a single line of code in the core compiler that’s shared with version 4.0 and earlier. This has been a project that’s been over a year in the making, and over the past couple of weeks, we made some important steps in terms of getting ready to really dogfood the new compiler ourselves, all across the company.

#1: We’ve updated all our build machines to use the new compiler. Being a distributed development team, we rely heavily on our automated build system (another topic I will write more about soon), so putting the new compiler on there is a big step. But we did, and indeed it showed us a few more bugs here and there, and we fixed those, but all in all, everything worked fine. So all our Oxygene-based products were now being build with the new compiler. That includes most parts of Oxygene itself (including the core compiler, which we migrated from C# to Pascal in the rewrite), Hydra, Data Abstract for .NET, Relativity Server, and a range of other smaller tools.

#2: So our new products were being build with Oxygene 5 now (and reasonably passed our automated testing), but did they work, too? Only one way to find out, so the next step was to update our build systems with a version of Oxygene 5 that was created on the new build system. This is called a “generation 2” compiler (generation 0 being the old, trusted 4.0 compiler, and generation 1 the new compiler, built using the old, trusted 4.0. generation 2 is the new compiler, built with (a few hours or minutes older version of) the same, new compiler).

So at this stage, our build system was relying on the generation 1 compiler having been stable enough to build a generation 2 compiler that in turn was stable enough to build all our products (including, of course, itself). If that works (and it did), you know you have something fairly solid.

Since then, we never had to go back to gen0 or gen1 on our build system. So as we improve the compiler, fix more bugs and add more features, we regularly update our build system to newer versions of the compiler, but all of these are post-gen2.

#3: But why stop there? Our build infrastructure is a sophisticated distributed system that makes a lot of use of Data Abstract, including DA LINQ (and LINQ is one of the trickiest parts of the compiler, from what Carlo tells me ;)). So our next step was to update all the servers that make up our build system and replace them with versions that (a) have been built using the latest compiler and (b) use the latest build of Data Abstract for .NET, in turn generated on our build system, with that latest compiler.

So by now our build system is completely driven by tools created with gen2+ versions of the Oxygene 5 compiler. And everything is running fine across our various build servers (which include services running under Windows, Linux and Mac OS X) – so that’s pretty good coverage.

Of course these exercises did not all go completely without a hitch. For example, we ran into some nasty-to-debug issues where our servers would run fine on Windows, but fail badly on Mono. Turns out Mono did not allow for some corner case (but within spec) IL constructs that the new compiler generated. We fixed the compiler to generate “more conventional” code – and logged bugs with the Mono guys, as well.

#4: So what else can we try to break? Our main website [](] is written completely in ASP.NET with Oxygene and Data Abstract. We run two copies of that site, one that is live and one that acts as a staging platform to test new things (but most of the time is identical to the live site, short of some minor differences, such as showing debug information or non-live versions of texts from the database). The staging version is now running with a gen2+ Oxygene 5 compiler and using the latest Data Abstract, as well – and all is functioning. Switching the production site over would be a technicality, and something we’ll probably do any day now.

#5: And last but not least, all of our internal developers that develop in Oxygene (even those not involved with the Oxygene product itself, such as our Data Abstract for .NET team, or people like me working on internal tools) are now using daily Oxygene 5 builds for their day-to-day work.

So. It goes without saying that even the scenarios I described above don’t provide complete coverage, and of course we still heavily rely on thousands of automated tests, as well as feedback from beta testers on their real-life projects. But I think we’re in pretty good shape with the new compiler – and I’m looking forward to ship it to you guys soon.

Stay Tuned for More

Read more about Delphi Prism at
Read more about Project Cooper, currently in beta, at

RemObjects (ECMA) Script

May 13, 2011 in .NET, Data Abstract, Linux, Mac, Mono, Windows

We recently finished a new version of RemObjects Script (Old version, New version), our open source implementation of the ECMAScript (JavaScript) language.

This new version is a complete rewrite that follows the exact rules of ECMAScript 5 to the letter, meaning it conforms to the ECMAScript 5 conformance test suite.

The dependency on the Microsoft Dynamic Language Runtime (DLR) has been dropped and thus speed has improved a lot. The engine is written in Delphi Prism with the Oxygene language, and is now licensed under the BSD license.

The engine was rewritten for two reasons: The original was written loosely based on EcmaScript 3, so the rewrite gives us full V5 support. The second reason was that the DLR was slowing it down a lot, and the abstractions and optimizations in the DLR are overkill for a language as simple as ECMAScript, with only a few internal types. The new version is built based on DynamicMethod and emits IL directly, making it very fast to run.

The RemObjects Script project is a key part of the Business Rules Scripting support in our Data Abstract for .NET product. Just as we released our Internet Pack library as open source, we do the same with RemObjects Script. This means you can freely use RemObjects Script in your Delphi Prism or any .NET project to add automation to your projects, too.

The usage instructions can be found at Using RemObjects Script.

What are you thankful for about Oxygene / Delphi Prism?

November 25, 2010 in .NET, Delphi, Elements, Hydra, Mono, MonoDevelop, MonoTouch, Oxygene, Personal, Visual Studio, Xcode

Oxygene compilerI originally planned to write all these Thanksgiving week posts ahead of time, and then schedule them, but that didn’t happen. So it is Thanksgiving morning and I am using the Wifi from my remote office in Boise (aka the kitchen table of my sister-in-law’s house) to post this one.  Going to head over to my mother-in-law’s for turkey and trimmings shortly.  Happy Thanksgiving to anyone else in the United States, and Happy Thursday to the rest of you.

RemObjects makes Oxygene, which is heart of Delphi Prism.  Whatever you call it, it is pretty amazing technology.  It supports all the latest .NET features and lets us develop .NET applications in Pascal.  There is a lot to thankful about it, but I will a few things about it.

  1. Parallel Extensions – Baked right into the language with Parallel Loops and Futures.
  2. Aspect Orientated ProgrammingThe Cirrus AOP Framework lets you reprogram the compiler.
  3. Class Contracts – The Class Contract support lets you include pre-conditions and post-conditions on methods.
  4. Windows Presentation Foundation – Microsoft’s new vector based GUI widget system.
  5. Silverlight – A cross platform rich web application framework, similar to Windows Presentation Foundation.
  6. Windows Phone 7 – Microsoft’s new Windows Phone 7 uses Silverlight for application development,  and did I mention Delphi Prism does Silverlight?
  7. Mono Support – Cross platform Linus and Mac OS X application development.
  8. MonoTouch – iPhone application development.
  9. MonoDroid – Android application development.
  10. Works Great with Hydra – Combined with Hydra it is the easiest way to combine .NET and Delphi native features in the same application.  Did I mention we have a combo deal on the two of them?

Just found out that they moved up our Thanksgiving dinner plans, so I need to go before I finished my list.  Hopefully you can help finish the list for me in the comments bellow.  So, what are you thankful for about Oxygene / Delphi Prism?

EKON 14 Recap

September 29, 2010 in Delphi, Mono, MonoDevelop, Oxygene

Right now I’m on my way back home from the Entwickler-Konferenz (EKON) 14 in Darmstadt, Germany. Jim is still there, but I have other duties so I left a day before the conference ends officially.

I had two sessions, the first yesterday was about Delphi Prism language specialties where I talked about cool features like class contracts and also interface delegation. Today I talked about multi platform development with Delphi Prism, concentrating on the apple platforms, both the Mac and iOS using Mono and MonoTouch for the iPhone/iPad.

I also sneaked into other sessions. There was a ‘how do I hack VCL programs’ session that really showed some interesting debugging, dumping and assembler-modification to crack a dongle protected native Delphi application as well as Holger Klemt talking about his personal experience with guys cracking is IBExpert software and what he did against that. Also Ray Konopka had a very interesting session about the Ribbon UI in general.

I especially enjoyed Max Kleiners talk about our PascalScript. Until today I didn’t knew he had built sort of a little IDE for it, called maxBox. It’s a scripting toolbox with a *lot* of scripatble functionality. He showed (beside other things) how to download a (free) mp3 file from the internet and directly played it from a little script – it was awesome (the demo, that is. Not the music, actually ;) ). maxBox, just like PascalScript that powers the IDE, is open source and you can get the sources from sourceforge. You can find more information about it here: . So go and check it out, it also brings script debugging and syntax highlighting with it and really is a good start for a little scripting with pascal script. At this point I really like to say thanks to Max. Doing that for the purpose of teaching programming and open sourcing the tool is a nice gesture.

Next speaking opportunity for me is at the Embarcadero CodeRage 5 online conference where I have two sessions on Thursday next week. One is about LINQ with Delphi Prism and the other about Hydra, so join me there if you like to. It’s totally online, so no shoes? No shirt? No problem! ;)

Delphi Prism on the iPhone

September 9, 2010 in .NET, Elements, iOS, Mono, MonoDevelop, MonoTouch, Oxygene, short, Tools

If you wanted to develop iOS applications with Delphi Prism (or Monotouch in general), there was this potential licencing problem, as long as you wanted to sell your app through the Apple AppStore (i.e. not using Enterprise deployment).

Here’s the good News: This is now history!
Today Apple announced to “relax all restrictions on the development tools used to create iOS apps, as long as the resulting apps do not download any code”.

This is a big relief for all those that wanted to write mono-based Applications for iOS but didn’t want to take risk that Apple’s going to decline the App for that reason. Additionally, Apple is going to publish their review guidelines, so that you know what’s allowed and what isn’t in detail before writing your software.

So, now you’re officially allowed to have fun and earn money with Delphi Prism on iOS. Enjoy it :)

Profile photo of marc

by marc

Delphi Prism XE is Available Now!

August 30, 2010 in Elements, Mono, MonoDevelop, Oxygene, RemObjects, short, Visual Studio


This is just a quick post to let you know that Delphi Prism XE is available now.

XE is a pretty minor update to Delphi Prism over the Delphi prism 2011 release we shipped in May, but it does contain quite a few fixes, tweaks and enhancements, so it’s an update we are very excited about getting out to users.

If you already have Delphi Prism 2011 (whether standalone or via a recent purchase of RAD Studio or a RAD Studio with SE), your existing serial number will work out of the box, and you can grab the trial download to upgrade. No need to wait for that email from Embarcadero. If you have RAD Studio 2010 without SA, you will need to upgrade to XE (or get SA) – but on the plus side, that means you’re currently still on Delphi Prism 2010, which makes the XE release much more exciting for you, as it will bring you a lot of new stuff, starting with VisualStudio 2010 and MonoDevelop IDE support.

You can find a complete list of changes in Delphi Prism XE at (check also the Delphi Prism 2011 section, if you are coming from 2011. Yes, you will need to scroll down quite a bit!)

And, of course, you can grab the trial version from Note that there’s a separate download for the edition that integrates onto MonoDevelop/Mac (the regular Windows installer includes support for MonoDevelop/Windows).


Profile photo of marc

by marc

Delphi Live — Day 1 Recap

August 25, 2010 in .NET, Delphi, Elements, Mono, MonoDevelop, MonoTouch, non-tech, Oxygene, Personal, RemObjects

Day one of Delphi Live has been great, here in San Jose. After the morning Keynote with David I, Michael Swindell, Tony de la Lama and Mike Rozlog and the official launch of RAD Studio XE, Andreano Lanusse gave a whirlwind tour of the cross platform capabilities in Delphi Prism XE — which included creating a ASP.NET web service in Visual Studio 2010 and deploying it to his Linux VM to run in Apache with mod_mono, and using MonoDevelop on the Mac to create an iOS application for the iPhone using MonoTouch (creating a web browser seems to be the Hello World of the iOS platform).

The highlight of the day most definitely was the return of Jim McKeeth‘s Delphi Bots Live, a hands on session where the audience was invited to program a bot for the Unreal Tournament ego-shooter game to fight and hunt down Jim’s real-live player. The battle raged on for over two hours, and participation was great, with people using Delphi Prism in Visual Studio, MonoDevelop and even in Notepad with the command line compiler to create their bots. In fact, Michael Swindell was so successful developing his bot with the command line compiler that we have decided to pull Visual Studio support from the product, and to concentrate our development efforts on Notepad, moving forward.


San Jose City Hall; collage of multiple exposures
shot with the iPhone 4 and “See This