An update on ASP.NET Core 1.0 RC2
Sponsored By
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:
- Acquisition
- How do you get the tool chain and shared runtime?
- Runtime
- The API used to find dependencies at runtime ILibraryManager
- The API used to find compilation assemblies at runtime ILibraryExporter
- Tooling
- 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.
https://channel9.msdn.com/Events/ASPNET-Events/ASPNET-Fall-Sessions/Class-Libraries
https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md 
Polish
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 .
More Performance
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
About Scott
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.
About Newsletter
Hosting By
April 14, 2016 11:09
It seems that it's more difficult to say when RC2 will come out but do you have any plan for the rls? (one month or five month?)
Ralph
Is it done yet? Ha ha... sorry, I can't help myself. This is no small task! You are basically writing the future for the next DECADE or so for every .NET developer. A few more months is not a big deal. Even 6 months? I personally would like to see organizations and corporations take a few more months trying to get things right. Otherwise, things are rushed and then you are left dealing with a product that no one likes and is ultimately broken.
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.
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.
Well, it may be delayed but the reality is it's one of those things you don't want to get wrong.
Do so, andyou're we're either forced to conform to breaking changes in another release a little further down the road, or make workarounds for the next 10 years, neither of which are particularly appealing.
As has been said in the wood trade for centuries - Measure twice, cut once!
Do so, and
As has been said in the wood trade for centuries - Measure twice, cut once!
I hate to be That Guy, but this is getting ridiculous. When was the last actual, production-quality ASP.NET release? In the time that's passed since then, the JS community has created and abandoned more web frameworks than the ASP.NET vNext team has tool chains. By the time ASP.NET vNext ships with templates using Grunt and Bower, the entirety of the rest of the web development community will be using totally different (and superior) tools. This is what happens when you don't do small, frequent, incremental releases. It's the .NET version of Windows Vista.
It's sad, but ASP.NET vNext has done more to drive me to Node.js than anything happening in the Node.js community.
It's sad, but ASP.NET vNext has done more to drive me to Node.js than anything happening in the Node.js community.
Dear That Guy,
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. :)
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. :)
I watched the last community standup (as I do most of them) and was nothing but smiles to see the progress made. Keep up the great work!
+1 @Vitoc
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.
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.
I don't know if I'm the only one, but as a library author, wrapping my head around all the recent changes has been kind of a nightmare. .NET Core, ASP.NET 5 (now ASP.NET Core 1.0), DNX (now CLI), UWP (now UAP), CoreCLR, .NET Native, netstandard, xproj/project.json...oy! Hard to keep up. I remember back when I found "old-school" PCLs a confusing. Now I have to try and make sense out of this matrix: http://docs.nuget.org/Create/TargetFrameworks
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. :)
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. :)
@Vitoc: I think you're missing something here. ASP.NET vNext is adopting those same immature tools and providing the same immature building blocks as the other frameworks out there today. It used to be that building on Microsoft's stack gave you a something stable, robust, and solid. That won't be the case anymore, and worse, by the time this is released, it will be built on top of tools and techniques that have already been abandoned.
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.
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.
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, I wasted hours in figuring out what was wrong, sometimes they replaced a Namespace, others you needed to add a new source in your Nugget configuration, other times they changed the signature of the methods, etc. but the last break was huge, sudently you needed to replace all your Microsoft.Aspnet libraries to Microsoft.Core, now you need to add a Main function, add more pollution to Project.json, change the way your hosting Works and the way it get parameters, for a RC type of Project is unnaceptable to have all those changes, obviously this got out of their hands, and now I'm not touching it until they get a real stable release, my test Project was almost finished and had security, logging, working with legacy assemblies figured out, now, I must throw everything and relearn other stuff, I'm really dissapointed.
Realizing that a lot of stuff has to be changed in RC1 is bad, but it's nothing compared to realizing it after RTM. I'm happy that the right steps are being taken to not make DNX hold the necessary progress back or spoil the foundation you're building.
@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.
@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.
Lots of changes, but I love where it's going. Keep going but don't delay RC2 visual studio tooling too much :), we want it.
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.
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.
I have to agree with Todd Menier here. The brandings and rebrandings and reversioning and name changes is really really confusing.
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.
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.
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. I still have not the slightest clue of what this all means for an application developer. Does it mean I now have to add assemblies and do run-time checks to see if a given feature exists or works the way I think it's supposed to? If so, that is an even worse solution than PCL.
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.
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.
Sounds interesting. I'll be looking forward to actually being able to use this one day, once libraries and tools catch up.
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.
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.
Here's an idea. Drop everything. Drop ASP.NET Core, drop .NET CLI, drop SQL Server for Linux, drop Ubuntu On Windows. Drop Windows! Drop everything.
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.
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.
@Ben
That's ridiculous. .NET has a great ecosystem and doesn't need JVM in order to be successful.
That's ridiculous. .NET has a great ecosystem and doesn't need JVM in order to be successful.
I totally agree with Matt Honeycutt. Shipping velocity is also super important.
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.
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.
Scott,
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.
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.
@Matt Honeycutt: "By the time ASP.NET vNext ships with templates using Grunt and Bower" - Did you try Asp.Net Core 1.0 RC1? Could you give us more details about superior tools then npm and gulp?
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.
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.
@Mason McGlothlin
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!
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!
+15 @Matt Honeycutt,
Well said.
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.
Well said.
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.
@Dave
Not a suprise and probably not a bad decision. Microsoft created Visual studio Code. It is written in Node.
Not a suprise and probably not a bad decision. Microsoft created Visual studio Code. It is written in Node.
@Stephen I understand the goals and it sounds well and good on paper; just not sure how it'll actually work out in practice as the implementation seems very complex. Again, I also still don't know the answer as to how this affects the **consumer** of the library.
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).
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).
Thanks for the update. Personally, I’m quite impressed with the transparent and responsive processes being used and I’m very happy with the rapid progress being made on .NET Core and related projects. I’m content to wait a little longer for things to be “done right” instead of having to live with less than ideal choices for many years to come. For all of my Java friends out there, I simply can’t resist…. “checked exceptions”. ;)
No problem. Take as much time as necessary. It's important to release high quality product because it's a platform. Platform have to be reliable and convenient.
@Matt Honeycutt:
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. ;)
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. ;)
That's great that we're in the top 10, but we should aim for top 5 or better! The best argument one can make for new people to adopt .NET is that it's a top performer. Top 10 (bottom of top 10) is probably not enough to convert a lot of folks. The top is still dominated by Java (closest to .NET) and when it comes to comparing the ecosystem, well, we're not in top 10. So let's go full force on performance and aim yet higher. We can do this!
Sorry, but this really just isn't good enough. Timelines need to be set and stuck to. Teams that made important decisions based on RC1 are being absolutely screwed around by the vagueness and massive changes.
This speaks to a lack of care.
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.
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. But that's the problem - the assumption I want to use Bower and grunt or gulp is already feeling antiquated... These things must now be re-evaluated, but they will not. We should not have run off chasing the latest frameworks of the moment - first Node, and now golang - but it's too late now as too much credibility is at stake. As much as I was inspired and energized by the announcement of vNext now, am just skeptical.
Where does this idea that people are mentioning about Asp.Net vNext is build on gulp and/or grunt come from? Is that because Visual Studio supports gulp and grunt? As far as I can tell if gulp and grunt die and people move to webpack or some other new thing, it will have no effect on Asp.net vNext.
Few months ago, when I started a new project, I look into ASP.NET 5 (now ASP.NET Core 1) vs ASP.NET 4.6 + MVC 5, and I made up my mind to wait until the first RC was to be released, because it was going to be the first "production ready" according to their own Roadmap.
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.
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.
As hanselman said a couple of months ago: ASP.NET IS DEAD!... well, time to move to node.js crap, sigh I really love C#
a nod of deep respect to Hanselman for posting this, on his personal web site, knowing that there would be some venting of frustrations.
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.
I am just wondering how these people still have their jobs. I won't have mine if I said to my technical manager that I can't give you an estimated project completion date.
Beside saying that, I do appreciate the work you have done already and the efforts you are putting into the project.
Beside saying that, I do appreciate the work you have done already and the efforts you are putting into the project.
I do agree with @Sean Hederman. Here's our situation. We migrated our old project to ASP.NET 5 RC1 and now we are close to our project release date and there are several bugs in the application. We cannot fix these bugs because of existing ASP.NET 5 RC1 and EF 7 RC1 bugs. We were wating for RC2 but only God knows when RC2 comes out (and of course with lots of changes). For some people it's normal to say "Oh yeah Microsoft, awesome, take your time and we will wait", they did not make our mistake to rely on ASP.NET Core.
The picture that shows the unification of the .NET Standard Library across all 3 domains (.NET Framework, .NET Core, and Xamarin) is outstanding news! Now, there are also opportunities for unification at the App Model layer: WPF, UWP, and Xamarin.Forms all use different dialects of XAML. Ideally, these XAML dialects should also be consolidated, such that the unification would be complete: common infrastructure at the bottom of the stack, .NET Standard Library at the middle of the stack, and XAML App Model at the top of the stack. One can also imagine that even ASP.NET and ASP.NET Core could replace HTML with XAML (sort of a Silverlight revival) via compilation to WebAssembly. Are there any thoughts being given to unifying XAML at the App Model layer?
Obviously there is a lot of pressure and expectation on the languages and other involved teams but Microsoft could do a lot better to communicate. There is still a fair bit of MS documentation citing DNX as though it is something with long-term-support. And then you can't get a list of what actually breaks in the RC2 apart from GitHub. This is well and good but placing this on Technet/MSDN/the more traditional places we've gone to for circulars could help especially for milestones like putting out an RC.
What would be the recommended way to host an asp.net core web application on a windows server (since it seems like you don't need iis for this anymore)?
Our project will start on 2 May with end of year deadline and we wonder if it's a good idea to use RC1 and migrate to RCx on the fly.
Thanks for the ongoing updates! Also, it was great to see my latest MSDN Channel 9 video on ASP .NET Core EF mentioned in your recent Community standup video! Thanks to Jon Galloway for bringing it up :-)
* ASP .NET Core EF: https://channel9.msdn.com/Blogs/DevRadio/DR1644
Shahed Chowdhuri, Sr. Technical Evangelist @ Microsoft
* ASP .NET Core EF: https://channel9.msdn.com/Blogs/DevRadio/DR1644
Shahed Chowdhuri, Sr. Technical Evangelist @ Microsoft
Talk all the time you need. I see no compelling reason to upgrade right now anyway. Particularly, considering Web Forms was dropped. But hey, at least we can use some crap editor like vim now and run on platforms that we didn't care about to begin with.
To all the people running a production app on a RC release, what were you thinking? You had to have the shiny and new didn't you? Consider it a lesson learned. I don't even see what you can't do with MVC 5 or even Web Forms that you can do with PRERELEASE software that is obviously nowhere near production ready. The EF 7 RC 1 doesn't even do JOINs properly. It does INNER JOINs for everything, even nullable fields. That should tell you that this isn't even a release candidate. I'm not even sure it's a beta. More like an alpha. Are there really people out there screaming to run their web apps on Linux? I think this is just to push people into running their apps in the cloud and the fact that Microsoft lost in mobile. Meanwhile, the people doing things old school are left out in the cold. No updates there because Microsoft is busy rewriting things from scratch. I used to think .NET was way ahead of Java. Now things are turning into a fiasco. There is too much reliance on the random trendy JavaScript tool of the week. This isn't productive. Things are not getting better. They are getting worse. It is starting to look like anarchy. We are now getting into the version hell that exists on Java with Maven. Simpler is better. Things aren't getting simpler, they are getting more complicated.
@Leo With regard to using XAML for developing web apps. Microsoft is going in the other direction. What is trendy is programming at the bare metal-level with HTTP. You're not cool unless you do that. Next we will be programming at the TCP-level and abandon using an HTTP stack. Microsoft can boost their benchmarks further when they do that. Then we can implement our own TCP/IP stack and write everything in assembler. After that, we can use carrier pidgeon and switch to using message in a bottle on paper.
@Amine
Of course not. Stay with .NET 4.6 for the next 6 months if you still want to stay with .Net
Of course not. Stay with .NET 4.6 for the next 6 months if you still want to stay with .Net
This is both an exciting and frustrating time for the 'dark matter developer' (to coin a term introduced by yourself Scott :) ).
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.
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.
Re-reading my post I realise it may sound a bit overly cynical- I do think these are incredibly exciting times and kudos for the effort that is put into this.
I'm thinking the Xamarin acquisition probably threw some kinks into the machine. Just ship it when it's right.
A lot of reactions to some things that people aren't fully grasping. It's easy to tell when someone has grown complacent with one tool/language/paradigm.
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.
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.
Seems that RC2 will enable the experience Scott described here: http://www.hanselman.com/blog/ExploringTheNewNETDotnetCommandLineInterfaceCLI.aspx
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.
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.
My question that I still can't seem to figure out is why the hell would some of you people start a new project on something in RC status? Dude I'm sorry but I'd tell my manager we should hold off at all possible until some concrete stability comes in. Or stick with .NET 4.6 - I am a Java developer/sysadmin but I got started with .NET back a few years ago so I always like to check in on how things are going and I have been really impressed by a lot of things that Microsoft has been doing recently to some extent. I'm like .NET core and have been playing with it all day (and over the past few months) but man it's not ready to be placed into an Enterprise grade project. No way. You're looking at 6 months to a year. Go ahead and get a POC propped up in your staging environment and tweak at it every so often or something.
An answer to questions about why people are using an RC product: We've done the same. The general idea is that .NET Core is obviously the future technology (I compare it to MVC1 and Webforms a few years back), and when RC1 was first released, we expected no major changes going forward, especially given the go-live licence. We also expected RTM to come soon, since an RC release implies it's only bug fixes that's coming. If we had gone with the ASP.NET 4.x stack, we would have to convert to ASP.NET Core eventually, and we figured this should be done sooner rather than later. Besides, moving from Core RC1 to RC2 to RTM would, one would expect, be easier than moving from 4.x to Core. The philosophy behind .NET Core is really exciting and we love where it's going. It also enables us to eventually attract non-.NET devs who would scoff at the idea of giving up their Macs (we're counting the days till we get Jetbrains Rider).
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.
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.
Are there plans on moving to JSPM or are we still sticking with Bower?
I wish I can try ASP.NET Core but there's no installer for OpenSuse. I checked on https://github.com/dotnet/cli. Is this product for Win, Mac, RH and Ubuntu only? Thanks.
1. There have been like 9 small incremental completely use-able releases .. despite this project being 10* the size of the small js libs that keep rolling.
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 .
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 .
XAML in webapps would be great addition. There are many people asking for web development using XAML and Webassembly (like silverlight without plugin) not sure if Microsoft is listening that developers liked that silverlight model and that HTML/JS is a big pain in the ass compared to c#/XAML.
So the thread in a nutshell:
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.
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.
The web moves way too fast these days. But does it really have to?
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.
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.
Dear Scott,
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.
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.
@Martin No, they are not listening. They are just trying to copy Google. Google releases 10 million new versions of Chrome a day. So, Microsoft, Mozilla, etc. feel the need to do the same. As you can see by all the new web stuff that Microsoft is releasing, they are overcompensating trying to appeal to developers using Linux, Angular, Ruby On Rails, etc. rather than creating their own innovations. As far as I'm concerned Web Forms is much better than MVC. MVC is just a copy of Ruby On Rails. Were there things that RoR did that should have been copied, like improvements to EF. Of course, but, that doesn't mean you have completely scrap something that had it's own benefits. Now, even Ruby On Rails is out of date and unless you are writing SPA applications you are uncool and need to be fired immediately (according to the cool kids). I have a question for the people that are so pro MVC. What kind of UI are you developing? LOB applications? Things like Bootstrap are a complete fiasco if you ask me. Web Forms may have issues such as view state, but, it is not an issue for a lot of applications. IMHO, it is vastly superior MVC. Especially if you are using UI controls like Telerik's. A lack of UI controls in MVC is an epic fail. MVC isn't the end all be all solution for everything. Unfortunately, Microsoft doesn't understand this and hence why they aren't moving Web Forms forward. Microsoft, you really need to get back to innovating and advance the state of web programming rather than just copying what other open source projects are doing. If you are so in love with MVC Microsoft, why don't you have a look at JavaServer Faces. It uses MVC and still has the concept of UI controls. I'm getting sick of the people who apparently have attention deficit disorder and move from one shiny toy to the next. Do you develop useful software in between constantly switching from one fad to the next?
Mongo C# driver is now waiting for this! , longer it takes the more are the chances criticism is waiting for this release candidate the moment the curtain uplifts. I guess MS knows what happens to stage performers if they arrive late ?
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
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
Hi Scott,
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.
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.
@Alexander Trauz - Do any of the people here complaining actually think they can go 2 years in the industry without learning something new?
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.
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.
@Jim not sure why till now you still want to bring up the war between MVC vs webform, still replying too much on UI control like Telerik to develop web apps. I myself came from the webform background 1.0+ and after I tried mvc 3.0, I wouldn't look back since then. Bootstrap, Semantic ui, google modern UI or any javascript/css UI frameworks... is the way to go, they have tons of features and welcome everyone to join in easily, free to use and free to change. JavaScript's become the main stream in our world of developing apps, why would you want to stick with the old closed system like webform/telerik ?
Even bootstrap have tons of 3rd party themes like https://almsaeedstudio.com/ , what else would you want ?
Sorry for my English, just my 2cents :)
Even bootstrap have tons of 3rd party themes like https://almsaeedstudio.com/ , what else would you want ?
Sorry for my English, just my 2cents :)
@Nam Vo - why would you want to stick with the old closed system like webform ... ?
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.
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.
Cowboy coding in the initial phases of a project (instead of always having the code base releasable), and then throwing things away when the RTM comes closer, it's like Vista all over again. Didn't you learn anything from that?
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.
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.
Will there be anyone left on the ASP.NET platform by time your done? In the non-enterprise world I saw some initial interest in this but it died months ago. People are moving in droves to GoLang and Scala
Working on a greenfield project.
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.
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.
OK, a little clarification - it worked fine on another system of mine. no idea why... :(
Hi, Nice update on Asp.net Core 1.0 RC2. Here describes about why RC2 is taking so long over RC1 and what's going to happen between now and the final release? I read it thoroughly. Here in this blog so much useful information available to know. I had a little bit idea about Asp.net when I hosted my business through Myasp.net. Thanks a lot for sharing with us.
JavaScript is and will always be a steaming pile as far as I'm concerned. A total train wreck. Same thing for Angular, et al. I have no interest in using any of this garbage. Just a repeat of C++. Trying to fix something that was broken to begin with with a bunch of band aids.
Really interesting on asp .net article, let me bookmark it and also share with my friends
what is the difference bewteen the CLI you refered in article(new .net core reuntime?) and the CLI(.NET Command Line Interface)
I hate to say that but you are screwing it guys... I don't mind the delays, I'm talking about the lack of stability.
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.
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.
Just watched the Community Standup and after learning about your process I just wanted to mention for the record that my concerns are cleared ;)
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
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
Scott;
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?
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.