7 ms·
Announcing .NET Core 1.1 Preview 1
- wmccullough 10y agoBug fixes this release: https://github.com/dotnet/core/blob/master/release-notes/1.1/1.1-preview1-commits.md https://github.com/dotnet/core/blob/master/release-notes/1.1... >1380 APIs were added in this release >Added support for Linux Mint 18, OpenSUSE 42.1, macOS 10.12, Windows Server 2016
- oblio 10y agoIt's good that they're iterating rapidly. > .NET Standard 1.6.1-preview1 was published as part of this release. .NET Standard 2.0 support is still coming. I feel like the highlight of .NET Core will be when it finally implements .NET Standard 2.0. For those who haven't been following, .NET Standard 2.0 is basically the moment when .NET finally reaches cross platform consistency parity with Java. For Java, if you want to have a cross platform app, you just target Java. For .NET versions pre-.NET Standard 2.0 you basically target a mishmash of platforms through "profiles". Imagine that when you're creating a Java app you'd be forced to chose a "profile" that says: this app supports JavaCombo12 (AIX, Solaris, Linux). Then once MacOS is available as a platform you have to choose JavaCombo13, that includes that. And then JavaCombo14, JavaCombo15, etc. Oh, I almost forgot! To make things more interesting, each "combo" could have different APIs available! :)
- mmgutz 10y agoI'm still confused on which .NET profile is entirely guaranteed to work on all platforms.
- xamlhacker 10y agoWait a few months. Then target your library development at .net standard 2.0. It will work across the classic .net framework (Windows), the new cross-platform .net core (Windows, Linux, OSX) as well as the Xamarin (iOS, Android, Windows UWP).
- mmgutz 10y agoThat's exciting. I applaud MS for openly expanding to other platforms but the confusing profile names need to be simplified. IMHO, there should be two profiles .NET Universal and .NET Windows (a superset of .NET Universal).
- mgkimsal 10y agosomething being a superset of a "universal" lib is not confusing?
- pjmlp 10y ago> Imagine that when you're creating a Java app you'd be forced to chose a "profile" that says They are called: - Android Java - Java Micro Edition - Java Embedded Edition with (compact profile 1, 2 and 3) - Java Standard Edition - Java Enterprise Edition - MicroEJ Java - Real Time Java Ah, then there are the vendor specific features like AOT compilation to native code or value objects like the Packet Objects in J9, just to give a possible example.
- oblio 10y agoI thought someone would nitpick that statement. Microsoft supposedly designed and built .NET as a cross platform framework, even though they only released it for Windows. Yet many years after .NET's release and the .NET Core announcement, they're still struggling to achieve parity with Java. Meanwhile, many of the examples from your list don't compare 1:1 with .NET profiles, because... : - Android Java This was caused by Google, so not $VENDOR's fault (Sun/Oracle). - Java Micro Edition This is moribund these days. - Java Embedded Edition with (compact profile 1, 2 and 3) This targets a totally different use case than the average .NET profile (most .NET profiles are minor variations on a theme). - Java Standard Edition Let's just call this "Java" :) - Java Enterprise Edition Let's call this "Java" + libs. It's hardly a profile, it's just Java + stuff on top. - MicroEJ Java I don't really know about this one. - Real Time Java See my comment about Java Embedded. .NET profiles are IMO, just an ugly hack to re-add portability to a platform that was designed with portability in mind but then lost it gradually as it became more and more integrated with Microsoft platforms.
- pjmlp 10y ago> - MicroEJ Java > I don't really know about this one. A Java version produced by IS2T for micro-controllers, think cortex-M class. http://www.microej.com/ http://www.microej.com/ http://www.stm32j.com/products/ http://www.stm32j.com/products/ As for the rest, we will have to agree to disagree. Regardless how it looks like in detail, in the daily work they are issues to take into account when trying to write portable Java code. .NET was designed with portability across processors and Windows versions, not for other vendors. Even Rotor wasn't fully compliant with .NET 1.0. When looking at the histories told by Don Syme related to the initial generics design and Ext-VOS, .NET genesis was to be a native platform based on COM. Actually something that was brought back to life as .NET Native + WinRT. As for the .NET profiles, they aren't perfect, but as someone that works daily with Java and .NET, I look forward to them.
- rpeden 10y agoIt'll almost have parity with Java once Core support .NET Standard 2.0. One admittedly unpopular area it'll be missing is options for desktop development. I know that the trend these days is to use web interfaces, and web development makes up about 95% of my professional life. But just out of curiosity, I picked up a WPF book from the library. And as I was reading through it, I remember thinking how nice it would be to be able to develop web apps with something like that. I suppose Silverlight would've been close, but it's dead these days. It looks like JavaFX is broadly similar to WPF over in Java-land, and it appears to work fairly well cross platform. It doesn't look native on any platform, but that isn't always a deal breaker. Using Intellij's non-native looking Swing UI on my MacBook doesn't bother me, though I appreciate that not everyone feels that way. I suppose this is my roundabout way of saying I'd love to have a decent cross platform .NET GUI framework. For anyone who wants this too, Avalonia looks like a good project to follow: https://github.com/AvaloniaUI/Avalonia https://github.com/AvaloniaUI/Avalonia It doesn't appear to support .NET Core yet, but last time I checked they expected to be able to relatively soon.
- pjmlp 10y agoI have been doing projects in the healthcare area. In what concerns computers to control robots, measurement devices and doing ETL data processing of data readers, on the projects I have been involved it is 100% Windows native WPF applications, with the legacy ones being a mix of MFC and Windows Forms.
- bopcrane 10y agoDespite the uncertainties I have about .NET's future, I'm very excited for the possibilities this will open up if they would continue this pace and just listen to the community. I myself can't wait for the freedom to choose a linux or windows server to deploy on
- krat0sprakhar 10y agoQuestion to the seasoned .NET devs - If you're planning to build a F# app that will eventually be deployed on Linux and developed on a Mac, what (& why) would be your choice - Mono or .NET Core?
- redboxcandy 10y agoMy plan is to target .NET Core. I like the idea of being able to run on cheap Linux instances. Although Xamarin is part of Microsoft, I'm concerned Mono might end up being the red-headed stepchild, with Core getting better company backing. The only thing that sucks is that currently some of the larger cool projects (like Suave and Akka.net aren't ready for Core yet (I think)). So eventually: sweet, short-term might be a couple more headaches.
- krat0sprakhar 10y agoI agree! In the new scheme of things I'm not sure how Mono fits into the .NET landscape. I was eagerly waiting to get a answer in Changelog's latest episode[0] but sadly they didn't cover this at all. It's even more confusing that there is absolutely no mention of .NET Core on the language's Github page - http://fsharp.github.io/ http://fsharp.github.io/ [0] - https://changelog.com/podcast/224 https://changelog.com/podcast/224
- sremani 10y agoIf you are planning on launching in matter of couple of months, mono. If you are thinking 6 months and beyond, .net Core. Also, .net Core does not have feature parity with .net4.6/mono, so you may want to know the gaps depending on the type of application being built.
- Nelkins 10y agoDepends on what APIs you need, and what your tolerance is for futzing around with things. If you need the larger API surface of the .NET Framework and you don't have time to be on the bleeding edge, go with Mono. Xamarin Studio has good support for it, and even if you're using some other editor (VSCode, Spacemacs, etc.) everything still generally works with the tooling for Mono. There are basically two components that need polishing for .NET Core to be a reasonable choice - the implementation of NetStandard 2.0 for .NET Core (so you get all the old APIs back), and for the tooling to mature (transition from project.json back to fsproj). These efforts are coming along nicely [1][2], but still aren't ready for prime time. Here's a roadmap that Enrico Sada has laid out to get the F# .NET Core situation to maturity: https://gist.github.com/enricosada/6f0a0424ca65b9d08e5a84f79560c4c6 https://gist.github.com/enricosada/6f0a0424ca65b9d08e5a84f79... And by the way, don't worry too much about switching over from Mono to .NET Core. With NetStandard 2.0 the API changes should be minimal. Similarly, once the cleaned up proj file format is out of preview the change in tooling from Mono to .NET Core should be minimal (or even non-existent). [1] https://slack-files.com/T04BJKUMU-F2ST232AJ-6e68200a3d https://slack-files.com/T04BJKUMU-F2ST232AJ-6e68200a3d - Enrico Sada's work on getting dotnet cli to work with proj system for .NET Core [2] https://twitter.com/sforkmann/status/790488306991661056?s=09 https://twitter.com/sforkmann/status/790488306991661056?s=09 - Steffen Forkmann getting Paket to work with new proj system
- nowprovision 10y agoCould be worse, can't see a new keyword yet
- GordonS 10y agosigh, predictably, there are a few: LTS, FTS, train.
- GordonS 10y agoI find all the terminology and tooling around .NET Core... confusing. Let's say I want to target RHEL and CentOS, versions 5-7. If I build mono on a machine with an old enough glibc, that single build will run on all of these. What's the equivalent to run on all these platforms with .NET Core?
- nightski 10y ago.NET Core is the equivalent to mono. However the .NET Core libraries were a bit painful to port to since they were limited. So they are expanding this with .NET Standard - which is an API specification - which you can use and work across all .NET platforms (.NET Framework, .NET Core, or Xamarin). Keep in mind it sounds like .NET Standard basically is between the full .NET Framework and .NET Core. So if you have an existing .NET Framework app it's very possible it would just work on .NET Standard.
- GordonS 10y agoBut what about runtimes? Can I have a single .NET runtime that will work with all of those Linux versions? With mono I have a single runtime that actually works across almost every Linux distro. Can I do this with .NET, have a generic runtime build that just works on everything?
- euroclydon 10y agoASPNET Core 1.0 has dependency injection built in. Is there something similar for non-aspnet core apps?
- oblio 10y agoSimpleInjector works on .NET Core.
- Sacho 10y agoThere's a lot of popular nuget packages handling dependency injection, in fact, the ASP.NET docs encourage you to use one in place of their own rudimentary implementation. The ones I'm aware of that have ported to .net core are StructureMap and Autofac.
- euroclydon 10y agoThe more rudimentary the better if you ask me. DI should be a standard library feature if you ask me.
- tmzt 10y agoCan anybody comment on what would be required to run .net 4.6 applications using System.Web on this? Could the Mono codebase be used for this?