Lot of people in this thread crapping on Microsoft, but that's not to say that there's not some valid criticism here.<p>Microsoft is trying to unscrew the single platform nature of dotnet. This is going to take some time. They are having to break bones to set them correctly. Let's not pretend that any of us devs have never inherited an old project that we had to fix, and left a wake of destruction.<p>That said, shame on them for not listening to the community more. Many, many people on Github were very vocal about the project formats and the build system, and it was obvious that Microsoft made up it's mind.<p>While I'm a huge fan of dotnet, I also have to chastise Microsoft here. You can't leap to open source and then crap on your contributors when they are telling you that you're making a blind decision. If it was the one contrarian person that always complains about everything, I could see it, but it wasn't. Very notable members in the dotnet ecosystem raised the warning flag on this.<p>I for one kept with the mindset of not building anything for production with their v1 release. This is an old rule. By v2, I'm betting this thing will be awesome. Hell it already is. Let's not throw the baby out with the bathwater.
Stop. Before moaning about json vs xml consider that the sln file is a non-stand external dsl that's existed since the early nineties. Now that's something I'd like to see being replaced.
I might be the odd one out since I don't find the XML format that bad.<p>A bit sad when you can't add comments in json like formats. (nobody really uses json5)
You can see the syntax below to specify the set of targets that you want to build for, as a semicolon-separated list.<p><TargetFrameworks>netstandard16;net452</TargetFrameworks><p>Fresh release of XML-based config file that already uses single string field for array?
Glad to see a more unified approach, particularly with .NET Standard and Xamarin [0]. I've been experimenting with Xamarin.Forms recently and put together a little mobile game. There are a couple of blog posts coming on that, including the whole shared projects / PCLs / .NET Standard thing.<p>[0]: <a href="https://unop.uk/net-core-1-0-1-and-net-standard" rel="nofollow">https://unop.uk/net-core-1-0-1-and-net-standard</a>
Hope this csproj is final breaking change on this!.I am not sure if any other project has gone through so much of changes from the initial release. It was called kvm,kre,klr [1]-> dnx,dnu,dnvm [2] ->coreclr,corefx ->changes to project.json to csproj system . I have started writing a gitbook[3] on asp.net core when this was in the RC phase but everything I learned or wrote had to be rewritten .I did not merge my dev branch to master for whatever new I was writing and eventually I stopped.I am wondering what would happen to all the books currently published where most of the book will be referring project.json<p>[1]<a href="https://weblogs.asp.net/imranbaloch/k-kvm-kpm-klr-kre-in-asp-net-vnext" rel="nofollow">https://weblogs.asp.net/imranbaloch/k-kvm-kpm-klr-kre-in-asp...</a><p>[2]<a href="https://blogs.msdn.microsoft.com/webtopics/2016/01/14/getting-to-the-crux-of-dnvm-dnu-and-dnx-in-asp-net-5/" rel="nofollow">https://blogs.msdn.microsoft.com/webtopics/2016/01/14/gettin...</a><p>[3]<a href="https://www.gitbook.com/book/openlearningportal/all-about-asp-net-core/details" rel="nofollow">https://www.gitbook.com/book/openlearningportal/all-about-as...</a>
I am currently working on two dotnet core projects (both ASP.NET Core) and my only complaint has been the tooling. Visual Studio talking in terms of solutions and the dotnet cli talking in terms of projects means that I have `launch.{sh|ps1} scripts for those not using VS and launchOptions.json/the sln file for those working in VS. It feels like something that should have been sorted out, even if it took a new `dotnet startup` command to emulate Visual Studio's StartUp projects. Entity Framework Core tooling, especially with SQLite, has also caused some issues around migration handling (in that there basically is no migration handling for sqlite, causing you to write a custom script to nuke the database and migrations every time you make a change).<p>The platform itself, however, is fantastic.
So...when do folks think it will be safe to use this? Often 1.0 is reserved for "we'll try to make less painful interface breaking changes after this release". But if this is any indication, we're still a ways off from API stability.
How come this story could be reposted so quickly when it has been submitted already 11 hours ago? <a href="https://news.ycombinator.com/item?id=12747592" rel="nofollow">https://news.ycombinator.com/item?id=12747592</a>
What a disaster. The tail wagged the dog in the .NET Core team. Every step of the way it became clearer that this was a pet project of some ivory-tower programmers and that we would be left to patch together this mess. Try adding a .NET Core project on your build server. You'll hate yourself by the time you get it building.
The .csproj msbuild file is here to stay? really? Why are we having to fit programming a build system around an archaic xml declarative language? The .csproj is the single worst point of the visual studio experience. Terrible format, editing experience, having to reload, having to copy paste GUIDs, manually lookup .target files ugh the whole thing is horrible.
Coming from a Linux/macOS background, this article is really hard to read. So many .Net-Buzzword things, MSBuild, project.json, csproj, sln...
I'd really appreciate if they streamlined how to get started with C# cross platform.