.NET Core strategy is good, but the implementation is totally wrong #1432
Comments
how would you know which dependencies to fetch from NuGet if you don't specify it somewhere?
the upcoming netstandard solves that for libraries IMO. MVC is a different product so it has to be managed differently.
Kestrel is based on libuv which is also used in node.js. Kestrel itself has the same maturity level as ASP.NET - both will be V1 products. So the decision is up to you whether you generally want to use V1 products.
AFAIK there will be (or maybe already is - I'm not sure) a way to install a predefined set of .NET Core assemblies on a server. dotnet/cli is the place to look for that.
check cli-samples for minimal samples. |
I'll ask the reverse question. Let's say you have a server with 20 web apps hosted on it developed at a different time. You want to create an app with the latest framework. The last deployment model followed the one you mentioned. One global framework. Issue? The last framework has lots of changes and you don't want to re-test all the 20 other apps to see if something broke. Your company doesn't have the budget to do that. This new model will allow you to just ship the framework with the apps. Space is cheap. Managing multiple frameworks is expensive. |
You don't NEED Kestrel. It's just that for V1 it's the only one you have. As for sample configurations, there is already requests to have those. If yours isn't there, please do open an issue. Nginx: #1170 |
Proper documentation and tutorials are currently missing. Not surprising. Everyone has been focused on either delivering RC2 or waiting for the RC2 before doing anything major. This will come in time but the main solution is going to be plenty of templates. Dependency injection takes 5 minutes to explain in person. One good article when you are online. |
Compared to what? NodeJS has package version, runtime version, and flags on which to run. Java has runtime version, framework versions (Sparks/Grails/etc...) and JAR versions. Let's face it. You have multiple parts. You have a runtime, you have a framework and then you have packages. Am I missing something? Please correct me if I'm wrong. If other frameworks are making it implicit, I'd rather have it explicit. Less chance to find out that you were trying to run new packages on an outdated runtime or have to copy/paste dependencies or my app just assume that it knows better. Every framework is going to run into those issues. Runtime version. Framework version. Package version. |
And that assumes that you only have one runtime and one framework and that your runtime is managing those dependencies by whether they exist in a specified path or not. Packages are managed by Nuget which they are going to install in a standard location. Easier to deploy and easier to maintain. Those packages are zipped and extracted at a location on disk which are then going to be able to be picked up by .NET Core and loaded up. The runtime will be included in PATH to be sure that we can run As for knowing which version of AspNet.MVC? What about upgrading the framework? You need to specify it somewhere if you want to upgrade it. No? |
|
I want to use .Net Core as simple as possible. I think that .Net Core should be a simple zip file with all first party libs (Mvc, StaticFiles, Razor, …). I don’t care which version is MVC or Razor. Next step is to extract the framework somewhere on my server and to say to my app to use it (NET_CORE_HOME="path_to_some_version_of_net_core"). That’s it. No package version, no framework versions (dnxcore50), no global framework. With this solution I can VERY easily test my app with every version of .Net Core. No one ships it’s framework with the apps. See PHP or Java or Python or Perl? No one. You will be the first (and the last). About the Kestrel. For me it is useless, because it could not be used in production. It does not have security, load balancing... A better approach is to be developed modules for other web servers (like PHP has done for Apache). About the development process: Let’s see what we have in one simple web application in .Net Core: 1. Dependency injection. 2. MVC as framework. 3. Adding/configuring services. 4. Lambda expressions. You can’t explain them for 5 minutes. The beginner has to know all this in order to test something. In PHP you just start working on your project. I ask again. What would the beginner prefer? I think that Nuget should be a simple package manager for importing third party libs to my project, not to the .Net Core. Nuget should download a lib, installs it somewhere relative to my project and makes some configuration work (in project.json). That’s it. Why did you make .Net Core to depend so much from Nuget. What if I don’t want to use it. |
Now you don't. Until you want the next version. A user shouldn't have to upgrade framework if it just wants the next version of the web tools. It's why they are there. They are shipped outside the actual runtime. They are a package with their own release cycle.
True. As mentioned before, optimizations will be in place. My bet? It will simplify deployment and you are literally the first person I hear that complaint about that specific feature.
It's meant to host the app but not to be a production web server. Even in the Windows world, we are not exposing Kestrel directly to the web. IIS will take care of that. On your end? You should use NGINX to secure your front-end.
You are confusing some concept. 1 and 3 is dependency injection which is your initial point. Now you are adding MVC which is pretty similar to what is already existing. It's easy to ramp up and easy to understand. Point 4 is about C# not ASP.NET Core. Is your point still valid for nodejs functions, Java arrow methods? Because they are very similar. ASP.NET Core with the starter template? I can get a student up and running within the hour and have him productive and create APIs backed by database within a day of work.
What do you want to use instead? Copy/pasting of dependencies is prone to error and people never update them once they are included. That is a security risk. What do you recommend? |
|
I don't know where this "kestrel cannot be used in production" comes from, since beta8 I guess it is how you run a .net core app. As far as I know, the team is committed to make kestrel a first class citizen in the modern web. However kestrel is very node alike. It is not meant to be a general purpose web server. For that matter you can use IIS, Nginx or Apache to front your kestrel exactly as you would do with node. This is just separation of concerns. |
|
I think the questions fundamentally misses the point of what .NET Core and ASP.NET Core are. There are many similarities in .NET Core to the way Ruby and Node works, for example. I recommend @nikigter invest some time to understand how these technologies all work, these questions are answered in detail in the docs, videos, etc. I don't see a point to discuss this all over again. |
|
I agree with @giggio. And since we're so close to RC2 and a month away from RTM, I suggest we close this issue. Nice discussion but "implementation is totally wrong" cannot be resolved. Everything mentioned can be flagged as "by design". |
|
Please, don’t understand me wrong, but the model where you ship the framework with the apps and that packages are managed by Nuget is not good. If you compare a development and installation process of a Web application written in PHP and .Net Core the winner will be definitely PHP:
I think that projects in .Net Core are more difficult and expensive to maintain. A lot of small and middle companies are not going to use it. That’s it. Niki P.S. |
|
Comparing a new model in pre-release candidate to a legacy programming language that is rooted in completely unrelated technology doesn't seem like the best correlation of usefulness. |
|
@ciel maybe you are right. But. The more I deep drive into .Net Core the more I realize that for the asp team will be very difficult (or impossible) to convince web developers to use it as a primary development framework. |
|
http://blog.codinghorror.com/php-sucks-but-it-doesnt-matter/ Jeff Atwood (stackoverflow) seems to disagree with you, and I trust his judgement a great deal more. .NET core doesn't need to convince programmers of anything. It's not complicated or difficult. Everything you outline as a con is just the usual stress of edge development. You see exposed nerves because you're working on internals and guts. The final product will have 0 of that. Even package management will be a non-issue. You claim that "the more you dive into .NET Core, the more it will be hard to convince people to use" - what? Are you truly looking at .NET Core, or are you just looking at the adoption difficulties present because you're on edge builds. The process couldn't be easier. You have the .NET Runtime/CLI. You create a All of the friction you cite is because it's internal machinations of being on the bleeding edge. Literally none of that will exist going forward though. NuGet was the greatest thing to ever happen to the .NET Ecosystem and it's been a great, great success. Now we have the power of You try to compare it to php, but that's like stacking a Great Dane next to a Chihuahua and calling them even. They're not even trying to solve the same problems. (In the sake of fairness, I consider .NET to be the chihuahua because I freaking love chihuahuas) |
|
@ciel in the last post I pointed PHP only as a sample. That’s true for every other. Let’s say you have 10 different simple projects for processing log files. In other languages (not only in PHP) you would have 10 source files. In .Net Core there would be 7130 files and 8420 folders because of the frameworks! Correct me if I am wrong. Guess what would be the customer’s reaction and decision when he sees so many files and folders on his server. He doesn’t care that the asp team has created the best ever development framework and how simple it is to work with it. @MaximRouiller I don’t see here simplicity. The problem is that you are talking about only from the development’s point of view. See how the final .Net Core project looks like from the customer’s point of view. |
.NET Core projects don't output anything more than traditional .NET Projects. They output the binaries needed to run, and the executable program or a library that can run with the .NET CLI. Except now you don't have to say "For Windows Only". .NET is established, growing, and popular. You couldn't be further from the mark. On May 16, 2016 1:01 AM, "nikigter" notifications@github.com wrote:
|
|
Alright... if I remember correctly... multiple runtimes can be installed on the machine. Meaning multiple frameworks. That also mean a different amount of packages. All of those being centralized. If I said anything different than that, I'm sorry. I was talking on the point of view of an older beta. But now, everything is centralized. Multiple apps with different runtimes will need a server with all those runtimes installed (including their packages). Yes, it's a lot of files. But let project ourselves 5 years in the future. It will allow an insane amount of variation on a single server. Need to host 25 applications each built slightly differently on 5 different version of the framework? You only need a server with those 5 runtimes installed. From my client's point of view? I don't need to pay to have regression testing on those 25 applications. I don't need to have IT guys testing multiple frameworks install to ensure that nothing was broken. My client is saving money. My client won't care that I use a tad more HD space. He will care that he doesn't have to spawn 5 different VMs (one per runtime) just to ensure nothing was broken. That my friend, is value. |
|
Multiple apps won't need different servers. Packages and runtimes are project-local, not machine-local. You don't need your targeted files in the GAC anymore. There is no regression testing needed, and there is literally nothing about the .NET Core strategy that is like you're claiming. Your application has a folder. Inside of it are the dependencies. It's really that simple. Why would you need your IT staff to test multiple frameworks? Just because you can write cross-platform doesn't mean you have to. Make your application and target a platform, then market it for that platform. You simply have options other than 'Windows' now. You have to do all that testing in php too, you know. php treats Windows servers very differently than Apache servers. I feel like your argument is grasping at straws and pretty uninformed. Have you actually built and run a .NET Core application? I think you might be confused because of early RC1 friction. Why in the world would one client be running your application in 5 places, on 5 different platforms? That's such a convoluted strawman argument I can't even think of a rebuttal. That will literally never happen. |
|
@ciel I was talking in past experience of hosting .NET servers for clients. If you are to upgrade a framework, you'll need to ensure that nothing is broken in either your application you developed for your client or for anything you bought from different vendors. So any upgrade to an existing machine is a pain. The new model solves that. I've never talked about running PHP. ;-) I've built the apps. I haven't had anything running in the past few months so... yeah. Memory fades and my grasp on some things might be off a bit. Not 5 places in 5 platforms. One server. 25 web apps built a different time with different runtime requirements. That is very common. Yet again, ASP.NET Core solves that issue. |
|
If we're running a containerised microservices architecture, where you redeploy apps instead of updating them, why would you have so much technical debt in the form of different runtime environments? Aren't we moving rapidly away from this monolithic model that requires we support multiple runtime versions? One runtime, agile microservices, containers. Hopefully, we will be able to deploy .net core using a range of package managers, including apt, yum, snappy, docker. And, be able to use PostgreSQL with NGINX and a host of other apps in our open source stacks. Maybe we want to use BuildRoot to create a 10MB linux OS to run in a Docker container (or Rkt, or LXD) that has all the components we need just to run our app. Add .net core to that tiny container and you've got something quite different to the typical .net environment running under Windows. Deploy your C# app into that and be ready to destroy the container when you want to update the code. One container, one runtime, one app, one version instance. Or, in the case of LXD (a full system container): one container, one runtime, one app stack, one version instance. It's an entirely new world for .net on Linux. |
|
@nikigter You are comparing pho 'echo "hello" vs whole modern web framework asp.net core. Maybe try to compare it to zend or simphony php framework, then you will understand that .net core is amazing and very productive. |
|
Sorry to revive a dead thread but this has to be said on top of all this (for people who happen across this thread it may be helpful). The OP is making comparisons between a framework (.net core and asp.net core) against languages (PHP is the main example used here). In PHP you could also use frameworks such as laravel and get just as many files and "complications", just as you can use one or two files to create a base c# application. Do not confuse the two when making comparisons, it's somewhat like apples and pairs. |
- Kestrel binds to ipv4 by default Fixes #1432
ghost
locked as resolved and limited conversation to collaborators
HI asp.net team,
I looked at the Web Application from ASP.NET 5 Templates and watched some videos about .NET Core and honestly I am disappointed. I think that your implementation of ASP for multiplatform is wrong. You did not look at how others (like Java or PHP) have solved the multiplatform development.
Niki
The text was updated successfully, but these errors were encountered: