.NET Foundation: Advisory Council

Do you know of someone that would like to participate in the .NET foundation, as part of the .NET Foundation Advisory Council?

Check the discussion where we are discussing the role of the Advisory Council.

Posted on 01 Dec 2014 by Miguel de Icaza

Microsoft Open Sources .NET and Mono

Today, Scott Guthrie announced that Microsoft is open sourcing .NET. This is a momentous occasion, and one that I have advocated for many years.

.NET is being open sourced under the MIT license. Not only is the code being released under this very permissive license, but Microsoft is providing a patent promise to ensure that .NET will get the adoption it deserves.

The code is being hosted at the .NET Foundation's github repository.

This patent promise addresses the historical concerns that the open source, Unix and free software communities have raised over the years.

.NET Components

There are three components being open sourced: the .NET Framework Libraries, .NET Core Framework Libraries and the RyuJit VM. More details below.

.NET Framework Class Libraries

These are the class libraries that power the .NET framework as it ships on windows. The ones that Mono has historically implemented in an open source fashion.

The code is available today from http://github.com/Microsoft/referencesource. Mono will be able to use as much a it wants from this project.

We have a project underway that already does this. We are replacing chunks of Mono code that was either incomplete, buggy, or not as fully featured as it should be with Microsoft's code.

We will be checking the code into github.com/mono by the end of the week (I am currently in NY celebrating :-)

Microsoft has stated that they do not currently plan on taking patches back or engaging into a full open source community style development of this code base, as the requirements for backwards compatibility on Windows are very high.

.NET Core

The .NET Core is a redesigned version of .NET that is based on the simplified version of the class libraries as well as a design that allows for .NET to be incorporated into applications.

Those of you familiar with the PCL 2.0 contract assemblies have a good idea of what these assemblies will look like.

This effort is being hosted at https://github.com/dotnet/corefx and is an effort where Microsoft will fully engage with the community to evolve, develop and improve the class libraries.

Today, they released the first few components to github; the plan is for the rest of the redesigned frameworks to be checked in here in the next few months.

Xamarin and the Mono project will be contributing to the efforts to bring .NET to Mac, Unix, Linux and other platforms. We will do this as Microsoft open sources more pieces of .NET Core, including RyuJIT.

Next Steps

Like we did in the past with .NET code that Microsoft open sourced, and like we did with Roslyn, we are going to be integrating this code into Mono and Xamarin's products.

Later this week, expect updated versions of the Mono project roadmap and a list of tasks that need to be completed to integrate the Microsoft .NET Framework code into Mono.

Longer term, we will make the Mono virtual machine support the new .NET Core deployment model as well as the new VM/class library interface

We are going to be moving the .NET Core discussions over to the .NET Foundation Forums.

With the Mono project, we have spent 14 years working on open source .NET. Having Microsoft release .NET and issue a patent covenant will ensure that we can all cooperate and build a more vibrant, richer, and larger .NET community.

Posted on 12 Nov 2014 by Miguel de Icaza

Mono for Unreal Engine

Earlier this year, both Epic Games and CryTech made their Unreal Engine and CryEngine available under an affordable subscription model. These are both very sophisticated game engines that power some high end and popular games.

We had previously helped Unity bring Mono as the scripting language used in their engine and we now had a chance to do this over again.

Today I am happy to introduce Mono for Unreal Engine.

This is a project that allows Unreal Engine users to build their game code in C# or F#.

Take a look at this video for a quick overview of what we did:

This is a taste of what you get out of the box:

  • Create game projects purely in C#
  • Add C# to an existing project that uses C++ or Blueprints.
  • Access any API surfaced by Blueprint to C++, and easily surface C# classes to Blueprint.
  • Quick iteration: we fully support UnrealEngine's hot reloading, with the added twist that we support it from C#. This means that you hit "Build" in your IDE and the code is automatically reloaded into the editor (with live updates!)
  • Complete support for the .NET 4.5/Mobile Profile API. This means, all the APIs you love are available for you to use.
  • Async-based programming: we have added special game schedulers that allow you to use C# async naturally in any of your game logic. Beautiful and transparent.
  • Comprehensive API coverage of the Unreal Engine Blueprint API.

This is not a supported product by Xamarin. It is currently delivered as a source code package with patches that must be applied to a precise version of Unreal Engine before you can use it. If you want to use higher versions, or lower versions, you will likely need to adjust the patches on your own.

We have set up a mailing list that you can use to join the conversation about this project.

Visit the site for Mono for Unreal Engine to learn more.

(I no longer have time to manage comments on the blog, please use the mailing list to discuss).

Posted on 23 Oct 2014 by Miguel de Icaza

.NET Foundation: Forums and Advisory Council

Today, I want to share some news from the .NET Foundation.

Forums: We are launching the official .NET Foundation forums to engage with the larger .NET community and to start the flow of ideas on the future of .NET, the community of users of .NET, and the community of contributors to the .NET ecosystem.

Please join us at forums.dotnetfoundation.org. We are using the powerful Discourse platform. Come join us!

Advisory Council: We want to make the .NET Foundation open and transparent. To achieve that goal, we decided to create an advisory council. But we need your help in shaping the advisory council: its role, its reach, its obligations and its influence on the foundation itself.

To bootstrap the discussion, we have a baseline proposal that was contributed by Shaun Walker. We want to invite the larger .NET community to a conversation about this proposal and help us shape the advisory council.

Check out the Call for Public Comments which has a link to the baseline proposal and come join the discussion at the .NET Forums.

Posted on 14 Oct 2014 by Miguel de Icaza

Markdown Style Guide

Markdown is as a file format for easily producing text that can be pleasantly read both on the web and while using command line tools, or plain text editors.

Recently, a crop of tools have emerged that deliver some form of WYSIWYG or side-by-side authoring tools to assist writers to visualize the final output as they work.

Authors are turning to these tools to produce documentation that looks good when authoring the document, yet the tools are not true to the spirit and goals of markdown. And in some cases, authors are not familiar with the essence of what makes markdown great, nor the philosophy behind it:

Readability, however, is emphasized above all else. A Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions.

Using these editors is the modern equivalent of using Microsoft Word to produce HTML documentation.

The generated markdown files very easy to produce, but are not suitable for human consumption. They likely violate a number of international treaties and probably will be banned by the EU.

This short post is a set of simple rules to improve your markdown.

They will help you deliver delight to all of your users, not just those using a web browser, but also those casually reading your documentation with a file manager, their console, and most importantly, potential contributors and copy editors that have to interact with your text.

Wrap Your Text

The ideal reading length for reading prose with a monospaced font is somewhere between 72 and 78 characters.

This is text snippet is from Mark Twain's Adventures of Tom Sawyer, with text wrapped around column 72, when reading in an 80x25 console:

It wont matter if you are using a larger console, the text will still be pleasant to read.

But if you use some of these markdown editors that do not bother wrapping your text, this is what the user would get:

And this is what is more likely to happen, with big consoles on big displays:

There is a reason why most web sites set a maximum width for the places where text will be displayed. It is just too obnoxious to read otherwise.

Many text editors have the ability of reformatting text your text when you make changes.

This is how you can fill your text in some common editors:

  • Emacs: Alt-Q will reformat your paragraph.
  • Vim: "V" (to start selection) then "gq" will reformat your selection.
  • TextMate: Control-Q.

Considering Using Two Spaces After a Period

When reading text on the console, using two spaces after a period makes it easier to see where phrases end and start.

While there is some debate as to the righteouness of one vs two spaces in the word of advanced typography these do not apply to markdown text. When markdown is rendered into HTML, the browser will ignore the two spaces and turn it into one, but you will give your users the extra visual cues that they need when reading text.

If you are interested in the topic, check these posts by Heraclitean River and DitchWalk.

Sample Code

For small code snippets, it is best if you just indent your code with spaces, as this will make your console experience more pleasant to use.

Recently many tools started delimiting code with the "```". While this has its place in large chunks of text, for small snippets, it is the visual equivalent of being punched in the face.

Try to punch your readers in the face only when absolutely necessary.

Headers

Unless you have plans to use multiple-nested level of headers, use the underline syntax for your headers, as this is visually very easy to scan when reading on a console.

That is, use:

Chapter Four: Which iPhone 6 is Right For You.
==============================================

In the previous chapter we established the requirement to buy iPhones
in packs of six.  Now you must choose just whether you are going to go
for an apologetically aluminum case, or an unapologetically plastic
iPhone.
	

Instead of the Atx-style headers:

# Chapter Four: Which iPhone 6 is Right For You.
	

The second style can easily drown in a body of text, and can not help as a visual aid to see where new sections start.

Blockquotes

While markdown allows you to only set the first character for a blockquote, like this:

> his is a blockquote with two paragraphs. Lorem ipsum dolor sit amet,
consectetuer adipiscing elit. Aliquam hendrerit mi posuere lectus.
Vestibulum enim wisi, viverra nec, fringilla in, laoreet vitae, risus.
	

Editors like Emacs, can reformat that text just fine, all you have to do is set the "Fill Prefix", by positioning your cursor after the "> " and use Control-x ., then you can use the regular fill command: Alt-Q, and this will produce:

> This is a blockquote with two paragraphs. Lorem ipsum dolor sit amet,
> consectetuer adipiscing elit. Aliquam hendrerit mi posuere
> lectus. Vestibulum enim wisi, viverra nec, fringilla in, laoreet
> vitae, risus.

Lists

Again, while Markdown will happily allow you to write things like:

*   Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
Aliquam hendrerit mi posuere lectus. Vestibulum enim wisi,
viverra nec, fringilla in, laoreet vitae, risus.
*   Donec sit amet nisl. Aliquam semper ipsum sit amet velit.
Suspendisse id sem consectetuer libero luctus adipiscing.

You should love your reader, and once again, if you are using something like Emacs, use the fill prefix to render the list like this instead:

*   Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
    Aliquam hendrerit mi posuere lectus. Vestibulum enim wisi,
    viverra nec, fringilla in, laoreet vitae, risus.
*   Donec sit amet nisl. Aliquam semper ipsum sit amet velit.
    Suspendisse id sem consectetuer libero luctus adipiscing.	
Posted on 30 Sep 2014 by Miguel de Icaza

Three Tricks in Xamarin Studio

I wanted to share three tricks that I use a lot in Xamarin Studio/MonoDevelop.

Trick 1: Navigate APIs

Xamarin Studio's code completion for members of an object defaults to showing all the members sorted by name.

But if you press Control-space, it toggles the rendering and organizes the results. For example, for this object of type UIWindow, it first lists the methods available for UIWindow sorted by name, and then the cluster for its base class UIView:

This is what happens if you scroll to the end of the UIWindow members:

Trick 2: Universal Search

Use the Command-. shortcut to activate the universal search, once you do this and start typing it will find matches for both members and types in your solution, as well as IDE commands and the option to perform a full text search:

Trick 3: Dynamic Abbreviation Completion

This is a feature that we took from Emacs's Dynamic Abbrevs.

If you type Control-/ when you type some text, the editor will try to complete the text you are typing based on strings found in your project that start with the same prefix.

Hit control-/ repeatedly to cycle over possible completions.

Posted on 20 Aug 2014 by Miguel de Icaza

Five Cross Platform Pillars

The last couple of years have been good to C# and .NET, in particular in the mobile space.

While we started just with a runtime and some basic bindings to Android and iOS back in 2009, we have now grown to provide a comprehensive development stack: from the runtime, to complete access to native APIs, to designers and IDEs and to a process to continuously deliver polish to our users.

Our solution is based on a blend of C# and .NET as well as bindings to the native platform, giving users a spectrum of tools they can use to easily target multiple platforms without sacrificing quality or performance.

As the industry matured, our users found themselves solving the same kinds of problems over and over. In particular, many problems related to targeting multiple platforms at once (Android, iOS, Mac, WinPhone, WinRT and Windows).

By the end of last year we had identified five areas where we could provide solutions for our users. We could deliver a common framework for developers, and our users could focus on the problem they are trying to solve.

These are the five themes that we identified.

  • Cross-platform UI programming.
  • 2D gaming/retained graphics.
  • 2D direct rendering graphics.
  • Offline storage, ideally using SQLite.
  • Data synchronization.

Almost a year later, we have now delivered four out of the five pillars.

Each one of those pillars is delivered as a NuGet package for all of the target platforms. Additionally, they are Portable Class Libraries, which allows developers to create their own Portable Class Libraries on top of these frameworks.

Cross Platform UI programming

With Xamarin 3.0 we introduced Xamarin.Forms, which is a cross-platform UI toolkit that allows developers to use a single API to target Android, iOS and WinPhone.

Added bonus: you can host Xamarin.Forms inside an existing native Android, iOS or WinPhone app, or you can extend a Xamarin.Forms app with native Android, iOS or WinPhone APIs.

So you do not have to take sides on the debate over 100% native vs 100% cross-platform.

Many developers also want to use HTML and Javascript for parts of their application, but they do not want to do everything manually. So we also launched support for the Razor view engine in our products.

2D Gaming/Retained Graphics

Gaming and 2D visualizations are an important part of applications that are being built on mobile platforms.

We productized the Cocos2D API for C#. While it is a great library for building 2D games -and many developers build their entire experiences entirely with this API- we have also extended it to allow developers to spice up an existing native application.

We launched it this month: CocosSharp.

Offline Storage

While originally our goal was to bring Mono's System.Data across multiple platforms (and we might still bring this as well), Microsoft released a cross-platform SQLite binding with the same requirements that we had: NuGet and PCL.

While Microsoft was focused on the Windows platforms, they open sourced the effort, and we contributed the Android and iOS ports.

This is what powers Azure's offline/sync APIs for C#.

In the meantime, there are a couple of other efforts that have also gained traction: Eric Sink's SQLite.Raw and Frank Krueger's sqlite-net which provides a higher-level ORM interface.

All three SQLite libraries provide NuGet/PCL interfaces.

Data Synchronization

There is no question that developers love Couchbase. A lightweight NoSQL database that supports data synchronization via Sync gateways and Couchbase servers.

While Couchbase used to offer native Android and iOS APIs and you could use those, the APIs were different, since each API was modeled/designed for each platform.

Instead of writing an abstraction to isolate those APIs (which would have been just too hard), we decided to port the Java implementation entirely to C#.

The result is Couchbase Lite for .NET. We co-announced this development with Couchbase back in May.

Since we did the initial work to bootstrap the effort, Couchbase has taken over the maintenance and future development duties of the library and they are now keeping it up-to-date.

While this is not yet a PCL/NuGet, work is in progress to make this happen.

Work in Progress: 2D Direct Rendering

Developers want to have access to a rich API to draw. Sometimes used to build custom controls, sometimes used to draw charts or to build entire applications based on 2D rendered API.

We are working on bringing the System.Drawing API to all of the mobile platforms. We have completed an implementation of System.Drawing for iOS using CoreGraphics, and we are now working on both an Android and WinPhone implementations.

Once we complete this work, you can expect System.Drawing to be available across the board as a NuGet/PCL library.

If you can not wait, you can get your hands today on the Mac/iOS version from Mono's repository.

Next Steps

We are now working with our users to improve these APIs. But we wont stop at the API work, we are also adding IDE support to both Xamarin Studio and Visual Studio.

Posted on 20 Aug 2014 by Miguel de Icaza

Mono Performance Team

For many years a major focus of Mono has been to be compatible-enough with .NET and to support the popular features that developers use.

We have always believed that it is better to be slow and correct than to be fast and wrong.

That said, over the years we have embarked on some multi-year projects to address some of the major performance bottlenecks: from implementing a precise GC and fine tuning it for a number of different workloads to having implemented now four versions of the code generator as well as the LLVM backend for additional speed and things like Mono.SIMD.

But these optimizations have been mostly reactive: we wait for someone to identify or spot a problem, and then we start working on a solution.

We are now taking a proactive approach.

A few months ago, Mark Probst started the new Mono performance team. The goal of the team is to improve the performance of the Mono runtime and treat performance improvements as a feature that is continously being developed, fine-tuned and monitored.

The team is working both on ways to track performance of Mono over time, implemented support for getting better insights into what happens inside the runtime and has implemented several optimizations that have been landing into Mono for the last few months.

We are actively hiring for developers to join the Mono performance team (ideally in San Francisco, where Mark is based).

Most recently, the team added a new and sophisticated new stack for performance counters which allows us to monitor what is happening on the runtime, and we are now able to export to our profiler (a joint effort between our performance team and our feature team and implemented by Ludovic). We also unified both the runtime and user-defined performance counters and will soon be sharing a new profiler UI.

Posted on 23 Jul 2014 by Miguel de Icaza

Better Crypto: Did Snowden Succeed?

Snowden is quoted on Greenwald's new book "No Place to Hide" as wanting to both spark a debate over the use of surveillance and to get software developers to adopt and create better encryption:

While I pray that public awareness and debate will lead to reform, bear in mind that the policies of men change in time, and even the Constitution is subverted when the appetites of power demand it. In words from history: Let us speak no more of faith in man, but bind him down from mischief by the chains of cryptography.

[...]

The shock of this initial period [after the first revelations] will provide the support needed to build a more equal internet, but this will not work to the advantage of the average person unless science outpaces law. By understanding the mechanisms through which our privacy is violated, we can win here. We can guarantee for all people equal protection against unreasonable search through universal laws, but only if the technical community is willing to face the threat and commit to implementing over-engineered solutions.

Last week Matthew Green asked:

Only time will be able to answer whether as a community the tech world can devise better and simpler tools for normal users to have their privacy protected by default.

Snowden has succeeded in starting an important discussion and having software developers and their patrons react to the news.

At Xamarin we build developer tools for Android and iOS developers. It is our job to provide tools that developers use on a day to day basis to build their applications, and we help them build these mobile applications.

In the last year, we have noticed several changes in our developer userbase. Our customers are requesting both features and guidance on a number of areas.

Developers are reaching to us both because there is a new understanding about what is happening to our electronic communications and also response to rapidly changing requirements from the public and private sectors.

Among the things we have noticed:

  • Using Trusted Roots Respectfully: For years, we tried to educate our users on what they should do when dealing with X509 certificates. Two years ago, most users would just pick the first option "Ignore the problem".
    Today this is no longer what developers do by default.
  • Certificate Pinning: more than ever, developers are using certificate pinning to ensure that their mobile applications are only talking to the exact party they want to.
  • Ciphersuite Selection: We recently had to extend the .NET API to allow developers to force our networking stack to control which cipher suites the underlying SSL/TLS stack uses. This is used to prevent weak or suspected ciphersuites to be used for the communications.
  • Request for more CipherSuites: Our Mono runtime implements its own SSL/TLS and crypto stacks entirely in C#. Our customers have asked us to support new cipher suites on newer versions of the standards.

Sometimes developers can use the native APIs we provide to achieve the above goals, but sometimes the native APIs on Android and iOS make this very hard or do not expose the new desired functionality, so we need to step in.

Posted on 21 May 2014 by Miguel de Icaza

News from the .NET World

Some great announcements today from the Microsoft world.

#1 Open Source ASP.NET stack

The first one is that Microsoft's next generation web stack (ASP.NET vNext) is open source from the ground up, and runs on Mono on both Linux and Mac.

There are plenty of other design principles in this new version of ASP.NET. I provide a translation from Microsoft speak into Unix speak in parenthesis:

  • Cloud-ready out of the box (this is code name for "can run with different versions of .NET side by side").
  • A single programming model for Web sites and services
  • Low-latency developer experience (Refresh on browser recompiles)
  • Make high-performance and high-productivity APIs and patterns available - enable them both to be used and compose together within a single app.
  • Fine-grained control available via command-line tools and standard file formats.
  • Delivered via NuGet (package manager, similar to Node's NPM or Ruby Gems).
  • Release as open source via the .NET Foundation.
  • Can run on Mono, on Mac and Linux.

Update: And the software is live at http://github.com/aspnet

Client Libraries to Microsoft Services

They are shipping a number of new components to talk to their online services, and they all have a license suitable for being used from platforms other than Windows.

Posted on 12 May 2014 by Miguel de Icaza

Roslyn Update

As promised, we are now tracking the Unix-friendly Roslyn port on Mono's GitHub Organization.

We implemented a few C# 6.0 features in Mono's C# compiler to simplify the set of patches required to compile Roslyn.

So you will need a fresh Mono (from git).

Posted on 28 Apr 2014 by Miguel de Icaza

Documentation for our new iOS Designer

The team has put together some beautiful getting started documentation for our iOS User Interface Designer.

In particular, check a couple of hot features on it:

Posted on 14 Apr 2014 by Miguel de Icaza

Mono on PS4

We have been working with a few PlayStation 4 C# lovers for the last few months. The first PS4 powered by Mono and MonoGame was TowerFall:

We are very excited about the upcoming Transistor, by the makers of Bastion, coming out on May 20th:

Mono on the PS4 is based on a special branch of Mono that was originally designed to support static compilation for Windows's WinStore applications [1].

[1] Kind of not very useful anymore, since Microsoft just shipped static compilation of .NET at BUILD. Still, there is no wasted effort in Mono land!

Posted on 14 Apr 2014 by Miguel de Icaza

Mono and Roslyn

Last week, Microsoft open sourced Roslyn, the .NET Compiler Platform for C# and VB.

Roslyn is an effort to create a new generation of compilers written in managed code. In addition to the standard batch compiler, it contains a compiler API that can be used by all kinds of tools that want to understand and manipulate C# source code.

Roslyn is the foundation that powers the new smarts in Visual Studio and can also be used for static analysis, code refactoring or even to smartly navigate your source code. It is a great foundation that tool developers will be able to build on.

I had the honor of sharing the stage with Anders Hejlsberg when he published the source code, and showed both Roslyn working on a Mac with Mono, as well as showing the very same patch that he demoed on stage running on Mono.

Roslyn on Mono

At BUILD, we showed Roslyn running on Mono. If you want to run your own copy of Roslyn today, you need to use both a fresh version of Mono, and apply a handful of patches to Roslyn [2].

The source code as released contains some C# 6.0 features so the patches add a bootstrapping phase, allowing Roslyn to be built with a C# 5.0 compiler from sources. There are also a couple of patches to deal with paths (Windows vs Unix paths) as well as a Unix Makefile to build the result.

Sadly, Roslyn's build script depends on a number of features of MSBuild that neither Mono or MonoDevelop/XamarinStudio support currently [3], but we hope we can address in the future. For now, we will have to maintain a Makefile-based system to use Roslyn.

Our patches no longer apply to the tip of Roslyn master, as Roslyn is under very active development. We will be updating the patches and track Roslyn master on our fork moving forward.

Currently Roslyn generates debug information using a Visual Studio native library. So the /debug switch does not work. We will be providing an alternative implementation that uses Mono's symbol writer.

Adopting Roslyn: Mono SDK

Our goal is to keep track of Roslyn as it is being developed, and when it is officially released, to bundle Roslyn's compilers with Mono [6].

But in addition, this will provide an up-to-date and compliant Visual Basic.NET compiler to Unix platforms.

Our plans currently are to keep both compilers around, and we will implement the various C# 6.0 features into Mono's C# compiler.

There are a couple of reasons for this. Our batch compiler has been fine tuned over the years, and for day-to-day compilation it is currently faster than the Roslyn compiler.

The second one is that our compiler powers our Interactive C# Shell and we are about to launch something very interesting with it. This functionality is not currently available on the open sourced Roslyn stack.

In addition, we plan on distributing the various Roslyn assemblies to Mono users, so they can build their own tools on top of Roslyn out of the box.

Adopting Roslyn: MonoDevelop/Xamarin Studio

Roslyn really shines for use in IDEs.

We have started an effort to adopt Roslyn in MonoDevelop/Xamarin Studio. This means that the underlying NRefactory engine will also adopt Roslyn.

This is going to be a gradual process, and during the migration the goal is to keep using both Mono's C# compiler as a service engine and bit by bit, replace with the Roslyn components.

We are evaluating various areas where Roslyn will have a positive impact. The plan is to start with code completion [4] and later on, support the full spectrum of features that NRefactory provides (from refactoring to code generation).

C# Standard

While not related to Roslyn, I figured it was time to share this.

For the last couple of months, the ECMA C# committee has been working on updating the spec to reflect C# 5. And this time around, the spec benefits from having two independent compiler implementations.

Mono Project and Roslyn

Our goal is to contribute fixes to the Roslyn team to make sure that Roslyn works great on Unix systems, and hopefully to provide bug reports and bug fixes as time goes by.

We are very excited about the release of Roslyn, it is an amazing piece of technology and one of the most sophisticated compiler designs available. A great place to learn great C# idioms and best practices [5], and a great foundation for great tooling for C# and VB.

Thanks to everyone at Microsoft that made this possible, and thanks to everyone on the Roslyn team for starting, contributing and delivering such an ambitious project.

Notes

[1] Roslyn uses a few tracing APIs that were not available on Mono, so you must use a newer version of Mono to build Roslyn.

[2] We even include the patch to add french quotes that Anders demoed. Make sure to skip that patch if you don't want it :-)

[3] From Michael Hutchinson:

  • There are references of the form: <Reference Include="Microsoft.Build, Version=$(VisualStudioReferenceAssemblyVersion), Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
    This is a problem because our project system tries to load project references verbatim from the project file, instead of evaluating them from the MSBuild engine. This would be fixed by one of the MSBuild integration improvements I've proposed.
  • There's an InvalidProjectFileException error from the xbuild engine when loading one of the targets files that's imported by several of the code analysis projects, VSL.Settings.targets. I'm pretty sure this is because it uses MSBuild property functions, an MSBuild 4.0 feature that xbuild does not support.
  • They use the AllowNonModulatedReference metadata on some references and it's completely undocumented, so I have no idea what it does and what problems might be caused by not handling it in xbuild.
  • One project can't be opened because it's a VS Extension project. I've added the GUID and name to our list of known project types so we show a more useful error message.
  • A few of the projects depend on Microsoft.Build.dll, and Mono does not have a working implementation of it yet. They also reference other MSBuild assemblies which I know we have not finished.

[4] Since Roslyn is much better at error recovery and has a much more comprehensive support for code completion than Mono's C# compiler does. It also has much better support for dealing with incremental changes than we do.

[5] Modulo private. They use private everywhere, and that is just plain ugly.

[6] We will find out a way of selecting which compiler to use, either mcs (Mono's C# Compiler) or Roslyn.

Posted on 09 Apr 2014 by Miguel de Icaza

ISO C++ 2D API

Herb Sutter from the ISO C++ group, reached out to the Cairo folks:

We are actively looking at the potential standardization of a basic 2D drawing library for ISO C++, and would like to base it on (or outright adopt, possibly as a binding) solid prior art in the form of an existing library.

And also:

we are focused on current Cairo as a starting point, even though it's not C++ -- we believe Cairo itself it is very well written C (already in an OO style, already const-correct, etc.).

Congratulations to the Cairo guys for designing such a pleasant to use 2D API.

But this would not be a Saturday blog post without pointing out that Cairo's C-based API is easier and simpler to use than many of those C++ libraries out there. The more sophisticated the use of the C++ language to get some performance benefit, the more unpleasant the API is to use.

The incredibly powerful Antigrain sports an insanely fast software renderer and also a quite hostile template-based API.

We got to compare Antigrain and Cairo back when we worked on Moonlight. Cairo was the clear winner.

We built Moonlight in C++ for all the wrong reasons ("better performance", "memory usage") and was a decision we came to regret. Not only were the reasons wrong, it is not clear we got any performance benefit and it is clear that we did worse with memory usage.

But that is a story for another time.

Posted on 04 Jan 2014 by Miguel de Icaza
Older entries »
This is a personal web page. Things said here do not represent the position of my employer.