I'm exploring Core MVC 1.0.
Is it possible to use Azure nuget packages I've been using in the past in previous Web API projects? For example, I've been using Microsoft.Azure.Mobile.Server.Notifications which gives me extension methods on HttpConfiguration that I can use in my controllers like:
var pushClient = Configuration.GetPushClient();
But I understand HttpConfiguration no longer exists.
Is there any way to use Azure packages like this with MVC controllers, or should I just be waiting until they release versions that target .net core? If so, are they even working on this? I can find anything anywhere.
Technically you can work with ASP.NET Core packages targetting the Full Framework too. We have several apps that are targetting netcoreapp and others targetting net461 due to Azure packages, but both use ASP.NET Core packages. Of course, this is valid if your environment has the Full Framework (Azure App Service does).
You can see how both the netcoreapp and net46 versions go related to NetStandard here.
To achieve this, remove the Microsoft.NETCore.App from the dependencies and change netcoreapp1.0 to net461 on your frameworks declaration.
When the NetCore-compatible packages go live, just reverse the change and your app will keep working.
With regard to the Mobile Apps Server SDK support for ASP.NET Core, the work is on our backlog, but we don't have a timeline to share. This is partly because some of the dependencies (such as Asp.NET OData and OData) don't yet support ASP.NET Core.
In the meantime, you could try #matias-quaranta's answer for how to use both together.
Related
We build our web app with Azure DevOps pipelines and deploy into Azure with an Azure DevOps release. I think today netcore got updated to netcore 3.1.4 on our build agent. But now our Azure DevOps deployment fails, because the netcore 3.1.4 runtime is not yet installed on our app service in Azure.
The error message we are getting:
Could not find 'aspnetcorev2_inprocess.dll'. Exception message:
It was not possible to find any compatible framework version
The framework 'Microsoft.AspNetCore.App', version '3.1.4' was not found.
- The following frameworks were found:
2.2.8 at [D:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
3.0.3 at [D:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
3.1.1 at [D:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
3.1.3 at [D:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
You can resolve the problem by installing the specified framework and/or SDK.
This makes sense and can happen, but what is the best way to go about fixing this?
I could fix my build to a specific netcore version. But I don't like this, because we do want to keep updating to newer versions, but we don't want a version that is not available in Azure app service.
Am I correct in thinking that we would have to install our services self contained, because otherwise we could get into this issue more often when Azure DevOps is faster with installing patches than Azure?
Or is there a way to force update Azure app service to the new netcore 3.1.4 security patch which would be ideal I think?
I just need some guidance in what is the best approach to fix this issue?
Or is there a way to force update Azure app service to the new netcore 3.1.4 security patch which would be ideal I think?
AFAIK, there is no such a way to force update Azure app service to the new netcore 3.1.4.
We could keep track on the latest releases on the https://aspnetcoreon.azurewebsites.net/, but we could not update it at this moment.
To resolve this issue, we recommend that you publish your app as self-contained produces an application, which includes the .NET Core runtime and libraries, and your application and its dependencies. Users of the application can run it on a machine that doesn't have the .NET Core runtime installed.
Publishing your app as self-contained produces a platform-specific executable. The output publishing folder contains all components of the app, including the .NET Core libraries and target runtime. The app is isolated from other .NET Core apps and doesn't use a locally installed shared runtime. The user of your app isn't required to download and install .NET Core.
You could check this document .NET Core application publishing overview for some more details.
Hope this helps.
If you want version of netcore to be automatically updated as an updated version is available, building our service as self-container seems like a good option: no need to have anything installed on the machine running (ie the version on Azure DevOps and Azure Web App don't have to match).
The main downside of this approach is that the build is going to less deterministic: running your build twice with on the same commit might create different binaries depending on what is currently install on the build agent. if you want to know more, here is an interesting post arguing about why deterministic build is important.
To keep the build determinitic, you can use the Use .Net Core task at the beginning of the build (that will make sure that the desired version of the dotnet sdk is on the agent). You could also add a global.json in your repository to lock for both the build on your dev box and in Azure Dev Ops.
This is a common topic of discussion, and you can find a lot of blogs advocating one or another side.
There were big discussions started when Microsoft released LTS net core 3.1 and it took some time before Azure start supporting the 3.1 runtime as well.
You could find a lot of blogs strongly suggesting to deploy your web apps as self-contained (runtime is ~100MB in size) and cut loose the dependency towards Microsoft supporting the latest runtime. While others advocate that the applications should remain as light weight as possible and the runtime should be set in the pipeline. But that is still up on you. I, myself prefer to deploy self-contained apps after my bad experience with net-core 3.1.
There is no established best practice.
In the past , I've run into the same situation, you can fix this by manually setting the value from RunTime Stack drop down. If you manually update the build processes .yml file
RuntimeStack: 'DOTNETCORE|3.1'
I new to .NET Core and our IIS configuration is as so. We run a single web site with about 70 .NET 4+ applications under it, each app runs under is own user and app pool. Our developers have requested .NET Core to begin upgrading applications.
The site is not accessible, only the applications. The applications do not inherit from the site web.config (which is generic) they pull from their own.
Would it be better to upgrade the site to .NET Core and then upgrade the apps, or leave the site at .NET 4 and upgrade the apps to .NET Core?
Use Net Standard, you should be able to use code across all projects.. Ensure your Net Framework projects are on the latest version and you should be fine. I believe you use code from Net Core projects in Framework, but not the other way round
It looks like there are no libraries provided in .net standard / .net core to support MSMQ.
In that case, how can we use MSMQ while working with asp.net core 2.0 and above web application?
I recently noticed this NUGET package: Experimental.System.Messaging
I've not yet tried it but it seems like it might be helpful for what you need.
Since Microsoft has released .NET Core 2.0 for Azure Functions a few days ago, I'm trying to understand how to create a new Functions project in VS2017 targeting .NET Core.
I've tried many configurations and still ended up with .NET 4.7.
Did anyone manage to create a new Function targeting .NET Core?
Thanks.
This is supported with the 1.0.5 release of the Microsoft.NET.Sdk.Functions package.
In your Azure Functions Project, do the following:
Update the Microsoft.NET.Sdk.Functions package version to 1.0.5
Right click on your project, click the Edit <projectname>.csproj option and modify the TargetFramework element value to netstandard2.0
This will should generate .NET Standard 2.0 assemblies with all the artifacts created by the Azure Functions tooling.
As of today I have been able to target .Net Standard 2.0 in a "reasonably" intuitive way and without editing any .csproj files.
You need a reasonably recent version of Visual Studio. I'm using Visual Studio Professional 15.5.3 (although I would guess that community would work).
You need to have the Azure development workload installed. This will install an extension called Azure Functions and Web Jobs Tools.
So far so plain vanilla. There were 2 additional bits that were to me not at all intuitive but ended up being very easy to do - easy when you know how!
You need to make sure that the Azure Functions and Web Jobs Tool is 15.0.31114.0 or greater - that's when they added .net core 2.0 support (see https://github.com/Azure/Azure-Functions/blob/master/VS-AzureTools-ReleaseNotes.md). You can update this using Tools/Extensions and Updates, or see https://marketplace.visualstudio.com/items?itemName=VisualStudioWebandAzureTools.AzureFunctionsandWebJobsTools
Even when you've done that, Visual Studio is a tiny bit weird about letting you create Azure Functions that target .net 2.0. When you go File/New Project, nothing has changed in the list of available project types, and if you select Azure Functions, the list of Frameworks just shows .NET Framework *, no .NET Standard, no .NET Core.
But if at this point you persevere and select Azure Functions, you then get a new dialog I hadn't seen before, which allows you to select Azure Functions v2 Preview (.NET Core).
Now, when I then look at the project properties, it turns out it is targeting .NET Standard 2.0, which in turn seems to contain Microsfot.NETCore.Platforms (1.1.0). So is this .net core 2.0 or not? Not quite sure but its' good enough for my purposes so now going to tuck into some coding.
Cheers!
For now, it's a manual process. You need to create .NET Standard 2.0 library, add function.json manually and run it with core tools.
the package Microsoft.NET.Sdk.Functions does not yet support .NET Standard 2.0 class libraries. This is the package that identifies a project as Functions project to Visual Studio and generates function.json from attributes during build.
You can still author C# class libraries that target .NET Standard 2.0, but you must use a manually-authored function.json. The templates for C# class libraries aren’t yet available in the Core Tools, but you can get a sample from GitHub.
from Develop Azure Functions on any platform
Update: 1.0.5 version of SDK should now support it, as mentioned by Fabio.
I want to use OpenRasta in a Windows Service to accept REST calls and know it can be self-hosted by HttpListenerHost. OWIN seems to be the latest and greatest self-hosted web server. Is there an advantage to using OWIN over HttpListenerHost? In terms of performance, flexibility, etc? Is it even possible to use OpenRasta with OWIN?
Blake, we recently released a Owin middleware package on NuGet you can try out.
Some more details here
http://tech.just-eat.com/2014/10/07/opensourced-openrasta-middleware/
In addition to that I'm working on a vNext version as the IAppBuilder has now changed to IApplicationBuilder so need some tweaks.
Just adding to Thomas' answer, since 2.6 the Owin support started by Just-Eat has been moved to the main repository, and we have packages specifically targetting Katana and Mvc Core. A preview 3 will be released soon, but CI packages are of course available. More details are available at https://github.com/openrasta/openrasta-core