Hacker News new | comments | ask | show | jobs | submit login
NET Core and ASP.NET Core RC2 Released (microsoft.com)
97 points by benaadams on May 16, 2016 | hide | past | web | favorite | 50 comments

    $ docker run -it microsoft/dotnet:latest
    # dotnet new
    # dotnet restore
    # dotnet run
You can run asp.net apps from this container too as they have packaged libuv into a nuget package.

protip: make your own docker image that inherits from one where dotnet restore has been run.

That way each subsequent run in DEVELOPMENT will happen in seconds as opposed to minutes.

I've been trying to get a PR Shepparded though the MS open source process for months.



    old-speed for every deploy & first deploy under new method: 
    new-speed - second & subsequent deploys if dependencies are unchanged:
I've tried to get it into the right place from a few different angles, but at the end of the day (after some discussions with the MS team) I think they want to leave this quality-of-life improvement out in favor of making sure the base-template is "pure" (actually a perfectly acceptable choice IMO, different priority for the tool provider vs. the front-line-dev)

ANYWAYS, 9 seconds vs 4 minutes per recompile is a BIG deal. You'll thank yourself and drink way fewer cups of coffee over the course of a day.

I've been playing with docker and dotnet since they gave a demo at Build 2015... if I could figure out a way to quit my job and just do open-source docker tooling, kubernetes, mesos, and dotnetcore I would do it in a heartbeat. I'd love to create the architecture for the "bootstrap" of scalable dotnetcore microservices.

(personal opinions/preferences here:) I wouldn't really recommend rebuilding your container from scratch as a way of doing normal daily development. Why not just mount your source into the container as a volume and do rebuilds from there? You can even mount in the nuget cache so that it persists between development sessions.

I only do a from-scratch restore and compile whenever I do a "final container" build to actually push/deploy. In that case, I want it doing a full restore, plus it already has some mechanism to capture the publish output from my build container and dump it into a more minimal runtime container.

On the other hand, what you're doing "locks in" your dependencies at a single point in time when you build your intermediate base layer. That may be desired for orthogonal reasons.

a mounted volume and possibly using dotnet-watch within the actual container may be an effective choice, but at the lat time I was working with it, "dnx watch" was broken in docker files with Glenn C's last comment being something to the effect of "i'll fix this after the dust around dotnet-cli settles" (again, totally fair, I discovered the bug during RC1 and overlapping with the dotnet-cli announcement)

HOWEVER back to the "use docker inheritance" thing. Absolutely a preference with many valid options available to you.

In the one I'm proposing your "company level" shared docker file would be (roughly, this is from memory scratch so a bit more of a gist than runnable code)

filename shared_company_image

    from microsoft/aspnet
    RUN dotnet new my_temp && dotnet restore && rm my_temp

then every internal project would run

    from shared_company_image
    COPY . /app
    WORKDIR /app
    RUN ["dnu", "restore"]

You'll see that in this scenario you're actually running DNU restore twice, but because they've already been downloaded ONCE in the above image, the second image only downloads MISSING and UPDATED deps and you save massive amounts of time for every developer at setup & startup.

It's almost like doing CSS bundling and minification.

There's an added bonus for internal IT teams (I guess) that in the shared image you could also "slurp in" other tools or patches that your team feels are critical.

Anyways, I agree that it's preference based, but this one adds a bit of weight in terms of saving frontline developer hours.

In my own dev-flow "docker run" happens pretty often, so if there's a way I'm missing to cut the number of those down, I'd be interested in hearing it.

edit: I should mention I'm working under an agency scenario with dozens of websites and hundreds of developers - we try and make ourselves extremely portable from one project to the next. I've currently got around 15 that I'm actively managing and I may have to parcel out just a couple hours work at a time for a developer.

zsh: command not found: dotnet

Does not work on OS X following these instructions: https://www.microsoft.com/net/core#macosx

I greatly prefer using docker for reasons like this. Otherwise, I'm not sure what's going on. I just ran through those instructions on my Mac. After installing that package and starting a new shell, `dotnet` was working.

There's a slack room which might be able to provider further support: http://tattoocoder.com/aspnet-slack-sign-up

Dunno, restarted my Mac - still not working. Running latest version - 10.11.5

(I and more authoritative individuals can help more in Slack without cluttering up this thread too much.) If the Installer did its job, you should have /usr/local/share/dotnet on your $PATH and it should contain a `dotnet` binary among some other items.

We're working on this issue.

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

Announcing .NET Core RC2 and .NET Core SDK Preview 1 https://blogs.msdn.microsoft.com/dotnet/2016/05/16/announcin...

Announcing ASP.NET Core RC2 https://blogs.msdn.microsoft.com/webdev/2016/05/16/announcin...

Announcing Updated Web Development Tools for ASP.NET Core RC2 https://blogs.msdn.microsoft.com/visualstudio/2016/05/16/ann...


.NET Core RC2 is supported on the following platforms:

Red Hat Enterprise Linux 7.2

Centos 7.1

Debian 8.2 (8.2, 8.3, 8.4)+

Ubuntu 14.04 (16.04 support is coming at RTM)

OS X 10.11

Windows 7+ / Server 2012 R2+

Windows Nano Server TP5

I hope it works with Server 2012 non-R2....

It's supposed to be Server 2008 R2+

I love the hew http://dot.net domain. I believe Scott Hanselman said they're working on a new "get started with .NET" website for it too? Is this section it or do we know if there's still something new coming?

The branding Active Server Pages (ASP).NET reminds me of the old MS. Why not something simple like Core.NET that suggests it can be used for other things besides server-side MVC pages? Core seems to be a real alternative to Java and Go for API services.

Here's the naming announcement, and reasons for it - http://www.hanselman.com/blog/ASPNET5IsDeadIntroducingASPNET...

So you want them to have .NET Core and Core.NET?

That's just a horrible idea.

It was not a real suggestion for the brand name. I don't know what their project codes are anymore. I thought it was ASP.vNext a few months back.

Because as someone with a legacy ASP.NET application I now wonder how much effort it would take to port.

If it was Core.NET I wouldn't know without actually reading the detail, which I am not likely to do because it's a low margin project.

SEO, probably.

Good news. Hopefully it will actually RTM by the end of June.

I'm a little disappointed that http://dot.net is just a redirect to this and they're not hosting from that. :)

Is this now an integrated release with the compiler and toolchain?

In the cross-platform section, what is Linus? Do they mean Linux?


I can't stand that each of their primary link leads to a completely different website, each with its own navigation and visual design.


Documentation lags severely behind though.

Unfortunately they aren't packaging / supporting Ubuntu 16.04 (Xenial), which is the latest LTS.

I understand that supporting 14.04 makes sense for now and that supporting non-LTS releases is maybe an unjustifiable burden, but 16.04 is a LTS release and I tried installing the 14.04 packages and it didn't work as they've got unmet dependencies.

/me sad

Says Ubuntu 16.04 support is coming at RTM (June?)

Still project.json tho, they said they will remove it in future. Too bad not now.

And replace it with what? Source?

Going back to .csproj files, but improving those.

From [0]: "Question: project.json is going away? Sadface

What were the things we liked? It was small, contained NuGet information, and could be edited by hand. Damian does not want to lose any of those benefits, and that is why they are working in several steps to complete this migration. Additionally, the team is building tooling at the command line so that you don’t have to work with the project file directly. Consider a possible npm-like command like “dotnet install json.net –save” to add a NuGet package to your project. There will be first class commands like this available.

The new MSBuild will not have a complete list of every file, so that should reduce the size of the build file. It will still be XML, but the team is committed to making that experience better for all .NET projects. This will be an enhanced MSBuild that has all of the best parts of project.json"


Oh man.

It's not like I liked the idea of project.json, because it clearly has problems, like being rigid / not extensible.

But I was hoping for a migration towards something like Maven / Gradle / SBT / Leiningen. And extending MSBuild is not a solution towards that.

And it's really not about MSBuild being XML. No, this is about MSBuild being too freaking manual, in an Ant/Makefile fashion. Maven is declarative, it depends on established conventions with overridable settings and has plugins. And it takes care of everything, from dependency management, building, deployment, testing, continuous integration, metrics, etc, things for which people normally use Visual Studio or TFS or other third-party and usually incomplete, bloated and expensive solutions. And sure, providing command line tools that modify MSBuild is nice. But you know, the fact that you need a tool to modify MSBuild highlights a big problem. And no, it's not because of the XML.

The proposal, as I understand it, would be to push NuGet specific stuff to something like a nuget.json file and what (little) remains of the project.json after that into the xproj file and "back" into the MSBuild/XBuild world.

(The proposal would not add the individual file contents of the project into the xproj, however.)

This was an article highlighting the community discussions on this: https://wildermuth.com/2016/05/12/The-Future-of-project-json...

This was a discussion on the github issues list. The plan is to put things back in msbuild. The question is what will they still leave in json format - possibly a nuget.json.

I'm curious, for anyone that has experience with .NET on Linux, for new stuff that you're writing, is it better to go with this or with Mono? How about if you wanted to give it a GUI interface?

Yes, the team I work on has experience with both, and .NET Core is the way to go.

I work on RavenDB[0], a NoSQL database for .NET. We tried porting our database technology to Linux using Mono, and we encountered many serious bugs.

We have since abandoned that port and moved to .NET Core. It is successful, and we will be releasing that in the next major version of our software, RavenDB 4.0.

[0]: http://ravendb.net

> How about if you wanted to give it a GUI interface?

There is no GUI support for .net core, there is no plan to support GUI apps AFAIK, it will be mostly ASP.NET. Sure somewhere in the future WPF might be ported, but right now if you want GUI you need to use Mono and GTK+.

.net core is really asp.net core right now. Keep in mind that microsoft doesn't maintain 3rd party DB drivers or ORM adapters for Entity Framework, aside from sqlite maybe. I wasn't able to run PostGres with EF with the RC1 on .net core, while it worked when targeting mono.

For server loads .NET Core is better on Linux; if you want GUI then Mono. (Unless you do an Electron web embed for GUI or similar)

Also Mono is full framework compatible; whereas .NET Core doesn't have the same api surface area as full framework (a lot of the Win specific stuff dropped, some older apis dropped etc). So it depends on the feature set you need also.

I don't see downloads for FreeBSD. CoreCLR (.NET Core) mentions FreeBSD at github, but nothing from Microsoft's announement of RC2.

IIRC freebsd was a community port https://github.com/dotnet/coreclr/issues/793.

Or possibly netbsd https://github.com/dotnet/coreclr/pull/4504/files

Those version may require self-build or a bit more heavy lifting.

I used RC1 on Linux which was fine but now I'm going to wait for the final release (end of the year?), obviously people using PostgreSQL or MySQL with EF won't get a functional driver soon.

I'm using the Postgres EntityFrameworkCore provider from here without issue so far: https://www.myget.org/gallery/npgsql-unstable

With RC2 on Linux ? or RC1 ?

With RC2 on Linux (in Docker). In the myget link I just posted, you can see that those EF-npsql packages depend on 1.0.0-rc2-final packages.

does .net core has an FFI for (Linux / Mac)?

Assuming you mean "foreign function interface", then yes, P/Invoke is supported on .NET Core just as it is in the .NET Framework (the Windows component). We use it extensively in the core libraries to access platform functionality.

(I work on the core libraries for .NET)

oh thanks is there any documentation around that or is it better to look into the source?

Most of the documentation/tutorials you find will be perfectly relevant, but they may be Windows-centric based on .NET's history.

At a really basic level, you simply declare a "static extern" method with a "DllImport" attribute attached to it. For example, you could call "printf" from libc like so:

  public static extern void printf(string message);

  static void Main()
      printf("Hello World");

What happens if the library isn't in LD_LIBRARY_PATH could I specify a path with DllImport?

Yes, you can specify a relative/absolute path in DllImport if you'd like. Generally it is easier to get consistent behavior if you either: 1) rely on the user to install the binary somewhere and place it on the path, or 2) deploy the native binary along with your application. We generally do 1) in .NET Core, or we rely on components of Windows, for example.

That won't work with Nuance CSDK. It will install the Linux binary to /usr/local/nuance-csdk/bin, /usr/local/nuance-csdk/lib, etc..

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact