runfaster2000

Yes. I work on the CLR/.NET Team at Microsoft. Sorry for not disclosing that more clearly. Oops.

Yes, Miguel and I are friends and work together frequently. Usually, he's badgering me, asking me when my team is going to deliver something we promised. We are now starting to adopt more of the Mono/Xamarin tech (in this case, their assembly linker), so the relationship is reversing. Here's a video of us together (where he makes fun of me): https://channel9.msdn.com/Events/dotnetConf/2015/The-NET-Voy...

Haven't started looking at the GNOME ecosystem yet. I'll leave that to Miguel to make suggestions on.

Great point. I agree with you. We know that this is a weakness. We had a planning meeting yesterday where we discussed this very scenario and want to shore up this space significantly.

Your point on roadmap is also well-taken. We're on the cusp of communicating our plans for the next version, and will be looking for more feedback like this.

Happy to take your issue offline if you'd like. It may help inform our future diagnostic plans. I'm rlander@ms.

You are correct that Linux is new to many folks on the .NET team. For another set of folks, it's a return to an old friend. Some team members have switched to a favourite Linux distro as their primary computing environment, even at home. About half of the team is now using MBP as their main computing device.

I have been complaining recently because I am constantly fighting space on my 512GB MBP due to the Linux and Windows VMs and all the Docker usage. My colleagues were smarter and got the 1TB versions to avoid this problem. I guess mine needs to be garbage collected.

That must seem quaint for some readers, but is a strong suggestion of a big shift from 5 years ago and will only continue for this team. Totally agree that you need to live and breath Linux if you want to have a compelling and competitive dev platform for it.

For the code-base itself, the move to nix is not at all new. CLR supported BSD Unix as early as 2000. The source was published for the BSD version through 2005. Silverlight brought new life into the codebase with Mac support (the earlier choice to target BSD was a prescient one). And then, the source did indeed lay unloved for multiple years and was revived again a few years ago. We started where we had previously left off and moved forward, a lot.

Many of the engineers have worked on at least two of our nix projects. A couple have worked on all 3. They are very happy to be working on it again and under very different circumstances.

Main point is that *nix support is not new for the codebase and for a signficant number of folks on the team. Being competitive on Linux is indeed the new thing. No question there! We're very happy to play in that space, in terms of runtimes, libraries, languages, tools and support.

Last, we have moved our web properties (that the team owns) to .NET Core on Linux, some time ago. With Azure supporting containers and orchestration, we will be moving those same web properties to Linux containers as the next step. We also use a ton of Linux in our test infrastructure. We are actively using Linux, happily.

We're working on this issue.

See open issues: https://github.com/dotnet/cli/blob/rel/1.0.0/Documentation/k...

Yes! Check out: https://get.asp.net/OtherDownloads

There are these docker images. Do they work for your needs?

https://hub.docker.com/r/microsoft/aspnet/

The F# team is working on getting F# working on .NET Core. It's an important goal for the team.

You can follow their progress: https://github.com/Microsoft/visualfsharp/pulls?utf8=&q=is%3...

WCF client is already open. That's a great place to engage.

https://github.com/dotnet/wcf

MVC is the default for ASP.NET 5, for both apps and services. It runs on both .NET Core and .NET Framework. Same with SignalR.

WebForms remains supported and new features go into it each release. It is supported on the .NET Framework.

Disclosure: .NET Core team member

We are making .NET Core OS agnostic as a general principle. The 260 char limit seems like an unwelcome Windows behavior to include in the Linux and OS X implementation. With that removed, it makes sense to also remove it from Windows. That was our thinking.

We do hear about this limitations on Windows somewhat frequently in the context of .NET. This comes from internal Microsoft teams about as much as anyone else. We were glad to remove this limitation for .NET Core.

Disclosure: .NET Team member

There are two major scenarios that we are targeting on top of Core:

- ASP.NET 5 web apps and services - see: https://github.com/aspnet/home - Native executables - see: https://github.com/dotnet/corert/blob/master/Documentation/i...

What do you think?

Disclosure: .NET Core team member

Not a competitor. We work closely with the Mono team, specifically Miguel. We are releasing lots of source for them with each .NET Framework release. The Mono team is adopting large quantities of that source to improve Mono. It's a collaboration.

Certainly, there are now two .NET choices on Linux. If you ask Miguel, I suspect he'd recommend .NET Core if you are building a server app.

Disclosure: .NET Core team member

MVC is also RC.

See: https://github.com/aspnet/Home/releases/tag/v1.0.0-rc1

It's also good to point out that .NET Core (effectively a subset of the .NET Framework) and Roslyn (C# compiler) are open source on GitHub.

See: https://github.com/dotnet and http://dotnet.github.io

I'm a .NET team member at Microsoft.

This is another similar answer: http://blogs.msdn.com/b/dotnet/archive/2012/11/13/the-net-fr....

My post had more C# bias than appropriate. .NET Native also supports VB. See: https://msdn.microsoft.com/en-us/dotnetnative. I don't think it yet supports F#, but that's likely on the roadmap.

Reflection is supported on .NET Native Native. See: http://blogs.msdn.com/b/dotnet/archive/2014/05/20/net-native.... Reflection.Emit is not.

There are effectively three codegen strategies: JIT, pre-jit and static compilation/AOT. They all have their own characteristics and reasons why they are a good choice. I can see that you have depth here, but I'm going to provide an answer with more context, for a broader audience.

- JIT has the most flexibility since the code is generated (you guessed it) just in time. This means that the code generated can be specialized in terms of hardware or use a layered approach to codegen (prefer throughput and then CQ for hotter methods). It is also the best for versioning, since the code is always generated in terms of the actual dependencies, as opposed to the ones you happened to compile with.

- Pre-JIT can be very high performance since you don't have to pay for JIT and other related costs up-front, as is the case with NGEN. Depending on the code generated, it may be subject to the fragile base class problem: https://en.wikipedia.org/wiki/Fragile_base_class, as is the case with NGEN. MDIL is also subject to it, but we made the cost to regenerate images very low. There can be a problem of when to generate the images and where to store them. These two issues have been a constant design challenge for us (mostly the former). At least on the surface, pre-jit is much cheaper than AOT, particularly since you can rely on a JIT for the code that you can generate deterministically (at least into a single bit of code) ahead of time (think generics). ReadyToRun (https://github.com/dotnet/coreclr/issues/227) is a project we're working that makes NGEN/CrossGen images more resilient to the fragile base class problem.

- AOT can be very high performance, for the same reasons. We've found that it is even higher performance since you can skip a number of architecural requirements for a dynamic runtime environment. If you couple this with app-local framework and runtime distribution, as is the case with .NET Native, then you also skip the fragile base class problem. Building a high-performance industrial quality AOT system with a fabulous developer experience is a fantastic computer science challenge. We've certainly found it to be that. We're several years into AOT investments and we're finding that it is paying off.

You might take a look at the C# 7 design notes: https://github.com/dotnet/roslyn/issues/created_by/MadsTorge...

It happens in both places. You can (and should) test with .NET Native enabled on your local machine. You still upload IL to the Windows Store, and the final native compilation is done there. The Windows Store uses the same .NET Native SDK as ships with Visual Studio.

You can see a few mentions to .NET Native and UWP here: http://blogs.msdn.com/b/dotnet/archive/2015/07/20/announcing.... .NET Native will RTM on 7/29 as the basis of the .NET tools for Windows 10 UWP apps

.NET team member here ... We like to think of .NET Native as a native tool-chain for .NET Core. I say "a" because the Xamarin and Unity (IL2CPP) tool-chains are equally applicable (and we've talked to them about it).

The core framework libraries (CoreFX) - https://github.com/dotnet/corefx - are used for all .NET Core scenarios, including .NET Native (UWP). This means that your code does the same thing in all of these different environments, since it's using the same underlying framework libraries. Separately, the Mono project is taking a lot of the same code, which means that the base framework for Xamarin apps are becoming more compatible with CoreFX, too. Yeahh! We hope to make this more formal in the future. We talk to @migueldeicaza about this frequently.

Today, .NET Native and .NET Core use two different runtimes, MRT and CoreCLR, respectively. MRT expands to the extremely creative "managed runtime". Colloquially, we call it "Mr. T". Earlier in the project, everyone working on .NET Native had posters of Mr. T (yes, that one) on our doors. Mohawks were entirely optional on the parts of team members.

MRT was built for static ahead-of-time (AOT) compilation. It is the child of the Redhawk project (http://www.zdnet.com/article/microsoft-codename-redhawk-live...). Redhawk was built to be a .NET-esque (using C# + extensions) systems programming environment. MRT was built to have many of the same benefits, but be compatible with .NET (not just "esque") and support nothing less, nothing more than C#.

CoreCLR is a child of the .NET Framework CLR. CLR (and by extention, CoreCLR) was built for dynamic execution, with a JIT. It supports AOT compilation in the pre-jit/NGEN sense.

The GC is the primary shared component between the two (MRT, CLR/CoreCLR) runtimes.

We plan to bring static compilation to more scenarios, however, we strongly believe that both JIT and (real) AOT are legitimate and compelling technologies and experiences and both are on our long-term roadmap. We'd like to leave the compilation choice/appraoch up to our users/customers. Novel idea, eh?

We have a lot of fun runtime and compiler tech on the team. It's a fun place to work. Much of it is now open source, meaning that we get to work on this fun tech in the open. This is our latest compiler announcement: http://blogs.msdn.com/b/dotnet/archive/2015/07/20/announcing....

Here's another one: https://github.com/Microsoft/dotnet/blob/master/dotnet-devel...

You can run .NET Core on OS X[1] (and Linux, FreeBSD and Windows). There are plenty of rough edges still, but we're adding more functionality and making it more capable each day. Soon enough, all the .NET Core ports will be just as capable as the Windows version.

ASP.NET 5 still runs Mono by default on OS X, but you can switch to .NET Core with the DNVM tool [2].

Note the blog post from yesterday by the F# team on F# 4. [3]

[1] https://github.com/dotnet/coreclr#get-net-core

[2] https://github.com/aspnet/home#os-x

[3] http://blogs.msdn.com/b/dotnet/archive/2015/04/29/rounding-o...

Makes sense. There is a latency of when .NET Framework versions are released and when they show up on Windows Update. Also, customer do not have to install them even when they do show up. Also, some versions don't show up on Windows Update for various reasons. That's why the install step exists.

.NET Native will expand to other app types. See the last paragraph of this section: http://blogs.msdn.com/b/dotnet/archive/2015/04/29/net-announ... .

Strangely enough, the reason that this install step exists is because the .NET Framework _is_ built-in to Windows. For example, .NET 3.5 was built-in to Windows 7. If your app needed .NET 4, then it needed to formally install it on the system. If we didn't make that an option, then .NET 4 apps would not run on Windows 7, which would be bad.

.NET Core is _not_ built-in to the OS, so apps can carry it within their package, meaning that there is never a need to add another step to the installation. This is a major goal of .NET Core.

Great. I'm the one (@richlander) who has been spending the most time on docs, including publishing all of the "Book of the Runtime" docs[1]. It's a whole lot easier for others to "follow along at home" if you show them how.

We (and me in particular) are going to continue investing in docs for this reason. Feel free to file an issue if there is anything else you want written/explained. We have operators waiting.

BTW: I highly recommend the "Introduction to the CLR" [2] doc. It has a great fundamental view of the product that I suspect many .NET developers would appreciate and will likely learn something from.

[1] https://github.com/dotnet/coreclr/blob/master/Documentation/...

[2] https://github.com/dotnet/coreclr/blob/master/Documentation/...

.NET Core team member here.

I'm glad that you were able to make it all work with the instructions[1] we provided. There are two major pieces that we're still working on, which you call out:

- Compiling managed source on OS X and Linux with Roslyn.

- Running DNU (NuGet) on .NET Core to restore packages.

Most everything else functionaly works. Once those are solved (and we are close to it), the experience will be great. In just a few commands, you'll be able to acquire .NET Core, restore packages and run your app, independent of which OS you are on.

For .NET developers, it is indeed historic. Community and corporate developers alike are quite excited and see a lot of new opportunities going forward. You might have noticed that the community is leading the OS X and FreeBSD .NET ports, with support from Microsoft. We added official FreeBSD CI[2] only a week ago, upon the request of the community.

[1] https://github.com/dotnet/coreclr/blob/master/Documentation/...

[2] https://github.com/dotnet/coreclr#build-status

edit: formatting

Nice choice! There is a _lot_ of investment in .NET at Microsoft. The move to open source and the community reaction to it has only made it more exciting and compelling for the company.

I get and appreciate the sentiment on "if Microsoft abandoned it tomorrow". Just clarifying that this risk is _very_ far from reality.

It's also really interesting to look at how Microsoft is approaching C#/Roslyn. One aspect of that is the C# 7 effort, which has an ambitious scope and has a great deal of open/public interaction. Check it out: https://github.com/dotnet/roslyn/issues/2136

Working with the "FreeBSD Port Team" was great. The team really lived up to the aspirational name. It would be fair to say that there were people from the port team on the repo and the gitter room (https://gitter.im/dotnet/coreclr) more hours of the day than not. Nice!

We gave @kangaroo a "port" glass to thank him for his OS X "port" and did it in Portland at the already mentioned .NET Fringe conference. We also gave him two bottles of port, one of which was "Washington Port" from Whidbey island (Whidbey being the codename for .NET 2.0). The engraving was done in the Microsoft "Garage".

We're looking forward to giving out a nice set of engraved FreeBSD port glasses once FreeBSD catches up to the OS X and Linux.

Yes. That is the rationale, one more component for an open and cross-plat .NET ecosystem. Also, @migueldeicaza asked us for it, so Xamarin/Mono could use it. It was these two things, together.