At the end of March, we announced the creation of the Technical Steering Group in the .NET Foundation. This was created to help open up how technical decisions are made in the .NET platform as well as keep everyone on the same page as to the direction of the combined projects that make up the core components of .NET. As V1.0 of .NET Core ships today and the tooling enters Preview 2, it is more important than ever that major stakeholders in the future of .NET can get together regularly and discuss the future direction of the platform overall. 

Today I’m thrilled to announce that Samsung are joining Microsoft, Red Hat, JetBrains and Unity in the Technical Steering Group. Samsung have been a major contributor to .NET Core in recent months and I’m hopeful that their increased involvement in the future of .NET will only help increase their participation.

.NET is a great technology that dramatically boosts developer productivity. Samsung has been contributing to .NET Core on GitHub – especially in the area of ARM support – and we are looking forward to contributing further to the .NET open source community. Samsung is glad to join the .NET Foundation's Technical Steering Group and help more developers enjoy the benefits of .NET.
-- Hong-Seok Kim, Vice President, Samsung Electronics

Today over half of the contributions to corefx and coreclr come from outside of Microsoft and that trend is increasing while the overall amount of contribution also keeps on growing. The early performance numbers show the performance of .NET Core is simply astounding – driven by the diverse mix of contributors to the platform.

The future of .NET is clearly very bright and seems to get better every day. I’m looking forward to working with Hong-Seok Kim and his team at Samsung along with everyone else in the .NET community to help bring the all benefits of .NET to more platforms and more developers.

-- Martin Woodward, Executive Director.

I'm proud to announce that Reactive Extensions for .NET has joined the .NET Foundation Family. While Rx.NET has been open source for a long time, this move signifies that the project is moving from one driven primarily by Microsoft to true cross-community ownership. Legends of .NET open source, Oren Novotny andBrendan Forster join Bart De Smet and Matthew Podwysocki as the new maintainers of the project so you know it's in the very best hands in the business.

We'll all be working to move things over in the next few days as we all get ready for the big 1.0 of .NET Core. In this guest post, Oren explains more about the move and what it means for the project. 

-- Martin

Announcing Rx and Ix 3.0

I'm honored to be one of the community maintainers alongside Brendan Forster, joining Bart De SmetMatthew Podwysocki and the team of reactive luminaries on this project.

The first thing to announce is that work has been ongoing to bring .NET Core support for Rx.NET and Ix.NET. The code is in a public beta form right now and you can check out the CI MyGet feed for regular builds. We'll have an RC2-compatible build on NuGet.org shortly and expect to GA alongside the rest of .NET Core on June 27.

Learn more about Reactive Programming with Rx over at http://reactivex.io/

Breaking Changes

There are two breaking changes to note in V3:

  1. Rx has a new Strong Name Key. This means that code must be recompiled against this new version; binding redirects will not work. The good news is that the SNK is now checked into the repository, so you can create private builds that are fully signed should you need to. This was not possible before as the existing SNK was the same key as the .NET Framework.

  2. The NuGet package names have changed. The Rx-* and Ix-* packages have been renamed to match their library names, keeping inline with the rest of .NET Core.
    - Use System.Reactive instead of Rx-Main
    - Use System.Interactive instead of Ix-Main
    - Use System.Interactive.Async instead of Ix-Async

If you find any issues, please file them over on GitHub. After we've got the V3.0 release out the door we're going to start working through the backlog that has built up in the project so please bear with us until the end of June while we get the initial community driven release out the door.  Come on over if you want to help out!

Oren Novotny, Co-Maintainer, Reactive Extensions for .NET

I love most forms of Cake and I've also been a bit of a build automation nut for nearly two decades now. So you can imagine my delight when I was able to combine these two passions with the CakeBuild.net project. At NDC Oslo today, Gary Ewan Park from the Cake project team announced that Cake was joining the .NET Foundation family. In this guest post, Gary explains more about the project. If it looks like it will be useful to you, I encourage you to give it a try and get involved in the growing community.

--Martin

What is Cake?

Cake is a cross platform build automation system, built on top of Roslyn and the Mono Compiler, which uses C# as the scripting language.

Currently, it supports running builds on:

  • Windows
  • Linux
  • OS X

Why use C#? Aren't there already other build systems out there?

We firmly believe that creating a reliable and maintainable build automation script is best done in the same language as the application that you are building. For example, if you are working on a Powershell project, it might make sense to use something like psake. If doing a web application, perhaps something like gulp. Working on an F# project, you might want to use FAKE.

Although we agree that being a polyglot developer is definitely a good thing, using a build script as a mechanism to pickup a new language is not the best approach. This normally leads to two things:

  • lack of adoption of that language across the team that you are working in
  • only one person, the person who started it, being in charge of said build script

Rather, if the build script is written in the same primary language of the project, then everyone on the team can be immediately effective at altering/fixing that build script.

Become immediately effective

On top of the fact that Cake allows you to create build scripts using a common language, out of the box, it has support for almost 30 of the most common build tools, including:

  • MSBuild
  • NUnit
  • XUnit
  • WiX
  • GitVersion
  • many others...

In addition, thanks to our growing and dedicated community members, we have almost 40 other build tools available via the addin mechanism which is baked into Cake. These addins include support for tools like:

  • Xamarin
  • CMake
  • Gulp
  • Npm
  • many others...

Ok, so how do I get started with Cake?

The best place to start with Cake would be the getting started guide. This will walk you through the process of using Cake to build an example project. From there, you can follow the setting up a new project guide.

More information

If you want to keep up to date with what is going on with Cake, be sure to subscribe to our blog feed and you can also follow us on twitter. In addition, if you have any questions or problems with Cake, you can join the Gitter chat room. There is almost always someone in the chat room, so feel free to ask any questions that you might have. Be sure to give cakebot, our resident hubot a botsnack when you drop by!

Thank You

Thank you very much for you interest in Cake, we truly hope that you find it as useful a tool as we have. Happy building! --Gary

Gary Ewan Park (@gep13), Project Maintainer, Cake (on behalf on the Cake maintainers and committers)

As .NET becomes more common cross-platform, a new generation of tools is emerging to help developers manage common workflows when using the same .NET code across multiple operating systems, runtimes and devices. Protobuild is one of these awesome emerging new tools and I've very proud to welcome them into the .NET Foundation. 

In this guest post, June Rhodes from the Protobuild project team explains more about the project. If it looks like it will be useful to you, I encourage you to give it a try and get involved in the growing community.

-- Martin

Do you develop cross-platform .NET projects? Maybe you manage them with multiple C# projects on disk for each platform or framework you want to target? Or maybe you use MSBuild conditionals to target multiple platforms and fore-go the use of Linux or Mac IDEs for .NET?

I had used both techniques before I developed Protobuild; a cross-platform project generator for C#. With my solutions often having 10 or more assemblies, manually keeping a Windows, Linux and Mac version of every project in sync as well as managing the references was difficult. As someone who frequently works on Linux, selecting the MSBuild option and foregoing the use of MonoDevelop wasn't an option either - I needed the ability to debug the software I was developing on all platforms.

I searched around for project generators at that point, but there weren't any particular good C# options. In addition I found that most of the project generators were one-way; if you wanted to add a file to your solution, you needed to open the cross-platform project definitions and add the file there. I wanted less overhead managing projects, so Protobuild supports two-way generation; when you add or remove files in your IDE, these changes get synchronised back to the cross-platform project definitions.

Over time Protobuild evolved to support more platforms; it now supports Windows, Linux, Mac (MonoMac, XamMac and Xamarin.Mac), iOS, tvOS, Android, Ouya, PCL (for bait-and-switch), Windows 8 Apps, Windows Phone 8, Windows Phone 8.1, Web (via JSIL) and most recently Universal Windows Apps - and you can target all of these platforms for your project just by selecting a drop-down

These days, Protobuild is used by cross-platform projects like MonoGame to manage their projects and dependencies. It's capable of cross-platform package management, and provides an automation layer for build server scripts.

If you're managing cross-platform .NET projects, and you'd like to try out or use Protobuild for your own projects, you can download it from the Protobuild website.

June Rhodes, Project Lead, Protobuild

The WiX toolset project holds a special place in my heart. I've built many installers in my time using the toolset and had nothing but positive interactions with the community as a developer, but also the WiX toolset was one of the very first open source projects that came out of Microsoft. Rob and his team blazed a trail that we where then able to follow with .NET and so many other open source projects afterwards. That is why I'm especially thrilled that now I get to work more with the project as they have decided to make the .NET Foundation their home.

For those few people who have been under a rock for the past decade and didn't know about it, the WiX toolset lets developers create installers for Windows Installer, the Windows installation engine used by many traditional desktop applications and also Windows Server installation mechanisms. The core of WiX is a set of build tools that build Windows Installer packages using the same build concepts as the rest of your product: source code is compiled and then linked to create executables; in this case .exe setup bundles, .msi installation packages, .msm merge modules, and .msp patches. The WiX command-line build tools work with any automated build system. Also, MSBuild is supported from the command line, there is an excellent Visual Studio integration along with links into Team Build / VSTS.

WiX includes several extensions that offer functionality beyond that of Windows Installer. For example, WiX can install IIS web sites, create SQL Server databases, and register exceptions in the Windows Firewall, among others. It's used by every single .NET development shop I know.

With Burn, the WiX bootstrapper, you can create setup bundles that install prerequisites like the .NET Framework making it easier for end users to run your .NET based applications. You can also use it to create installers for applications created using other runtimes. I once quickly knocked up an installer using the WiX toolset that installed Java + Eclipse + Team Explorer Everywhere along with demo projects, test data and demo scripts just to make my demos quicker to get set up back when I was looking after the Eclipse tooling in Microsoft. Burn also lets you download packages or combine them into a single downloadable .exe.

The WiX SDK includes managed and native libraries that make it easier to write code that works with Windows Installer, including custom actions in both C# and C++.  If you haven't tried it yet then what are you waiting for - give it a go now.  If there is any functionality that you want to add then get involved with the amazing community and contribute.

May the 4th be with you. Always.

Martin Woodward
Executive Director.