An update on ASP.NET Core 1.0 RC2
What's going on with ASP.NET Core 1.0 RC2? Why is RC2 taking so long over RC1 and what's going to happen between now and the final release? I talked to architect David Fowler about this and tried to put together some clear answers.
This stuff is kind of deep and shows "how the sausage gets made" so the TL;DR version of this is "the guts are changing for the better and it's taking longer than we thought it would to swap out the guts."
That said, ASP.NET Core RC2 has some high level themes:
Re-plat on top of the .NET CLI
This is the biggest one and there are quite a few changes and tweaks made to the hosting model to support this. The way your application boots up is completely different. I'd encourage you to take a look at the https://github.com/aspnet/cli-samples. Some of the changes are very subtle but important. We baked a bunch of assumptions into DNX specific for web applications and now we're building on top of a tool chain that doesn't assume a web application is the only target and we have to account for that.
There were a couple of fundamental things affected by this move:
- How do you get the tool chain and shared runtime?
- The API used to find dependencies at runtime ILibraryManager
- The API used to find compilation assemblies at runtime ILibraryExporter
- There's no dnvm replacement
- Visual Studio Tooling (UI) support needs to use the new CLI
- OmniSharp needs to use the new CLI
- What's the dnx-watch successor?
The list goes on and on. I'd suggest watching the ASP.NET Community stand up as we're pretty transparent about where we are in the process. We just got everyone internally using builds of Visual Studio that have CLI support this last week.
The new .NET CLI (again, replacing DNX) will be the most de-stabilizing change in RC2. This is a good intro to where things are headed https://vimeo.com/153212604. There's been tons of changes since then but it's still a good overview.
Moving to netstandard
This has been a long time coming and is a massive effort to get class library authors to move to the next phase of PCL. This is critical to get right so that everyone can have their favorite packages working on .NET Core, and as such, working everywhere.
We're looking at all of the patterns that we have invented over the last 2 years and making sure it's consistent across the entire stack. One example of that is the options API. We went through the entire stack and made sure that we were using them consistently in middleware and other places. That is a breaking change but it's an important one.
Other examples of this include things like making sure we have the right extension methods in places and that it looks like they were designed in a coherent manner (logging is an example).
Other small things:
- Remove the service locator pattern as much as we can. Some of this requires API change.
- Making sure we have the right set of DI abstractions so that DI vendors can properly plug into the stack.
- Taking the time to look at feedback we're receiving to make sure we're doing the right things. This is ongoing, but if there are small changes we can make that solve a common issue people are having, we'll make that change while we still have this freedom.
- Change how we plug in and configure servers in our Hosting APIs https://github.com/aspnet/KestrelHttpServer/pull/741
Fundamentals - Stress, Security, Performance
This is always ongoing but now that most of the features are done, we have more time to spend on making things like Kestrel (the web/app server) rock solid and secure.
We're also doing more stress runs to make sure the stack is very stable memory wise and to make sure nothing crashes .
This is part of fundamentals but deserves to be called out specifically. We're still making changes to make sure things are very "performant." Some of these are tweaks that don't affect consuming code, others are actual design changes that affect API. MVC is getting tons of love in this area (https://github.com/aspnet/Mvc/pull/4108). HttpAbstractions and other higher level APIs are also getting lots of love https://github.com/aspnet/HttpAbstractions/pull/556 to make sure we reduce allocations for things like file upload.
We're also looking at higher level scenarios to make sure that not only focusing on microbenchmarks. You can see some of them at https://github.com/aspnet/Performance/tree/dev/testapp.
Techempower is still on our radar and we're running the plain text benchmark on similar hardware now and comparing against the competition (we're in the top 10 right now!) and we'll hope to be there and official for RTM.
I hope this gives you some context. We'll cover this and more every week on the Community Standup as we move towards RC2, then on to RTM on three platforms!
Sponsor: Big thanks to RedGate and my friends on ANTS for sponsoring the feed this week! How can you find & fix your slowest .NET code? Boost the performance of your .NET application with the ANTS Performance Profiler. Find your bottleneck fast with performance data for code & queries. Try it free
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
Again, looking at this in the scope of decades versus months, this is no big deal, and is the right thing to do. Take your time and yield excellence, team. Everyone deserves this, especially you. :) You've basically overhauled a core/key component of the .NET universe and everyone needs to recognize that chances are VERY high that this is not going to go off without a hitch regardless of how talented everyone is over there.
Besides, you ARE being transparent with the standups which is incredible and should be commended more than it has been.
Do so, and
As has been said in the wood trade for centuries - Measure twice, cut once!
It's sad, but ASP.NET vNext has done more to drive me to Node.js than anything happening in the Node.js community.
Many of us view time spent on frameworks that have been abandoned as wasted time. Wasted time is bad. I don't want the flavor of the month. Give me something that works, something that's rock solid. Give me something that's going to be around for years as opposed to a few months so I can build during that time rather than having to perpetually learn the next shiny thing. Entire development teams are wasting obscene amounts of both personal and professional time on the flavors of the month. It's called the bleeding edge for a reason. IMO, at a certain point the research and POCs needs to take a back seat to actually building something meaningful that does something meaningful rather than just being shiny and new. That means rolling up your sleeves, getting a little dirty, and using something that's older than 6 months, a year, or (gasp) even two years old.
And yes, I'm getting old. Get off the lawn. :)
Well said. I'm also hoping for something that I can be the future on, not just the next six months.
I'm looking forward to RC2.
All that said, I know the various teams are tackling an enormous beast, and I'm sure the end results are going to be awesome. Just know know badly needed clear documentation is. And once you settle on a name, maybe just...settle on it. :)
I hope I'm wrong, but the last two years of churn and constant direction change gives me little confidence that ASP.NET vNext will be a compelling enterprise-grade alternative to the more popular tools out there.
@Matt Honeycutt: You're not wrong about tools and libraries flaring in and out of existence, and of the Microsoft platforms typically being late to the party or absent altogether. But ASP.NET as it was had plenty of problems other than the parts that were about creating Microsoft alternatives to common solutions. The endless efforts to divide System.Web up into something that's pay-to-play speaks loudly of what shape it was in, and it was high time for a decade and a half of software engineering, lessons from MVC and the embrace rather than the uneasy pistol-whipping of HTTP to be folded back into the core. And to make an omelette, you have to crack a few eggs.
And yes, of course, I was satisfied with grunt and gulp being embraced and supported until half the community started using webpack and browserify instead, too. And I look forward to versions of Visual Studio tooling and ASP.NET Core that fruitfully integrate with them too. But this is a problem that five guys in a room can solve in a few weeks (at least if one of them is Mads Kristensen...). ASP.NET Core is about more than that, and it's just in the beginning that the concrete has to set to form a good foundation. The whole stack being NuGet-based means that the updates can come weekly, monthly or nightly, and that as soon as there is an initial version, these things will be much easier to deliver sooner.
Of course I'd like a lot of hours back in learning things I had to unlearn. I'm guessing that this is not an uncommon sentiment at Microsoft either. After all, they had to build it, and chances are that if they hadn't, they wouldn't know what the dotnet CLI (still a horrible name) foundation should have been instead to avoid the issues. Basically, shipping a 1.0 never stops being rough work, but once that stake is in the ground, the fun can really begin.
As much as we can find flaws and valid criticism with stuff that's been going on, you all deserve our thanks and gratitude too for making ASP.NET Core happen at all.
Despite it's making us suffer, I'm glad those changes are happening now and have hope it will avoid reproducing the windows apps sdk nightmare (1 different version with a different runtime and sometimes xaml per platform). After all no one forced us to switch to asp.net core & .net core.
To people threatening that they'll switch to node.js I would say please do and start tackling those kind of issue where every solution is deprecated or unstable.
Metro, Metro-style, Windows 8-style, Modern, Windows Store, Universal, Windows Apps, today's App Name of the day on your chart is UWP (Universal Windows Platform App?)
Now we have to figure out .NET Framework vs .NET CORE vs .NET STANDARD LIBRARY
Then I have to decide if I want to learn a new bunch of Middleware languages like Bower, Grunt, Typescript, Linq, Linq to sql etc, or wait and see if they go away like Dodos.
The complexity of the Microsoft stack is starting to get overwhelming and I've been using it for over 30 years. And then I have to figure out how to teach it to Computing Science students.
It's starting to make competing frameworks like Meteor look so much simpler.
I thought the goal was to eventually make .NET Core the one true .NET that works everywhere, with each platform having a few of their own specific assemblies? This new diagram seems to indicate that Mono, .NET Framework, Core, and god knows what else will all continue to exist ad-infinitum.
It also seems the scale of these changes would indicate you guys need to think about cancelling the "RC" label and go back to calling the next version an alpha or beta. As evidenced by other comments on this thread, you're screwing your customers over by using the "RC" label and giving a false impression that it is a stable code base.
Finally- what does this mean for Entity Framework? I've noticed that team has been conspicuously silent in 2016. I'm eagerly await a release of EF (or any ORM for that matter) that actually works well at enterprise scale and is being actively supported.
No wonder why my test proyect blew on me after updating, I embraced .ASP NET 5 and MVC 6 since the beginning betas, migrating a Project with 60+ controllers from MVC 3 to MVC 6, all was good and simple, sudenlty everything started to fail
For one, you should have expected instability from the betas and for two, you shouldn't have migrated such a large MVC3 project. The mantra has always been if you're using ASP.net 4/4.5 then stick with it.
The amount of breakages between RC1 and RC2 has been staggering and I'm sure a few people have been caught out with the "production release" RC1 but at the same time, the RC1 bits still work just fine and though the tooling underneath will change drastically, 95% of your code should migrate easily. Some namespaces will move around and you might need to tweak your project.json a bit but the migration from RC1 to RC2 should be much simpler than migrating from ASP.net 4.6 to ASP.net core.
Wow. Trying to read https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md makes my head hurt. I assume someone understands all that but it sure isn't me.
Okay, I'll give a stab at explaining what the "netstandard" thing is all about. To see why it's important, you need to know how stuff works today to understand where the issues are. It comes down to libraries.
If you download a good library from Nuget today and take a look inside the nupkg file, you'll probably see that this "one" library actually contains several different versions - there's usually a version for .net 3.5, 4.0, 4.5, 4.6 and then there could even be other versions for Windows Phone and so on. Now, if you've never built a library like that before, you're probably wondering - how the hell do you have a csproj that targets 4 or more different .net frameworks? The short answer is, you don't. The library developers tend to have several csproj files that reference most of the same .cs files, with a lot of #if blocks to separate code that only works on .net 4.6 or whatever.
There is a solution to this, which is PCL. The problem is, as a library developer, what you have to do is basically pick all the platforms you want your library to support and you'll get a project that will only compile with all the stuff that's actually available on those platforms. Each possible combination gets given a number and there's literally hundreds of possible combinations. Worse still, each time a new platform appears, the number of profiles goes up more or less exponentially. And the absolute worst part? If you want to develop on that new platform, you have to wait for library developers to actually rebuild their library for it - even if your platform technically supports all the functionality the library requires. It's an utter mess.
Well, .net core is yet another new platform and one of the first things they decided was having multiple csproj files was smelly and bad - so the project.json can target multiple frameworks, so that helps a lot. Still, if you target 5 frameworks you end up with 5 outputs and again that's still pretty messy.
The netstandard stuff is going to help fix all of this. The idea is that instead of hundreds of different profiles, you have a single standard. Each platform will support a minimum version of that standard and anything afterwards. So if your platform supports netstandard 1.2 (For example), then you can use any library that targets netstandard 1.0, 1.1 and 1.2.
If a new platform comes along (say .net 4.7? or .net core 2.0), then all those libraries targeting the netstandard will work out of the box without the developer having to do a thing. This should make building libraries much simpler from now on.
But, seriously, you need to work on your naming. "RC" means stable - just the last polish. You are making major changes. RC1 and RC2 are not release candidates - they are clearly Beta 1 and Beta 2 with the amount of changes going on.
Now, create a Microsoft distribution of Linux, port C# to the JVM (all the bits you can at least) and basque in the open source glory you all so desperately want to be a part of! The cloud and DevOps guys would love you because, well, Linux, and the developers would love you because you guys could bring great tooling to the table.
Skate to where the puck is going to be!
Seriously though, this stuff is really hard and you're all doing your best. We'd all rather you get it right and hopefully this can be the last major rewrite for a while.
Oh and yeah, if you want to implement any of my dream scenario I'm completely down with that too.
That's ridiculous. .NET has a great ecosystem and doesn't need JVM in order to be successful.
I have been playing with vNext since beta 6, made a few personal toy projects, hosted in azure. I hope my next serious project in my company can be written in asp.net, instead of nodejs or rails or java or Go.
The RC1 release was not successful, you should not call it RC. I assume many people like me, know that between RC2 and RC1, there are too many changes, then hold back and wait.
5 months after RC1, there is still no ETA for RC2. I have to say shipping too slow is driving developers away from asp.net core.
PS: yes, grunt and gulp are outdated, now it is webpack. JS world is changing too fast, I don't think asp.net should bundle with those js tools. Instead, we can use c# to build the toolchain we need.
It'd help to mention that MS is moving likely 10,000,000 lines of code in the .net framework from a tied to win32 version to a more flexible one.
We use the bare minimum tool set .net, c#, asp mvc plus two top JS libraries for the reason that long term development and support costs are 5 times more expensive than the initial development time.
Insist a projected longevity of 6 years for any tool, JS framework or library in the MS Visual Studio tool set. Include ones with a committed development team and not 1-3 developers, a message base and a few random blog posts.
Publicly list the MS development tool ecosystem and announce end of life for the bottom 10% tools each year for 5 years.
Besides this I agree with you, we are waiting for the new Asp.Net for almost 2 years, and we only have one beta (RC1 is a beta in real, RC2 will be a real RC) without clear roadmap.
Totally get where you're coming from but whether we like it or not the JVM ecosystem sets the agenda for .NET. Not in terms of languages where I think we do very well, but in terms of frameworks and libraries. We usually get the port 5 years later. Or never. Or we get the unmaintained port. But that is all slightly off topic.
I don't think anyone is railing on MS here. Just a very concerned group of developers airing their frustrations. Mine was slightly in jest, but it served to illustrate a point.
I think there probably needs to be some kind of mea culpa here. The ASP.NET guys clearly didn't talk to the rest of the .NET team - who knew everyone wanted to be X-plat? Surely that's not useful to anyone other than web developers!
And that's the major point about the JVM - it started out X-plat. Once again .NET has to catch up and we have to wait while it does.
Like I said before though: we'd all rather it be right and take longer. So keep going and do the best job possible!
It is more than obvious that this is going to be a fiasco like has been the past 2 years. After many hours of discussion and brainstorming we decided to move to alternatives (like NodeJS). After a few weeks of training and rebuilding one of our legacy systems all of 15 .NET developers say that they probably never go back to ASP.NET. (really without exception!)
Unfortunately we spend too much time from beta 6 to RC1 to learn all of ins-and-outs and be ready for the final version. But seeing so many radical changes during this time looked like we were wasting our time and didn't gave us any confident about the future of this experiment of microsoft. After announcing latest radical changes we predicted that in best case scenario the RC2 comes in May and RTM in september 2016. But many of us even predicted a RC3. Let's see who was better in predicting.
Not a suprise and probably not a bad decision. Microsoft created Visual studio Code. It is written in Node.
Does it require runtime feature detection? Does it mean the same method can give different behavior on different platforms (because the implementation code is different)? If so, then this solution is just making the problem worse by making it more expensive to find and address issues (runtime errors rather than compile time errors).
I get what you're saying, but to me it comes across a bit impatient. What is stopping you from building what you need/want to build right now? What feature is missing in 4.x, VS2015, and all the tools available today that is an impediment to building pretty much any application you can dream of? I gotta be honest -- I can't think of any. It feels like we, as developers, have become a bit spoiled. "It has to be fast, it has to be lightweight, it has to be secure, it has to be stable, it has to be shiny, it has to be free, it has to be open(ish) source, and I want it all yesterday!" We have to remember this is a platform that hundreds of thousands, if not millions of developers and other professions will build on, all of which will be impacting tens or hundreds of millions of end users in their daily experiences on the interwebs. I'm just saying, let's get this right. ;)
This speaks to a lack of care.
If a new platform comes along (say .net 4.7? or .net core 2.0), then all those libraries targeting the netstandard will work out of the box without the developer having to do a thing.
If a developer wants to get the shiny new features of the new platform, then, he has to get his hands dirty and upgrade is application.
On the other hand, those guys at Microsoft are top-notch architects. Designing and upgrading an API is not done on a kleenex : they may introduce breaking changes but not unbearable ones (when for example going from .net core 1.0 to 2.0). If we don't make their life harder, then they'll have more time to do a better job than scratching their head on how to support older versions of the platform.
And I am a developer. My opinion is making their work easier and mine a little bit harder.
This is IE 6 all over again. This browser should have been killed when IE7 went out.
I am so pissed at them (Microsoft) because of that browser which is still in the wild. From day one, I was praying for some of the big players in the field to put in motion what I call the "browser version requirement manifesto" where support begins the third most recent version to the current one.
I put everything into RC1, I developed all my application using RC1, found a couple of bugs, but nothing I couldn't work around, and also since RC2 was "just around the corner" I really didn't cared that much about bugs.
And a few months online my users found a very annoying bug which gives random gateway errors when uploading files. Since my project is based around the concept of uploading files, I needed to fix this right away.
I found that the bug was already fixed in the GitHub repo, and it was scheduled for RC2, and I even announced to my users about the bug and that it would be fixed in a little bit.
RC2 was delayed indefinitely, and also I found there are A LOT of breaking changes, just starting with dumping DNX for another NOT YET WORKING AT ALL CLI system. I'm in a position where my project is kind of dying because there isn't much I can do.
I could use the "nightly builds", but I fear that will create MORE problems than solve the one big one I have.
I honestly feel a little bit betrayed by the Microsoft ASP.NET team, because I feel they lied to me about the RC being "production ready".
And I feel abandoned because there are no new releases of any kind, not even to fix these horrible bugs.
Honestly, I shouldn't used ASP.NET Core, I regret my decision, and I'm not looking forward a lot to it.
Something is wrong. The gap between RC1 and RC2 is too large and is ever widening. I fear that RC3 is so far off in the distance that now will inevitably be rushed to release regardless of readiness.
The gap between RC2 and RC3 won't be as large as it is between RC1 and RC2.
Those changes are for the better.
But I understand you, the architects were too fast on the rewrite.
Beside saying that, I do appreciate the work you have done already and the efforts you are putting into the project.
* ASP .NET Core EF: https://channel9.msdn.com/Blogs/DevRadio/DR1644
Shahed Chowdhuri, Sr. Technical Evangelist @ Microsoft
Of course not. Stay with .NET 4.6 for the next 6 months if you still want to stay with .Net
How am I supposed to understand documentation that heavily references technology that was new and exciting (DNX?) only to be replaced by something entirely different again a few months later?
Maybe it is just me but I would appreciate a more 'Explain This Like I'm a 5 Year Old' introduction to all of this. I certainly don't have the will or desire to follow a community standup to work it all out myself, or maybe I am just not the target audience here.
Do any of the people here complaining actually think they can go 2 years in the industry without learning something new? Sounds like monotony to me.
The RC1 thing was unfortunate and MS came around to realising that the rewrite had already accumulated some baggage. Heck, even I remember complaining about how kestrel vs. IIS bootstrap worked. MS listened and they are fixing it. We can't complain every time they do something, so ease up. Every change I hear about has me more and more confident in what will be released.
Finally, if what ASP.NET Core is doing confounds you, don't beat your chest and throw rocks at it. Realise that the model being developed is very relevant to what countless other frameworks are still doing today.
It's been a few years since I wrote any ASP.Net code, but I have written quite a bit of powershell, and this all sounds very cool to me.
Luckily most of our code is just plain C# and not tightly coupled to a specific version of .NET, but the delays and changes are of some concern, since our projects are advancing towards release-stage. Thanks Scott and the rest of the team for being open about things though.
Regarding the gulp/grunt tech getting old: this is not part of the stack. It's simply part of some of the starter templates. There's nothing stopping anyone from using a different technology for the front-end stuff. I generally use the templates as a reference only, and do actual work using the Empty template.
2. When your working with pre release you can / should expect big changes . Its the same story with Angular 2.
3. MS made a call its better to wait and integrate with command line to give a better and more integrated long term experience. Its their call and we wont know if its right or wrong for another year so stop the puerile winging.
It does not indicate waterfall or low quality or any of the other crap written above and even though frustrated you should be ashamed if you cant see that .
1) Using the term "Release candidate" for alpha versions was bad.
2) Please bring back the robustness of classic .net releases so we can become comfortable again.
3) Great that you guys talk.
May I suggest you don't jump on a speeding train that has just been released from the factory for trial-run testing. When the train derails, it's no use complaining that you never made it to your destination.
Here's an idea: use ASP.NET Web Forms. Seriously. It can do ANYTHING on the modern web! It is very mature, stable, fast, secure, and thoroughly documented. Also, there is a huge library of problems and solutions in the official forums. Just about anything you want to do has already been solved.
So, save your time, headaches, and frustration. Go back to ASP.NET Web Forms.
I want to thank you so much for the update , Also for the amount of amazing work that you've dedicated to Asp.Net Core.
We are building a big project using RC1 and we couldn't be more happy about the amazing performance and the new features
Can't wait to see the final Release .
Thank you, Scott & Asp.Net Team.
1. If I now want to stick to my database , I have to go back to clr452. That is a thin rope to walk on. No docker support, no net core, aspnet core is virtually not released for me. Remember clr 451 support is stopped as well.
2. Change the database (hahaha.. really ?)
my 2 cents - if its taking time .. why not just launch a new superhero ?
How would it feel if flash keeps going back to the changing room to adjust his briefs to make us believe he is superman ?
Flush that name ASP, why not get a new name for this guy ? One name, one solid release, nice documentation and good solid support. I know you guys are going in for parroting the open source world but don't get swayed , .NET was a productive environment and we loved it the way it was even before.
Till then we shall just hang on to the hope, and think about just using our good ol` .NETclr
many people are waiting on a template for pure WebAPI.
For example if one is creating a REST service that mobile apps or fridges will be consuming why he have to pull in full MVC including Razor engine etc.
Apart from perfomance issues as I read about the whole concept of rewriting to .NET Core 1.0 is to use only the libs You need.
Before we had a pure WebAPI project and we lost it?
So it got heavier for REST developers.
P.S. Sorry for double post, first one had a typo in my eMail address.
Learning something new is totally fine when it is constructive to a project, not destructive.
Throwing away existing code (that took time and cost money) because it does not fit into the latest seasons fashion trend is unsustainable.
I would say you are not paying the project bills. Hire a team of developers, pay for training, pay them to create a project, pay them to test it, and then trash it within a year or two when the next seasons fashion changes yet again. How long do you think you could keep this up and stay in business?
Microsoft, you really need to refocus your efforts on what makes you unique. ASP.NET Web Forms needs to progress further.
Even bootstrap have tons of 3rd party themes like https://almsaeedstudio.com/ , what else would you want ?
Sorry for my English, just my 2cents :)
So you think MVC is new because ASP.NET MVC came out after ASP.NET Web Forms?
Do your own research e.g. wikipedia.org and you will find MVC architecture has been around since the 1970's. Yes, it is 30 years older than ASP.NET Web Forms.
Microsoft knew about MVC for a very long time but did not embrace it until competitors started using it. Microsoft is a business and needs to compete. I think it is great that they have ASP.NET MVC.
However, the issue is that ASP.NET Web Forms developers want Microsoft to continue developing and progressing Web Forms technology. That is all. We do not war against or hate MVC, Web Pages, or any other technology.
No worries really, take your time and just fix it in a robust way. VS2015 is still the best dev tool hands down. And thanks for the transparency.
So I just tried to build a simple template out of the box. Just to try to learn about the embedded DI support; see if this puppy is even close.
Can't even get nuget to restore the packages. Read everything, tried everything.
Spent a whole day on this. I'm old. Don't have a lot of days to waste.
My fault for buying into the dream too early.
Back to work.
Keep at it, fellas. You do good work.
10 million name changes (and names still inconsistent) alphas labelled RC, and more importantly numerous design mistakes - let's call things by their name.
You guys have designed what I consider to be the masterpiece of frameworks (.Net Full). But I think that we can agree on the fact that you are not operating at the same level on that one.
I am saying this respectfully : it is unacceptable for an architect to get the API wrong when starting from a blank page with full ownership of the code (you own .NET, linux is open-source, etc...). Telling us today : "Oh we noticed things were inconsistent", "oh we want to redo these fundamental APIs", "oh we're changing the pipeline" is unacceptable - not even mentionning doing so with the RC label.
Sure we learn about the design during the actual implementation but what you normally learn are implementation details. Here the situation is that you got your "ideal" public API wrong, this is not reasonable, especially when you are Microsoft. Looks like you haven't done your homeworks.
I don't buy the "normal this is so hard" argument. Look at the Full Framework, and all the breaking changes that have been introduced so elegantly between version 1 and version 4.6 (Lambda Expressions, Linq, async etc...). No public API broken for over a decade amid a frenetic IT world This wasn't less hard, but this was possible because the architects did their homework properly and got their ideal public API right.
Where are Lippert, Meijer etc ?
I'm been a fan of you and I love you guys, I just want you to react.
PS: I'm not one of those whose project has been screwed. I advise people to stick to 4.5 and EF6 since the beginning of this thing.
PS2: To reply to one of the commenter, yes they are many people whose main appeal for .NET Core comes from its ability to be ran on Linux. I personally don't care about the pay-as-you-use stuff, but I understand this decoupling actually enables cross-platform support.
As an idea, since I don't think many people will do resource critical dev with Core yet, they might consider decoupling behind the scenes, but postponing the performance tweaking APIs (load what you need etc) to a later point. This would provide the advantage of providing a neat API and streamlined install packages to help us forget the current mess.
This would also allow them to turn unstable APIs into implementation details for time being.
It's clearly not the chaos it looks like from the outside and you're still the best at building frameworks. The only issue was actually the RC label but these stuff happen - and unlike many companies it's the first time in decades you do the mistake as far as I can remember.
Great job and thanks for your efforts
We want MSFT to be successful in the worst way; however, it seems as if the technical debt has bitten them a lot in last 5 years with Windows 8 being the worst. All of this churn right now is killing even Visual Studio 2015, with NUGET restores failing, no MVC installation by default, Core 1.0 vs. ASP.NET 4.6 or 5.. It's just feels like a cluster out here trying to sift through it all.
Thanks for the post, and if we don't all move to MEAN in the mean-time; we are anxiously awaiting MSFT solutions. This despite the fact we've been kicked to the curb so many times in the past.
Maybe it's time for us to sell our MSFT?
Comments are closed.