.NET

We’re excited to announce a new open source project on GitHub from the WCF team at Microsoft.  This new version of WCF targets .NET Core and has been donated to the family of .NET Foundation open source projects. Check out the WCF project for more ... [More] details. The team is actively developing WCF in this repository, and they will review any issues and pull requests you wish to contribute. The wiki describes how to build and contribute to the project. WCF targets the .NET Core framework which is designed to support multiple computer architectures and to run cross-platform. Right now the WCF project builds on Windows, but .NET Core offers the potential for it to run on OS X and Linux. The WCF team are working hard to make this a reality and to keep up to date as platform support for .NET Core grows, but if you want to help I know they would love contributions especially around improving and testing the platform support. In this guest post from Ron Cain, he explains more about the new project and how to get started with the new, open source WCF and .NET Core. -- Martin What is in the new WCF GitHub repository The WCF repository contains a subset of the full Windows Communication Foundation product available on the Windows desktop, and it supports the library profiles already available for building WCF apps for the Windows Store.  These profiles are primarily client-based, making them suited for mobile devices or on mid-tier servers to communicate with existing WCF services.  The corresponding Windows Store libraries now available in this repository are: ServiceModel.Primitives ServiceModel.Http ServiceModel.NetTcp ServiceModel.Duplex ServiceModel.Security Features known to work This project is under active development, but as we’ve learned from other projects we want WCF to become an open source project early in its lifecycle so that it has time to respond to community feedback before it is declared “done”.  This means some areas are a work in progress and you will see them changing rapidly. Our team’s goal is to achieve feature parity with the existing Windows Store profiles first and then improve as feedback comes in.  The following features are expected to work today: Bindings: BasicHttpBinding NetHttpBinding NetTcpBinding CustomBinding Transport-level binding elements: HttpTransportBindingElement TcpTransportBindingElement Message encoding binding elements: TextMessageEncodingBindingElement BinaryMessageEncodingBindingElement Channel shapes IRequestChannel Miscellaneous: ChannelFactory ClientBase FaultContract, FaultException and FaultException MessageContract DataContract serialization of simple and complex types XmlSerializer serialization of simple and complex types (XmlSerializerFormatAttribute) IClientMessageInspector Known issues Features that are available for Windows Store profiles but not fully enabled yet by WCF will throw a PlatformNotSupportedException today. Our team is actively working on these and expects to enable most of them soon.  Checkout the WCF Issues to see how our team is prioritizing this work, and feel free to comment on the issues for the features most important to you. The features not yet enabled are: Duplex communication WebSockets SSL Message level security Digest or NTLM authentication Streamed transfer mode ETW tracing support TCP transport level security Visual Studio 2015 RC and WCF Microsoft released Visual Studio 2015 RC at the Build conference in April 2015, and it supports the ability to use WCF in both Universal Windows and ASP.NET 5 applications.  The code used to build these WCF libraries used by VS 2015 RC was moved into this new GitHub repository, and the GitHub version will be the source used moving forward.  By contributing to the WCF project you will be contributing directly to the WCF capabilities available to Universal Windows and ASP.NET 5 apps. Ron Cain, Project Lead, WCF. [Less]

At BUILD some of the .NET Foundation team members were interviewed on Channel 9. Check out the interview here: .NET Open Source Initiative Jay Schmelzer, Immo Landwerth, Martin Woodward and I chatted about what the .NET Foundation is, why we need ... [More] it, and what it can do for the .NET ecosystem. Jay is the President of the .NET Foundation, Immo is on the Advisory Council and project lead for CoreFx and Martin is the Executive Director of the .NET Foundation. I’m officially the Secretary but I rather call myself Technical Evangelist :-). Meet the rest of the people behind the .NET Foundation and join the conversations in our forums. Enjoy, -Beth Massi, Technical Evangelist .NET Foundation [Less]

At BUILD some of the .NET Foundation team members were interviewed on Channel 9. Check out the interview here: .NET Open Source Initiative Jay Schmelzer, Immo Landwerth, Martin Woodward and I chatted about what the .NET Foundation is, why we need ... [More] it, and what it can do for the .NET ecosystem. Jay is the President of the .NET Foundation, Immo is on the Advisory Council and project lead for CoreFx and Martin is the Executive Director of the .NET Foundation. I’m officially the Secretary but I rather call myself Technical Evangelist :-). Meet the rest of the people behind the .NET Foundation and join the conversations in our forums. Enjoy, -Beth Massi, Technical Evangelist .NET Foundation [Less]

The .NET Foundation was set up to foster open source innovation and collaboration around .NET and so I'm very pleased to announce that we have released an initial version of a new project called LLILC (pronounced "lilac") on GitHub. This is a new ... [More] LLVM-based native code compiler for .NET Core which is being contributed to the .NET Foundation by Microsoft. LLVM is a very popular open source compiler framework which supports targeting multiple CPU types. LLILC creates a bridge into LLVM for .NET, making LLVM's broad chip support and tools available to .NET Core. We are envisioning using the LLVM infrastructure for a number of scenarios. The first tool in LLILC is a Just in Time(JIT) compiler for CoreCLR. Why a new JIT for CoreCLR? While the CoreCLR already has JIT, we saw an opportunity to provide a new code generator that has the potential to run across all the targets and platforms supported by LLVM. To enable this, as part of the LLILC project we're opening a CIL reader that operates directly against the same common JIT interface as the production JIT (RyuJIT). This new JIT will allow any C# program written for the .NET Core class libraries to run on any platform that CoreCLR can be ported to and that LLVM will target. There are several ongoing efforts to compile MSIL in the LLVM community. Why build another one? When we started thinking about the fastest way to get a LLVM based code generation working we looked around at the current open source projects (SharpLang is a very cool one and LLVMSharp is also good) as well as code Microsoft had internally. While a number of the OSS projects already targeted LLVM BitCode, no one had anything yet that was a close match for the new CoreCLR interface. Looking at the options it was quickest for us to refactor and modify a working MSIL reader to target BitCode then get an existing project to support the contracts and APIs the CoreCLR uses for JIT'ing MSIL. Using an existing MSIL reader let us get the project bootsrapped using a number of building-block components that we think the wider community will also be able to take advantage of. This rapid bootstrap for C# across multiple platforms was the idea that was the genesis of this project and the compelling reason to start a new effort. We hope LLILC will provide a useful example - and a set of reusable components - for the whole community and make it easier for lots of other projects to interoperate with the CoreCLR runtime. Why LLVM? Basically LLVM is awesome. It's already got great support across many platforms and chipsets and the community is amazingly active. The ability for LLVM to operate as both a JIT and as an AOT compiler was especially attractive. By bringing MSIL semantics to LLVM we plan to construct a number of tools that can work against CoreCLR or some sub set of its components. By putting all this out in an early state, we also hope folks will be able to produce tools and technologies that we haven't even thought of yet. Roadmap As we said, it's early days for the LLILC project but the current plan is to start with a classic JIT, then move to Install-time JIT (what we talk of as "NGen" in the .NET world). Next the LLILC project team want to look at an Ahead of Time compiler (AOT) - a build lab compiler that produces standalone native executables for many platforms, using some shared components from CoreCLR. The AOT compiler could also be used to improve startup time for important command line applications like the Roslyn Compiler. The LLIC JIT will be a functionally correct and complete JIT for the CoreCLR runtime and a great reference implementation. It's too early to say but it may not have sufficient throughput to be a first-tier JIT, but it is expected to produce high-quality code and so might make a very interesting second-tier or later JIT, or a good vehicle for prototyping codegen changes to feed back into RyuJIT. Right now the core LLILC project team have been focusing on Windows along with Linux and Mac OS X but we would be very keen on folks getting involved that wanted to widen th platform base. Current Status Today on Windows we have the MSIL reader & LLVM JIT implemented well enough to compile a significant number of methods in the JIT bring up the tests included in CoreCLR. In these tests we compile about half the methods and then fall back to RyuJIT for cases we can't handle yet. The testing experience is pretty decent for developers. The tests we run can be seen in the CoreCLR test repo. All tests run against the CoreCLR GC in conservative mode - which scans the frame for roots - rather than precise mode. We don't yet support Exception Handling. We've established builds on Linux and Mac OSX and are pulling together mscorlib, the base .NET Core library from CoreFx, and test asset dependencies to get testing off-the-ground for those platforms. The LLILC team are starting to engage with the very cool folks in the LLVM community on the project (see the LLVM blog post) but we also hope that developers and academics who are familiar with LLVM will also get involved, helping C# and the other .NET languages be supported for LLVM. The LLILC team will be working in the LLILC and LLVM repos over the next several months. They will be posting to the Forums as they make progress. As .NET Core becomes more fully supported on Linux and OS X, it is their intention to provide an LLILC implementation at a similar quality, so that you can use both projects together. It is also a great opportunity for us to get feedback, since we expect a lot of experimentation with .NET Core. While it is early days, we'd love to have you join in and help bring the potential that LLILC offers to .NET Core via LLVM a reality. We want to know about your experience, either positive or issues that you encounter. If you have LLVM experience or want to gain that experience by working on the project, please do engage directly with the LLILC project. The team will actively be monitoring for any PRs, responding to issues and wanting to discuss any changes we are proposing to LLVM to help it support .NET. LLVM and .NET are an interesting combination. .NET provides multiple-language support via a common language runtime, while LLVM supports "compilation of arbitrary programming languages" to multiple CPU targets. By combining these two worlds, LLILC provides a promising path to multiple platform support for .NET languages and by extension to the .NET developers across the globe. Exciting stuff. Martin WoodwardExecutive Director, .NET Foundation [Less]

The .NET Foundation was set up to foster open source innovation and collaboration around .NET and so I'm very pleased to announce that we have released an initial version of a new project called LLILC (pronounced "lilac") on GitHub. This is a new ... [More] LLVM-based native code compiler for .NET Core which is being contributed to the .NET Foundation by Microsoft. LLVM is a very popular open source compiler framework which supports targeting multiple CPU types. LLILC creates a bridge into LLVM for .NET, making LLVM's broad chip support and tools available to .NET Core. We are envisioning using the LLVM infrastructure for a number of scenarios. The first tool in LLILC is a Just in Time(JIT) compiler for CoreCLR. Why a new JIT for CoreCLR? While the CoreCLR already has JIT, we saw an opportunity to provide a new code generator that has the potential to run across all the targets and platforms supported by LLVM. To enable this, as part of the LLILC project we're opening a CIL reader that operates directly against the same common JIT interface as the production JIT (RyuJIT). This new JIT will allow any C# program written for the .NET Core class libraries to run on any platform that CoreCLR can be ported to and that LLVM will target. There are several ongoing efforts to compile MSIL in the LLVM community. Why build another one? When we started thinking about the fastest way to get a LLVM based code generation working we looked around at the current open source projects (SharpLang is a very cool one and LLVMSharp is also good) as well as code Microsoft had internally. While a number of the OSS projects already targeted LLVM BitCode, no one had anything yet that was a close match for the new CoreCLR interface. Looking at the options it was quickest for us to refactor and modify a working MSIL reader to target BitCode then get an existing project to support the contracts and APIs the CoreCLR uses for JIT'ing MSIL. Using an existing MSIL reader let us get the project bootsrapped using a number of building-block components that we think the wider community will also be able to take advantage of. This rapid bootstrap for C# across multiple platforms was the idea that was the genesis of this project and the compelling reason to start a new effort. We hope LLILC will provide a useful example - and a set of reusable components - for the whole community and make it easier for lots of other projects to interoperate with the CoreCLR runtime. Why LLVM? Basically LLVM is awesome. It's already got great support across many platforms and chipsets and the community is amazingly active. The ability for LLVM to operate as both a JIT and as an AOT compiler was especially attractive. By bringing MSIL semantics to LLVM we plan to construct a number of tools that can work against CoreCLR or some sub set of its components. By putting all this out in an early state, we also hope folks will be able to produce tools and technologies that we haven't even thought of yet. Roadmap As we said, it's early days for the LLILC project but the current plan is to start with a classic JIT, then move to Install-time JIT (what we talk of as "NGen" in the .NET world). Next the LLILC project team want to look at an Ahead of Time compiler (AOT) - a build lab compiler that produces standalone native executables for many platforms, using some shared components from CoreCLR. The AOT compiler could also be used to improve startup time for important command line applications like the Roslyn Compiler. The LLIC JIT will be a functionally correct and complete JIT for the CoreCLR runtime and a great reference implementation. It's too early to say but it may not have sufficient throughput to be a first-tier JIT, but it is expected to produce high-quality code and so might make a very interesting second-tier or later JIT, or a good vehicle for prototyping codegen changes to feed back into RyuJIT. Right now the core LLILC project team have been focusing on Windows along with Linux and Mac OS X but we would be very keen on folks getting involved that wanted to widen th platform base. Current Status Today on Windows we have the MSIL reader & LLVM JIT implemented well enough to compile a significant number of methods in the JIT bring up the tests included in CoreCLR. In these tests we compile about half the methods and then fall back to RyuJIT for cases we can't handle yet. The testing experience is pretty decent for developers. The tests we run can be seen in the CoreCLR test repo. All tests run against the CoreCLR GC in conservative mode - which scans the frame for roots - rather than precise mode. We don't yet support Exception Handling. We've established builds on Linux and Mac OSX and are pulling together mscorlib, the base .NET Core library from CoreFx, and test asset dependencies to get testing off-the-ground for those platforms. The LLILC team are starting to engage with the very cool folks in the LLVM community on the project (see the LLVM blog post) but we also hope that developers and academics who are familiar with LLVM will also get involved, helping C# and the other .NET languages be supported for LLVM. The LLILC team will be working in the LLILC and LLVM repos over the next several months. They will be posting to the Forums as they make progress. As .NET Core becomes more fully supported on Linux and OS X, it is their intention to provide an LLILC implementation at a similar quality, so that you can use both projects together. It is also a great opportunity for us to get feedback, since we expect a lot of experimentation with .NET Core. While it is early days, we'd love to have you join in and help bring the potential that LLILC offers to .NET Core via LLVM a reality. We want to know about your experience, either positive or issues that you encounter. If you have LLVM experience or want to gain that experience by working on the project, please do engage directly with the LLILC project. The team will actively be monitoring for any PRs, responding to issues and wanting to discuss any changes we are proposing to LLVM to help it support .NET. LLVM and .NET are an interesting combination. .NET provides multiple-language support via a common language runtime, while LLVM supports "compilation of arbitrary programming languages" to multiple CPU targets. By combining these two worlds, LLILC provides a promising path to multiple platform support for .NET languages and by extension to the .NET developers across the globe. Exciting stuff. Martin WoodwardExecutive Director, .NET Foundation [Less]

Time flies. Exactly one year ago today, Microsoft Corp. announced the creation of an independent .NET Foundation to foster open development and collaboration around the Microsoft .NET development framework. At the end of February we announced our ... [More] Advisory Council, a group of nine leaders who are bringing their passion and experience to help steward the future of .NET as an open source community. Today, I am pleased to announce that the .NET Foundation Board appointed a full time Executive Director to the .NET Foundation: Martin Woodward. In his new role, Martin will remain an employee of Microsoft, where he has been involved in the open source world for some time. He came from the Microsoft MVP community where he worked on Eclipse, Java, Unix and Mac tooling for Team Foundation Server, bringing this functionality to Microsoft’s Developer Division. He helped drive the introduction of Git to Microsoft and ensured it was done in collaboration with the open source community. Behind the scenes, Martin lent his expertise to several Microsoft open source initiatives that you’re familiar with, including some of the projects brought into the .NET Foundation. Additionally, he has been part of a cross-company effort to improve the internal processes and tooling at Microsoft, enabling the company to do more in the open source space. Over the past year, we have been honored by the level of community involvement in the .NET Foundation. Community collaboration levels are frankly staggering. While Microsoft has utilized its full engineering teams, including the Core CLR, Core Framework, ASP.NET, F# and Roslyn Compiler teams, working in the open on GitHub, more than 60 percent of pull requests approved for those repositories are coming from outside of Microsoft. The core project teams remain heavily focused on being responsive to those pull requests, often responding in a matter of minutes. More important, however, is the passion of the volunteers in the .NET community that is driving the success of those projects. Until now, the .NET Foundation Board of Directors has relied on a team effort to manage the organization. But with the scale of activity that we have seen in the last year, it is time to bring someone to the team who can be fully dedicated to ensuring the rapid growth and continued innovation of the .NET open source ecosystem. I’m thrilled to have Martin onboard to do just that. Please join me in welcoming our new executive director, Martin Woodward, to the .NET Foundation team and community!   Jay SchmelzerPresident, .NET FoundationDirector Program Management, Microsoft [Less]

Time flies. Exactly one year ago today, Microsoft Corp. announced the creation of an independent .NET Foundation to foster open development and collaboration around the Microsoft .NET development framework. At the end of February we announced our ... [More] Advisory Council, a group of nine leaders who are bringing their passion and experience to help steward the future of .NET as an open source community. Today, I am pleased to announce that the .NET Foundation Board appointed a full time Executive Director to the .NET Foundation: Martin Woodward. In his new role, Martin will remain an employee of Microsoft, where he has been involved in the open source world for some time. He came from the Microsoft MVP community where he worked on Eclipse, Java, Unix and Mac tooling for Team Foundation Server, bringing this functionality to Microsoft’s Developer Division. He helped drive the introduction of Git to Microsoft and ensured it was done in collaboration with the open source community. Behind the scenes, Martin lent his expertise to several Microsoft open source initiatives that you’re familiar with, including some of the projects brought into the .NET Foundation. Additionally, he has been part of a cross-company effort to improve the internal processes and tooling at Microsoft, enabling the company to do more in the open source space. Over the past year, we have been honored by the level of community involvement in the .NET Foundation. Community collaboration levels are frankly staggering. While Microsoft has utilized its full engineering teams, including the Core CLR, Core Framework, ASP.NET, F# and Roslyn Compiler teams, working in the open on GitHub, more than 60 percent of pull requests approved for those repositories are coming from outside of Microsoft. The core project teams remain heavily focused on being responsive to those pull requests, often responding in a matter of minutes. More important, however, is the passion of the volunteers in the .NET community that is driving the success of those projects. Until now, the .NET Foundation Board of Directors has relied on a team effort to manage the organization. But with the scale of activity that we have seen in the last year, it is time to bring someone to the team who can be fully dedicated to ensuring the rapid growth and continued innovation of the .NET open source ecosystem. I’m thrilled to have Martin onboard to do just that. Please join me in welcoming our new executive director, Martin Woodward, to the .NET Foundation team and community!   Jay SchmelzerPresident, .NET FoundationDirector Program Management, Microsoft [Less]

The .NET team at Microsoft announced today that they are contributing another new open source project to the .NET Foundation -- the Microsoft Build Engine (MSBuild), available today on GitHub. MSBuild is a platform for building applications, and the ... [More] default build engine for Visual Studio and the .NET community on the Windows platform. It enables developers to orchestrate and build products in environments where Visual Studio isn’t installed. Through open sourcing MSBuild, the team intends to make it a top choice for .NET developers on the Linux and Mac platforms. The team reports that community feedback led them to open source MSBuild, and through the .NET Foundation, they hope to continue this collaboration. Get involved in MSBuild, and keep the comments flowing on the .NET Foundation Forums. Read more about the open sourcing of MSBuild on the .NET team blog.   Robin Ginn Director, Technical Evangelism, Microsoft Open Technologies [Less]

The .NET team at Microsoft announced today that they are contributing another new open source project to the .NET Foundation -- the Microsoft Build Engine (MSBuild), available today on GitHub. MSBuild is a platform for building applications, and the ... [More] default build engine for Visual Studio and the .NET community on the Windows platform. It enables developers to orchestrate and build products in environments where Visual Studio isn’t installed. Through open sourcing MSBuild, the team intends to make it a top choice for .NET developers on the Linux and Mac platforms. The team reports that community feedback led them to open source MSBuild, and through the .NET Foundation, they hope to continue this collaboration. Get involved in MSBuild, and keep the comments flowing on the .NET Foundation Forums. Read more about the open sourcing of MSBuild on the .NET team blog.   Robin Ginn Director, Technical Evangelism, Microsoft Open Technologies [Less]

It’s official – we’re happy to welcome nine community leaders to the .NET Foundation Advisory Council – leaders who will bring their experience and passion to help steward open source .NET projects and continue on a path of open and transparent ... [More] governance for the foundation. The .NET Foundation Board has been selecting these individuals from an impressive roster, and we had to make some difficult choices to come up with the initial list. A few months down the road, we expect the Advisory Council to come up with a more participatory process to ensure that the next Advisory Council is selected by the .NET community at large. Please join me in welcoming the newly minted Advisory Council members: Shaun Walker – Software Architect. Ex-Project leader for DotNetNuke open source product and ecosystem. Immo Landwerth – Senior Engineer from Microsoft .NET Framework team helping lead open source initiatives. JB Evain – Founder and Project Leader at SyntaxTree open source projects. Senior Software engineer at Microsoft. Daniel Roth – Senior Engineer from Microsoft ASP.NET Framework team helping lead open source initiatives. Bill Wagner – Humanitarian Toolbox contributor, author and speaker for .NET technologies. C# MVP, and Regional Director for .NET Framework. Phil Haack– Engineering Manager at GitHub with significant open source contributions and experience. Mirco 'meebey' Bauer – Co-founder of Debian Mono Group, GNOME foundation member. CTO at GSD Software Design GmbH. Marcus Wendt - Project Leader on Composite C1 OSS project and active speaker on .NET technologies. Dominick Baier – Project Leader on ThinkTecture projects in .NET Foundation. Many of you may know these individuals already, by collaborating through code or conferences, on a number of .NET-related projects. Each of them brings a record of independence, impartiality and candor, which will help guide key decisions affecting the direction of the foundation. We’re proud to have them represent the community and the foundation through their continued open source evangelism. Our heartfelt thanks go to all those who stepped up and volunteered to help, especially to those who have not been selected just yet: just like everyone in the .NET community, we are looking forward to your continued participation and assistance as we continue our journey. Advisory Council members look forward to any suggestion, criticism and assistance, as does the foundation board. Please continue to send us feedback as we work together for a stronger .NET open source community.   Gianugo Rabellino Board Member, .NET Foundation Senior Director of Open Source Communities at Microsoft Open Technologies, Inc.   [Less]