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
Related
We have an e-commerce ASP .NET MVC application which posts a message in an Azure Service Bus Queue at some point. To interact with the Azure Service Bus we are using Microsoft.Azure.ServiceBus v5.0 package.
Application is hosted in Azure as a WebApp so we are using Application Insights to monitor it but because of the fact that Microsoft.Azure.ServiceBus starting with the version 3.0 has a dependency on System.Diagnostics.DiagnosticSource monitoring is failing (basically nothing is logged to Application Insights).
We found out that this is an known issue:
Troubleshooting Application Insights Agent (formerly named Status Monitor v2)
The question is there are other solutions than downgrade Microsoft.Azure.ServiceBus package to version 2?
Thanks.
As I understand your question correctly, it asks about how to handle this situation where the two nugets have conflicting version requirements for a common child (System.Diagnostics.DiagnosticSource) nuget.
In such cases, you should always use a version of one of the former nugets which has the version of the child nuget version lower as compared to the other. For example, in this case you should use below two compatible nuget packages:
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'
Situation
Today there is a security vulnerability in .NET Core 2.1 and we have all of our developers update their .NET Core 2.1.x to .NET Core 2.1.10 but no idea when we'll get around to updating the .NET Core hosting bundles on our production web servers.
Questions
Does the fact that we updated our developer machines become nullified because we haven't updated the web servers yet?
Once our developer's code is pushed to production will those apps run against the older libraries for .NET Core that are on our web servers or will they somehow run in the newer version that our developer machines are building with?
If our projects once pushed to production run under an older version of .NET Core libraries, will we run into compatiblity issues because our developers built against an older version?
I guess my ultimate question is, should we always have a policy in our company to update the hosting bundles on our web servers before we update our development machines?
If you wanna benefit from the update done from .NET Core 2.1.x to .NET Core 2.1.10, I would say : while you don't update the servers, yes.
The apps will try to run under the installed framework on the ervers. If you are publishing using the default mode, your code will depend on the framework installed on your production machines. However, you can change to self contained deployment mode and embed the framework with your code to work on "targeted platform" (https://www.danielcrabtree.com/blog/496/net-core-self-contained-and-framework-dependent-deployments-explained).
It should remain compatible because the versions are both 2.1.x. However I would not try it in production before having tested it in a separated environment.
I believe you should not update your production servers before having tested the new version first. I would change the targeted framework on my development machine, then I would update the framework and the code in (at least) a pre-prod environment. I would test it in this environment. And only then, I would consider a change on the production servers.
Point 3. EDITED based on Daboul comment
I have begun the process of migrating one of our many ServiceStack services from .Net Framework to .Net core. Most of the migration has been relatively smooth, but I have run into a brick wall with Service Models. This service is dependent on using other ServiceStack services that are still on version 4.0. When I attempt to use Service Models from those services in the new project I get an error saying that the IReturn<> interface wants the version 4.0 assembly specifically, and does not want the 5.0 version of ServiceStack.Interfaces. Downgrading just ServiceStack.Interfaces causes a similar error, but the inverse where everything else that depends on that assembly wants version 5.0. Is there a way to upgrade one project without upgrading every project? I think we all know that real systems need a transition period, and that there's just no way to migrate every service simultaneously.
Please read the existing links from this answer:
https://stackoverflow.com/a/51252374/85785
TL;DR you can’t share the same .dll, you either need to multi-target or decouple the binary dependency by using C# Add ServiceStack Reference.
Other solutions is having old Framework projects Reference the old compiled ServiceModell.dll (alternative to multi targeting) or just copy the source code of the DTOs you need (alternative to C# Add ServiceStack Reference).
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.