Microsoft is on a roll - they've got command line installable packages of the .NET execution environment for all 3 platforms - OSX, Linux and Windows! (http://get.asp.net/OtherDownloads)
Can't wait to figure out what you can do with this on Linux. Anyone knows? Maybe not desktop apps but Web Apps should be doable at this stage?
I've been building in MVC3/4 for the last few years so have quite a bit of experience with how MS has been evolving in this space. From "BundleTransformers" through "Web Essentials" and now suddely all the way to GULP
I started building a weekend and evenings project in EF7+MVC6 at Beta6 and have suffered through breaking changes in beta7 & 8 but each stage of the way I've enjoyed myself.
Some of the things that I have recently struggled with is getting the project working on linux VMs and docker.
While I can get boilerplate projects working, this "bigger" project struggles to compile on docker.
Part of it may be my own fault since I've split the solution into multiple projects ("WEB", "API", "MODEL") where MVC6 seems to have a paradigm of keeping everything in the same project, but it does seem to work OK on a windows 10 host (I keep wanting to test it on azure but that's another story)
There isn't any clear path as of yet from "building something that runs locally in VS" to getting it hosted in a "massively scalable cloud of containers"
I'm exploring docker and kubernetes at the moment - but progress is slow :)
Additionally - in terms of development - I'd like to see some more scaffolding, like I see with (for example) strongloop/loopback in node.js I'm finding that my API breaks down in .NET when I try and use an EF entity around since we get into circular JSON references.
Anyways, I'm starting to get off on a tangent. I really do like what I see in .NET5 though feel there are some pains in places. Specifically around containerizing & rapid application development.
I'm aiming to have a demo of ASPNET5 on Kubernetes within two weeks. :) I'm having to figure out a lot along the way. I wish the aspnet team would take direct ownership of their docker image. There's no reason that the aspnet team can't be putting out new docker images every night with the latest DNX and MVC bits pre-loaded ready to go.
Kinda. I think it'd be better if the aspnet team's CI system would upload new dnx packages to myget... and then also build a new docker image with the latest dnx bits baked in.
That way I can try the latest and greatest of rc2 without having to rebuild my container every time new packages go up on myget.
It's a pretty minor ask... I'm probably one of a very small number of people that are stubborn enough to be on the bleeding edge (using rc2 when rc1 is the latest release, etc)
Thanks! That's actually awesome and covers both use cases I care about personally. I am going to download it later today and try out - been preparing myself by reading C# code over past few weeks, so this is perfect timing.
I am interested in finding out how it compares right now to Java for building web apps and services - in terms of DB access, various ORM stuff etc.
I think it's awesome. I've been a Mac/Linux convert for over a decade now but I really really like C# and ASP.NET. The Visual Studio Code editor is awesome, the command utilities work great so far.
Where is an example of this. I write Node and Django on Linode since they provide great service, have a lot of flexibility and don't have extravagant and hard to predict prices for a VPS. It seems I have no options of running a C# website or project from my Ubuntu 14.04 without installing Mono. Is this accurate or are you saying somehow I can run an ASP.NET website from my Linode?
And assuming I can, is anybody else doing this? In the past it seems like production Mono makes no sense when Python and Node just work without additional libraries to make it work.
I haven't used VS Code in a long time (since the very early versions when it cam) and I remember that it didn't meet my needs.
What I like about VS is its project templates, dynamic auto-complete, integrated terminal, amazing visual git (and diff) integration...
Are these available in VS Code ?
We're interested in running .NET web servers (currently NancyFX-based) in Docker containers on CoreOS. I think that may be covered by the ASP.NET 5 scenario.
Has the ASP.NET request processing pipeline changed significantly in v5? Last time I checked, our fork of Nancy only really cares about _Init, _BeginRequest, and the unhandled exception handler.
ASP.NET 5 is essentially based on OWIN as a pipeline which uses a pipeline of async Func calls (that can be wrapped up into "middleware" components). NancyFX, actually implements an OWIN middleware which I think would be easy to tie into ASP.NET 5, but I haven't tried yet.
It's a bad fit for most of the things I need to do. Especially for systems that have a lot of background processing, but need a web front-end (because enterprise, and dashboards!), it is a drag to have everything go down because IIS has decided to recycle your app pool due to 20 minutes of front-end inactivity. Yes, you can change the settings to disable that, or architect things differently to separate the UI from the background service, but it is extra complexity that is a pain. Building a Windows service that has a light-weight webserver built into it is much easier.
IIS also has too many knobs that can get fiddled and frig things up. Before we switched, I'd always be on support calls to help a customer fix one of our products after their sysadmin tweaked something in a way to break us, or installed some other piece of software that stomped on us.
IIS also has a very conservative set of defaults if you naively install it. Seriously, I've seen a lot of instances where customers install IIS, and CSS doesn't get served - you have to install an additional Static Content module. People don't read instructions, or bother to run required setup scripts. So you have to do a bunch of additional work with less-than-friendly installer authoring programs to make sure that features that any self-respecting web server ought to have out of the box are available.
Hey, been using ASP.NET 5 on Linux since beta 5 and really love it so far! Keep up the great work. I hope to contribute a bit in the future when I have some more free time.
God forbid! PowersHell can really drive you to insanity with half-swallowed chained exceptions (pointing to the initial caller) and its return-everything-from-procedures behaviour.
The big issue, is SQL Server the only production ready database supported? SQL Server is not a viable option in the open source world. There is an Alpha version of the PostgreSQL npgsql driver, not sure how solid it is.
Moreover, is CoreCLR production ready on Linux? I haven't read 3rd party critical reviews or comparisons against JVM/Go/node.js on Linux. I don't have fond memories of putting faith in Mono/XSP.
Different eras, different revenue sources, different incentives.
In the days of ASP.NET v1, MS made money from server licences to run IIS and ASP.
These days they want to make money from Azure, and they make money regardless of if it's hosting .Net, PHP, Java or node.js; or on linux or windows. The .Net open stack becomes a loss leader. Ironically, it's also going to greatly improve .Net on AWS.
Yeah, I was thinking this too... that's when I was a .NET developer. Then the alt.net train started and (ironically?) lead me to discover the world outside the .NET and windows ecosystem. If things were more cross-platform back at the time I probably would have stuck around.
Also, the powershell package manager is quite nice. So far it is basically chocolatey for me but if there are some more it can handle in the future... https://github.com/OneGet/oneget/issues/77
Yeah, unfortunately that nice clean syntax requires a fairly recent version of PowerShell so the code we actually use has to be a bit verbose for compat :)
That got a lot boilerplate on it on purpose, to make you have the right ExecutionPolicy(Powershell won't let you run random scripts, unless you override it), etc.
This would be a lot more exciting if it actually worked with IIS but it looks like they rushed this out, calling it a "release candidate" in order to be able to say it was out in time for the Connect conference without actually hitting the kind of bar one expects from a release candidate.
Their github issue pages are full of unresolved issues around problems with ASP.NET 5 and IIS [0][1][2], and the official docs on publishing ASP.NET 5 to IIS have a significant and incomplete list of "common errors" people are encountering [3].
Personally, I'm seeing responses from Kestrel when hitting ASP.NET 5 hosted pages under IIS, but they are zero-byte error 404 responses which don't help much. It's all great in Visual Studio but it's a big zero when trying to actually use it for real. This is not a release candidate. At best it's a 9th beta.
Yeah, I've got a minor issue with the Configuration classes and they were already talking about RC2 a little while ago [1]. I don't think we can fault them too much for this - we've all been on those kinds of schedules.
Following your link led me to discover your https://github.com/voltagex/minecraft-rebridge, which looks very cool. Would it be difficult to configure the embedded http server to support persistent TCP connections for lower latency between subsequent requests? (I think NanoHTTPD supports persistent connections but I've never used it so don't know what's involved)
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.
I got confused when trying to install .NET Core, so sorry if this is a bad question. It seemed like .NET Core depended on Mono. Does it actually? I can't remember what exactly seemed like it depended on Mono. Perhaps Nuget? My memory is fuzzy.
Either way, these two docs [0,1] (not just those particular pages) could really use some clarifications. I had trouble working my way through either of them and they seemed to be giving conflicting information at times.
Granted, I have no significant experience with .NET or Mono. I was able to install Mono once on Ubuntu. But I gave up after trying to install .NET Core on Ubuntu (and FreeBSD) more recently - a week ago. Sorry, I can't provide more substantial criticism right now.
I guess the forums[2] would be the best place to bring these issues up in the future (with more information)?
It wasn't necessarily that [0] or [1] was confusing in and of themselves but that the information seemed to conflict at times. Having multiple sources can be helpful to establish patterns unless they are saying opposite things. But again, I cannot point to specifics.
I guess my current question is, can .NET Core be built on FreeBSD without a Windows machine? It appeared that this, for one, was not the case. This is a bit of a showstopper.
So it looks like the answer is yes then. You do need a Windows machine to build the managed components. So I cannot build (for now) if I do not have a Windows machine.
I did actually follow this guide, though I still wasn't able to compile. The build failed before the managed components section. If I have a chance to look at it again, I'll try to file a bug report or get more help.
You would use Mono for mobile apps (i.e. Xamarin's bread-and-butter), cross-platform desktop apps, and server apps based on currently released versions of ASP.NET.
You would use .NET Core for server apps based on the upcoming version of ASP.NET.
In the future, it would nice if an ecosystem builds up for using .NET Core in other contexts. In particular, I know that not so many people care about desktop GUI development these days... but it would be great if you could combine .NET Core and AOT native compilation. Be able to write cross-platform desktop apps in type-safe, more-friendly-than-C++ language... and be able to ship them as standalone executables rather than worrying about a Mono or Java runtime being installed.
Maybe you'd be interested in mkbundle[1]. A tool mono has for close to a decade that allows you to bundle your app and all its dependencies into a single file.
We use it extensively at Xamarin with our platform.
.Net Core does not have the same API coverage as Mono. So some things are available, while others are not. (I think) Mono is integrating things from the open source parts of .Net, but you still have areas where you might be using something that isn't available in Core but is with Mono (non-win) or the full framework (on windows).
Xamarin is positioning themselves as more of a cross-platform tools company now, since the definitive "multi-platform .Net RT" will come from Microsoft. It looks like Xamarin's business will be to build on top of that.
Oh, Microsoft finally woke up and supports path longer than 260 chars in dotNetCore. So, the questions when will Microsoft WinAPI & and the Windows Shell/Explorer too? Will we probably have for Windows 11...
I thought windows allowed this already with some sort of weird UNC path spec. Instead of "c:/program files/whatever", you'd do "//?/c/program files/whatever", and then it lets you use really long paths. Or is that not right? I'm just going off vague memories and [0]; I'm really not a windows guy.
That's the idea, however this does not automatically make programs actually work with long paths. Command Prompt is a prime example, at least on Windows 7.
What are the uses for this besides npm < 3.0? I'm super curious, the 260 limit seems like a huge flaw but in my interweb travels I haven't seen it mentioned anywhere else
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.
I have dealt with this in an enterprise quite frequently, dealing with people's home areas. If the home area folder is already 80 chars before the user starts creating deep folder structures with long filenames, you will run into this if you deal with a large number of users.
I've run into this problem using TFS on Windows before. Combination of folders within folders and a deep source tree would force me to abbreviate in file names and pull the source directly into C:\ rather than a preferred place.
Have a TFS build server that puts your cloned projects at not-the-top-of-the-filesystem.
It's very easy to hit that limit. It's atrocious and a joke. And Microsoft has paid me as an employee to write some ridiculous stupid workarounds for it in completely 100% managed C# code that shouldn't be bound by such stupid legacy decisions.
I hate MAX_PATH with a passion. It's one of those things that basically forces a hacky solution every, god, damn, time.
PowerShell is less like bash and more like a
.net based DrRacket.
You can instantiate
.net objects, query their state, manipulate them interactively, and pass them around. You can also trivially write new shell commands in C#.
If you go through the tutorials and write a cmdlet in C#, and see how it interacts with powershell, you'll understand why it's cool. Might not be useful for everything, but it's well designed and extremely powerful.
Having a command-line interface that allows me to instantiate and interactively mess around with any .NET object was the killer functionality that first got me to really start playing with PowerShell, but the object-oriented pipeline really soured me on text-based pipelines in general. It's a very powerful, I would say underrated, way of doing stuff.
Basic man-page style documentation for your own scripts comes practically free with powershell. Powershell uses named parameters (though technically you're not forced to do so) with command-line tab-completion. Powershell uses a standardized verb+noun syntax design which makes it slightly easier to figure out what commands are what. Powershell uses an object pipeline instead of plain text.
This is the spirit of unix taken to the next generation. It's an incredibly useful CLI environment and pipeline which makes it easy to combine small tools to achieve powerful functionality while also facilitating making scripts by making them easier to use and easier to write.
For example, let's say I wanted to find every process using more than 100m of ram. With powershell that's just:
get-process | where WorkingSet -gt 100e6
Because powershell is object based you gain a lot more potency in the command pipeline. For example, let's say I wanted to kill all processes that matched a certain filter. That's as easy as piping the output of get-process through some filters then into stop-process. Let's say instead I wanted to wait until all instances of firefox are closed, that's just this:
get-process | where path -like '*\firefox.exe' | %{ $_.WaitForExit() }
Powershell is far from perfect and it has a few very annoying gotchas here and there, but so does bash, python, and any other language for that matter. Powershell is a very powerful language that has benefited from a lot of rethinking of some of the traditions in command line interfaces that exist solely because that's how it used to work back in the day despite the reasons for those choices no longer pertaining in the here and now (teletype terminals, slow connections, slow everything, etc.).
A common complaint from people used to bash is that it's verbose. But since everything is autocompleted and there is support support for short aliases it's very hard to claim it has to be more verbose than bash. Using long description funcion names by default, and shorter alias as an option is clearly the sane design choice.
Fundamentally? Passing objects around instead of text means that I spend a tonne less time futzing around with cut, awk and sed transforming the output of one tool into appropriate input for the next one over.
Off the top of my head: native hashmaps. Native JSON marshalling/unmarshalling. Native HTTP calls. Control structures that don't suck (ie, bash doesn't even support variable comparison natively). Probably lots more I'm forgetting.
`test` (aka [) is a bash builtin, FWIW; integer comparison works perfectly well inside (( )).
I generally prefer bash for job control and pipe parallelism. For more complex tasks that would require a hash, internet access complex parsing etc., I tend to write a script in a different language, and plug it into a pipeline with bash.
The lack of parallelism in PS is the second biggest reason I don't use it.
The single biggest reason is bash is my common interface across Linux, Windows (cygwin), OS X and Solaris (when I used to run it).
> The lack of parallelism in PS is the second biggest reason I don't use it.
I've done parallelism in PS, it's not difficult[1][2]. IIRC there were some gotchas, but it's certainly possible.
> For more complex tasks that would require a hash, internet access complex parsing etc., I tend to write a script in a different language, and plug it into a pipeline with bash
Right, you have no other choice in bash. Powershell lets you do all that within the language itself trivially.
Great. I was looking forward to a good alternative with decent syntax to PHP, and now that ASP.NET can run on linux, there's nothing that stops people from using it over PHP.
Honestly I wonder what reason would one have to choose PHP over ASP.NET for their apps in a few months / years time.
Same reason people choose PHP over Ruby on Rails, Node.js, Compojure, Yesod, or the billion of other choices available today: because so many small business have their hosting via super-cheap linux boxes that you only get FTP access to.
Cheap hosting and PHP do go well together, but when you work at a company that has a lot of stuff written in one language, and the whole team is experienced with that same language, there needs to be a legitimate reason to change the whole technology stack. Because it's "cool" or not is generally not a good enough reason - unless it gets to the point where it isn't supported anymore, you can't find employees, the community has dried up, there's nothing new happening with the language, etc. But PHP, despite the problems it does have, it suffers from none of those things. So I don't see a mass exodus happening any time soon.
Completely agree. It's very exciting, and extremely cool but in terms of a business decision for larger technology teams, it will very much be like node.js, it's a similar thing, runs on cheap linux boxes and can do everything PHP can but it's taken time for companies to get it in where it "fits"
You could say the same about PHP vs Ruby, and would have been able to for a long time. Yet, people still use PHP. I suspect stuff like Wordpress has a big influence on that.
As someone who has avoided Microsoft in the past, I've found myself in a position to write a few projects lately on the C# .NET platform, and actually find myself eager to have this available on OS X. I actually enjoyed a lot of features of Visual Studio specifically (I realize this isn't coming yet), but the platform itself really just feels pretty nice and natural.
I've been eagerly keeping a close eye on .Net Core. Congratulations to the teams that have been working on this! It's long overdue and I can assure you many others are keenly interested in this.
For myself, mainly because as primarily a Python programmer I've been looking for where to move next with the 2/3 split. I've migrated completely to PyPy4 (which is Python2.7) rather than port/test to CPython3 in the last few years. It was worth the migration and testing that was involved.
I'm waiting to see if PyPy will announce they are the flag bearers for Python2. If so, I'll most likely continue using it going forward.
On the other hand we use .Net and Python at work so while most people would not agree or find .Net Core to be a bit pointless, for me it means I can move my projects and small business to run on my underpowered VPS, utilizing the same well-supported tech stack that many enterprises use.
Keeping my head in C# is a good advantage as I'm also interested in Xamarin and Unity (both professionally and personally). Of course, I'm one who does not have any particular grudge against Microsoft. I do prefer POSIX based systems.
For my home business and hobby tech stack I'm currently looking at 1) PyPy4, 2) .NetCore 3) CPython3. While I'm currently running everything on PyPy4, there's a smaller gap between 1 and 2, and a big liklihood of adoption gap between 2 and 3.
Exciting to see the rc released. I've been waiting up until this point to really dive into a project.
One of the things that will be a huge barrier for me though is the lack of system.drawing. I've worked in the sign and graphics industry for 8 years and a lot of software I have written relies on system.drawing. The font rendering is crucial. It appears the only feasible option is the mono implementation.(and maybe that is good enough)
Looking ahead I'm curious if there will ever be aa coreclr replacement for this? It seems Microsoft closed the open issue regarding this.
It's confusing, but ASP.NET 5 ships with ASP.NET MVC 6. ASP.NET MVC 5 was released in October, 2013. I'm assuming you meant ASP.NET 5 / ASP.NET MVC 6 since that's what was announced today.
There's a good chance you know this, but since some people reading this thread might not I figured I'd give some more detail.
It's definitely in Microsoft's interest to make Azure a great place to host your ASP.NET applications. The team that builds ASP.NET is part of the Azure group, and that's what pays the bills. (disclaimer: Microsoft employee, Azure fan)
However, ASP.NET 5 has been built to run great on your own web server. In addition to IIS on Windows, ASP.NET 5 has a cross platform, open source web server named Kestrel that runs on Windows, Mac and Linux: https://github.com/aspnet/KestrelHttpServer/
I did that the other day, on beta8 or whatever. In that case, I could run a console app. Then I tried the Yeoman setup [1] for a simple website without auth. It failed to run.
Today, I uninstalled mono, previous dmx stuff, and ran the package linked in this story. Same result. Yeoman website failed.
It's failing to resolve the fx dependencies.
Also, it's difficult for me to understand if I need mono or not. I have it.
I was able to use 'dnu build', but that looks like it builds a dll and places it in a folder. I was curious if it's possible to build a single executable (similar to go) that can be run. Also, 'dnx run' is slightly slow so I wanted to see if the performance hit was less after building an exe.
Soon, but not quite yet. you'll be able to "dotnet compile" in a folder and that'll make stuff, and then "dotnet compile --native" will give you a single linked executable.
I think setting DNX_TRACE=1 will give you some more info. Probably better to open an issue and discuss there - at least because it's easier to read large amounts of text on GitHub
Can't wait to figure out what you can do with this on Linux. Anyone knows? Maybe not desktop apps but Web Apps should be doable at this stage?