When I use a Visual Studio 2015 template to create a brand-new ASP.NET Core project, I see a couple of unexpected pieces. I'd like to understand these:
By default, the new project targets dnxcore50 and dnx451. I thought ASP.NET 5 / MVC 6 required .net 4.6, so I don't know why dnx451 is one of the default targets.
Regardless of dnx target, the startup.cs file specifies app.UseIISPlatformHandler. I've been running the dnxcore50 target in Docker (i.e. Linux) without any problem, even though Linux does not have IIS. So I don't know what UseIISPlatformHandler does. I can find no documentation for it either.
Can anyone clarify?
Why dnx451 instead of dnx46 is basically IIS's fault, see answer here. Also perhaps the templates run behind because Azure has not yet switched to 4.6? Just a little theory of mine. I'm not sure.
UseIISPatformHandler is again only used for IIS. You can savely remove it if you have no interest in publishing your web app to IIS. You can learn more about the HTTP Platform Handler (which IIS needs) here. And you can learn more about the IIS Platform Handler Middleware from the source code.
Does this make it more clear?
Related
Can anyone help as to how to use the run time binaries found in the link below?
https://www.microsoft.com/net/download/windows
Basically, we are moving to .NET Core (we have been using .NET framework 4.0 for many years - so big shift as you can guess). I am kind of nervous to install .NET core on the production server (Windows Server 2012). Is it safe to install .NET Core on a server running .NET framework 4.0? If no, is there any way I can get the .NET Core runtime on to the server without installing them (kind of copying portal libraries) so that I can start with the beta testing of the app. Any help would be much appreciated. Thanks!
EDIT:
It is not duplicate, One of the main questions I had if I can use portable binaries on the server to run my app, without actually installing them (got the answer below, thanks again). Not sure someone down voted this without any reason. It makes the developers nervous to ask a question in StackOverflow. if they can mention the reason that would be great!
There are no issues when installing .NET Core and .NET Framework on the same machine. They are designed to allow them to be installed side-by-side.
However you do need to install the .NET Core runtime onto the server to allow the code to be run because the OS has native dependencies that need to be present. See this link for more information.
With .NET Core you can do framework dependent deployments (FDD) and self-contained deployments (SCD). FDD requires any shared assemblies to be present on the server i.e. System.* assemblies etc. but an SCD only requires the basic runtime/native dependencies. For an SCD your app deployment would include any .NET Core shared assemblies in it's deployment package.
You can read more about FDD and SCD here
Also there is more information about the native dependencies on different OS platforms here
I have recently started learning ASP.NET Core with the help of an ebook. There are few statements mentioned in the initial chapters, which I am unable to understand clearly.
For eg. following statements are mentioned under Foundational improvements in ASP.NET Core section
Lightweight and modular HTTP request pipeline
Ships entirely as NuGet packages including the runtime
Runtime can be installed Side-by-side- allows you to version application along with runime
The above statements are not clear to me probably because of the term "modular HTTP request pipeline" from Point 1 and terms "runtime" and "version application" from Point 2.
Any short explanation or reference to the suitable doc will be appreciated.
Thanks
http request pipeline
They totally rebuild the HttpListener which is also called the http server. Normally you would host your application in iis which would give you tons of functions but is 1 very old, massive sluggish application.
Now on default you run the application as a console which starts up a HttpListener which is called Kestrel in dotnet core.
This kestrel is totally build from the ground up (so modular priciples and barely any technical depth). And is build based on a very vast C++ library called libuv.
The modularity in this means that it has been build in various loosly coupled parts, meaning that you could replace or extend those parts if you want to. For example use a test server for automatic integration tests.
Ships in nuget packages
Normally you would install a netFramework eg: 4.5.0 and you would already get all these system.* dlls eg: System.web.dll
Now all these dll's are nuget packages and bundled into 1 package called netstandard: https://www.nuget.org/packages/NETStandard.Library/.
Multiple runtimes
If you build a dotnet project, it creates Dlls. these dlls can be run by by any OS if that os has installed the dotnet runtime. (basicaly dll is intermediate language and can be run by the dotnet runtime).
You can also build your dotnet project to include the runtime inside your application, so you can run multiple dotnet applications on an OS with different Dotnet runtime versions.
The downside of this last option is that you have to build your dotnet project for every OS specifically. So normally people choose to just build the OS independent Dlls and make sure the right runtime is installed on the OS.
Using Visual Studio 2017 (RC), I am trying to setup a project that uses ASP.NET Core, but with the .NET 4.6.2 library.
This is a supported configuration:
Visual Studio will then create a default project; but it doesn't run:
This is without changing a single line in the project: the VC2017 template just does not work.
I tried the following:
- Different versions of the .NET framework
- x86, x64, AnyCPU
- Clear the NuGet cache
- 'Repair' options on Visual Studio's installer.
My understanding is that the error is a x86/x64 mismatch. But since I didn't change a single file from the template, there has to be something else wrong.
Installing ASP.NET Core on .NET Core works perfectly, so the problem is limited to using the regular .NET framework.
Any ideas?
I have the same problem too. But I just found the solution.
In ".csproj" I change some things:
<PropertyGroup>
<TargetFramework>net462</TargetFramework>
<!--<RuntimeIdentifier>win7-x86</RuntimeIdentifier>-->
<RuntimeIdentifier>win10-x64</RuntimeIdentifier></PropertyGroup>
And I enable the 64-bit version of IIS Express.
I had problems like these when I restored stuff to a new laptop.
I mindlessly I copied files from my old profile directory to a directory with the same name, but that isn’t a profile directory on the new machine.
A part of this process involved a cloud backup service that my wife bought for me but that I never actually set up right. That also copied files to new locations without my paying attention to what was happening.
I still don’t know (yet) exactly how the machine keeps track of which versions of frameworks and tools to use in the various application directories, but I can report what I did that finally allowed me to create new .NET Core apps on the new machine.
I deleted everything in this directory that was older than today.
%USERPROFILE%.nuget\packages
Again, pretty mindless. I don’t know, (yet) if all that was necessary. Maybe just deleting one or two of the files/directories would have worked. Regardless, I was very happy to see that I could create and develop .NET Core apps on my new machine.
I'd like to (try to) add HTTP/2 support to Kestrel - for my own edification, for now. I'm using Ubuntu as my dev platform, because my requirements include using Linux.
Of course, it appears fairly simple to make changes to the Kestrel code - just clone the source from https://github.com/aspnet/KestrelHttpServer, then make my changes, then build the assembly. The problem I'm having, is getting other code to reference my modified code/assembly rather than the "official" assembly from .NET Core. To that end, I would love to hear how to do the following:
"Install" my changed Kestrel assembly locally such that anything that depends on that assembly uses my changes automatically. This may include projects that I create via dotnet new -t web, as well as other .NET Core assemblies that I haven't modified.
Be able to propagate my changes to other machines as necessary, in a controlled manner.
Thank you, and have a good one!
There are 2 options
create own nuget package from sources using dotnet pack command, and then use own feed for nuget restore. See related SO answer and Hosting your own nuget feed guide;
or
add Kestrel project into your solution and add dependency as "project reference".
I have an application that consists of a client-side application and a WebApi website.
My client-side stuff is targetting .NET 4 so that I don't have to insist that users install .NET 4.5. My website, however, is entirely under my control, so I'm targetting .NET 4.5.
There is one shared assembly, which I use for data access. It uses Entity Framework 5.
When I build the client application, the DLL used is version 4.4.xxx, whereas when I build the web application, the DLL is 5.0.xxx.
Up until now, I've been able to run the client application with no problems, and I've also been able to run the web application, again without problems.
However, I've now re-created my web application project from scratch (*), and suddenly I can't run it. I get a YSOD saying "Could not load file or assembly 'EntityFramework, Version=4.4.0.0 ..." at the point where my data-access assembly is first invoked.
Now, it's perfectly clear what that error means - it can't find the v4.4 DLL as used by the data-access assembly - but I don't understand why that's a problem with my new project when it wasn't a problem with my old project. As far as I can see, the same DLLs are referenced in each project.
(*) I should explain why I'm re-creating my project. I originally created the project in VS 2012 RC, and then later upgraded to the release version. Although this supposedly upgraded my project, I've had a few problems with it, and have also noticed some differences v. a newly-created project. So, to be on the safe side - and hopefully circumvent those other problems - I'm re-creating it from scratch.
So, my question: why is this suddenly a problem, and what can I do to resolve it?
Is the code depending on the assemblies set to require the exact version? If so, you will need a publisher policy for the EntityFramework assembly or bindingRedirect for the referencing application (web project).