Published by Marco on 19. May 2016 16:14:52

The article ".NET Core, a call to action" by Mark Rendle
 exhorts everyone to "go go

I say, "pump the brakes."

[RC => Beta => Alpha]

Mark says, "The next wave of work must be undertaken by the wider .NET
community, both inside and outside Microsoft."

No. The next wave of work must be undertaken by the team building the product.
This product is not even Beta yet. They have called the last two releases RC,
but they aren't: the API is still changing quite dramatically. For example, the
article "Announcing .NET Core RC2 and .NET Core SDK Preview 1"

[1] lists all sorts of changes and the "diff of APIs between RC1 and RC2"

is gigantic -- the original article states that "[w]e added over a 1000 new APIs
in .NET Core RC2".


That is a huge API-surface change between release candidates. That's why I think
these designations are largely incorrect. Maybe they just mean, "hey, if y'all
can actually work with this puny footprint, then we'll call it a final release.
If not, we'll just add a bunch more stuff until y'all can compile again." Then,
yeah, I guess each release is a "candidate".

But then they should just release 1.0 because this whole "RC" business is
confusing. What they're really releasing are "alpha" builds. The quality is
high, maybe even production-quality, but they're still massive changes vis-a-vis
previous builds.

[An Example: Project files]

That doesn't sound like "RC" to me. As an example, look at the project-file
format, project.json.

Mark also noted that there are "no project.json files in the repository" for the
OData project that comes from Microsoft. That's not too surprising, considering
the team behind .NET Core just backed off of the project.json format
considerably, as concisely documented in "The Future of project.json in ASP.NET
Core" by Shawn Wildermuth
The executive summary is that they've decided "to phase out project.json in
deference to MSBuild". Anyone who's based any of their projects on the
already-available-in-VS-2015 project templates that use that format will have to
convert them to whatever the final format is.

Wildermuth also wrote that "Microsoft has decided after the RTM of the ASP.NET
Core framework to phase out project.json and use MSBuild for build data.
(Emphasis added.)" I was confused (again) but am pretty sure that he's wrong
about RTM because, just a couple of days later, MS published an article
"Announcing ASP.NET Core RC2"

-- and I'm pretty sure that RCs come before RTM.

[Our Experience]

At "Encodo" , we took a shot at porting the base assembly of
Quino to .NET Core. It has only dependencies on framework-provided assemblies in
the GAC, so that eliminated any issues with third-party support, but it does
provide helper methods for AppDomains and Reflection, which made a port to .NET
Core nontrivial.

Here's a few things we learned that made the port take much longer than we

  * Multi-target project.json works with the command-line tools. Create the
    project file and compile with dotnet.
  * Multi-target project.json do not work in Visual Studio; you have to choose a
    single target. Otherwise, the same project that just built on the command
    line barely loads.
  * Also, Visual Studio ignores any #IFDEFs you use for platform-specific code.
    So, even if you've gotten everything compiling on the command-line, be
    prepared to do it all over again differently if you actually want it to work
    in VS2015.
  * If you do have to change code per-platform (e.g. for framework-only), then
    you have to put that code in its own assembly if you want to use Visual
  * If you go to all the trouble to change your API surface to accommodate .NET
    Core, then you might have done the work for nothing: many of the missing
    APIs that we had to work around in porting Encodo.Core are suddenly back in
    RC2. That means that if we'd waited, we'd have saved a lot of time and ended
    up in the same place.
  * There are several versions and RCs available, but only the beta channel was
    usable for us (e.g. the RC3 versions didn't work at all when we tried them).
  * In the end, we didn't have to make a lot of changes to get Encodo.Core
    compiling under .NET Core.
  * We learned a lot and know that we won't have too much trouble porting at
    least some assemblies, but the tools and libraries are still not working
    together in a helpful way -- and that ends up eating a lot of time and

With so much in flux -- APIs and project format -- we're not ready to invest
more time and money in helping MS figure out what the .NET Core target needs.
We're going to sit it out until there's an actual RTM. Even at that point, if we
make a move, we'll try a small slice of Quino again and see how long it takes.
If it's still painful, then we'll wait until the first service pack (as is our
usual policy with development tools and libraries).


I understand Mark's argument that "the nature of a package-based ecosystem such
as NuGet can mean that Project Z can't be updated until Project Y releases .NET
Core packages, and Project Y may be waiting on Project X, and so on". But I just
don't, as he says, "trust that what we have now in RC2 is going to remain stable
in API terms", so I wouldn't recommend "that OSS project maintainers" do so,
either. It's just not ready yet.

If you jump on the .NET Core train now, be prepared to shovel coal. Oh, and you
might just have to walk to the next station, too. At noon. Carrying your
overseas trunk on your back. Once you get there, though, you might be just in
time for the 1.0.1 or 1.0.2 express arriving at the station, where you can get
on, you might not even have to buy a new ticket -- and you can get there at the
same time as everyone else.


[1] The Mark Renton article states boldly that "Yesterday we finally got our
    hands on the first Release Candidate of .NET Core [...]" but I don't know
    what he's talking about. The project just released RC2 and there are even
    RC3 packages available in the channel already -- but these are totally
    useless and didn't work at all in our projects.