I'm using both asp.net mvc 5 and asp.net web api 2 owin based web application.
The first one is the website and the second one is the backend api.
I need to share some libraries,
in the asp.net mvc application i can access to HttpContextBase.Request that is a HttpBaseRequest
in the web.api a can access to httpContext.Request that is a HttpRequest
Planning to upgrade to asp.net core in future, what is the best way to have a common object to share in my class libraries?
You could define an interface representing access to httpcontext, however without binding it to any specific http-related type
Then, provide implementations specific to frameworks that your libraries and apps are dealing with. .net framework and .net mvc and dotnet-core each define different implementations for http contexf, request, response.
e.g.
interface IMyHttpContext
class Net4HttpContext : IMyHttpContext
class NetCoreHttpContext : IMyHttpContext
then, expose just what you need. e.g. GetRequestPath, WriteToResponse, GetHeader, SetCookie. etc..It'll be a lot of and ongoing work, but as a result, your netstandard libraries (one of which should host your interface, btw) won't care about the impementation. Obviously, you'll have to replace all usages of specific http objects to your interface.
So, IMyHttpContext goes to one new netstandard assembly..This assembly will work with all dotnet frameworks.
Net4HttpContext goes to net45 assembly, itself referencing System.Webb. you reference this one by windows-only, .net framework apps.
NetCoreHttpContext goes to dotnetcore or netstandard assembly, referencing dotnet core's http-related nuget packages. use this one with dotnet core apps.
Then, throughout your apps, whether they are net45 or netcore, along with some DI setup, you reference just your interface. Implementations get to be injected.
Good luck.
Related
I'm starting to wonder whether this is the right tool for the job, still here goes.
I'm attempting to automate the creation of our Azure Test environment using Azure SDK for JS. The environment spans many services (as you can imagine), including Classic ASP.NET app services.
Node is my safe space, so that is why I started with the JS SDK.
I have started scripting the creation of an app service using WebSiteManagementClient.webApps.createOrUpdate. I'm confused though, there is seemingly no way to configure any of the following:
Which app service plan the app service should be connected to. This feels fundamental.
The operating system, Windows or Linux.
The stack version, .NET 4.8, .NET Core, or whatever.
Is it possible to configure the above using the JS SDK, or am I going to have find another approach?
Update 23/03/21
Untested, but these are my findings so far:
App Service Plan - The plan is set using the serverFarmId property of the Site interface.
Operating system - Assuming Windows as the default, if you want a Linux app service, you change the kind property of Site from app, to app,linux.
Stack & version - In the SiteConfig interface, you have linuxFxVersion and windowsFxVersion. Again, I think the assumption is 'latest .NET' (e.g. .NET 4.8). For .NET Core 3.1, the setting looks to be DOTNETCORE|3.1.
It can be achieved using js SDK. I checked the source code and it is ok. But I don't recommend to use js sdk to do this.
Because you need to call the SDK, there are many internal logics that you need to code. This will waste a lot of your time. So I recommend you to use restapi.
The restapi method name is similar to the naming in the SDK, mainly because you can test api interfaces online to achieve the functions you want. So you can selectively choose the method you want to achieve the function you want.
Official doc
Web Apps - Create Or Update
As for your concerns, you only need to write all the configuration in json format and put it in the request body.
Tips:
First use the online interface, encode the json format, create a webapp according to your needs, and then integrate it into your code.
I've recently switched jobs from a AWS shop to an Azure shop, both using dotnet. AWS publishes Amazon.Lambda.AspNetCoreServer, which is a magic Nuget package that allows you to write a plain ol' ASP.NET core Web API and deploy it as into a lambda with only a few lines on config. I really loved this pattern because it allows developers to just write a normal web api without having the host runtime leak into their coding.
Does anything like this exist in Azure? Even something that is community supported? Or is there some any way to achieve something like this in Azure Functions?
Unfortunately there is no simple way to do that since Azure function format is a bit different.
[FunctionName(nameof(GetAll))]
public IActionResult GetAll([HttpTrigger("get", Route = "entity")]HttpRequest request)
Then it will generate json with meta data for AF.
If you wish to host pure .net core without any changes I would look into Containers option
PS0: Theoretically it would be possible to do it with little bit of reflection. For instance you create project with all your Asp.Net core apis, which you can use in asp.net core hosting. Then you write tool which grabs your dll and using reflection you find all actions in your controllers and generate code for AF
PS1: Have a look https://github.com/tntwist/NL.Serverless.AspNetCore
I'm trying to wrap my head around how we're supposed to build Azure functions.
I love the idea of building serverless, compact, single-function apps that respond to events.
Here are the problems I'm running into:
I have nice class libraries built in .NET Standard 2 that handle all my "backend needs" namely handling CRUD ops with Cosmos Db, Azure Table Storage, Azure SQL, Redis, Azure Storage. No matter what I did, I couldn't integrate these class libraries into an Azure Functions project. More details below.
Also, getting dependency injection in Azure Functions project has proven to be quite a task -- especially with my class libraries mentioned above.
At this point, the only option I'm seeing is to "copy and paste" code into a new Azure Functions project and use it without any DI.
This seems to go against "best practices". So what's the solution other than either to create monolithic code or wait till Azure Functions support .NET Core and DI.
I thought I could use my .NET Standard class libraries from a regular Azure Functions project targeting .NET Framework. After all, the idea of .NET Standard is to "standardize" things. I opened a couple of posts here on SO. I'm providing the links so that you can see the issues I've run into:
Using .NET Core 2.0 Libraries in WebJob Targeting .NET Framework 4.7
No parameterless constructor error in WebJobs with .NET Core and Ninject
P.S. My previous posts are referring to WebJobs. That was plan B approach because WebJobs seem half a step ahead of Azure Functions when it comes to supporting things like .NET Core and DI. Ultimately, I'd like to build a few Azure Functions that can use my class libraries built in .NET Standard 2.
Also, my previous posts mention that my class libraries target .NET Core 2.0. Since then I converted them to .NET Standard 2 which didn't really take much at all. I did this so that I truly conform to .NET Standard 2.
One issue is that Visual Studio has an outdated version of the Functions Core tools. Until this is resolved, you can work around in the following way:
Install the latest via npm by running npm install -g azure-functions-core-tools
In your Function App in VS, go to the Properties
Go to Debug, and click New... under Profile
Name the new Profile something like FunctionsNpm
Set the executable to (replace [YourUserName]): C:\Users\[YourUserName]\AppData\Roaming\npm\node_modules\azure-functions-core-tools\bin\func.exe
Set the arguments to host start
Set the working directory to $(TargetDir)
In toolbar, look for the green triangle icon to change your current Profile to the one you just created:
Now when you run from VS, you'll be using the npm tools instead of the older one that come with the VS package.
.NET Standard 2 support is on its way, see this github issue.
We want to create general public web services and we create customized APIs.
But how to isolate, version and bind those endpoints as a hyperscaled system?
We want to have:
https://api.domain.tld/v1/..
https://api.domain.tld/v2/..
https://api.domain.tld/latest/..
https://api.domain.tld/bosch/v1/..
or
https://domain.tld/api/v1/..
https://domain.tld/api/v2/..
All endpoints should be isolated. Behind an endpoint like https://domain.tld/api/v2/.. exists at least 3 instances of an ASP.NET WebAPI. We do not want to separate versioning by namespaces inside the WebAPI project and use internal route configurations to resolve this.
We want to have this behavior onpremise and aswell on Azure.
Is there any recommendation or best practise and configuration samples out there?
I could only found one thread here (How to version and configure WebApi with multiple aliases) which is very old and there is no answer.
I always use the version as the api route, like you so:
https://domain.tld/api/v1/..
https://domain.tld/api/v2/..
which has always worked fine, but other use url parameters, which I find to be less explicit:
Visual Studio Team Services - API
I would just not recomend you to go with this pattern:
https://api.domain.tld/latest/..
https://api.domain.tld/bosch/v1/..
It would you make you API look a bit messy, but it could make sense if you use logical services in your API:
https://api.domain.tld/service1/v1
https://api.domain.tld/service1/v2
https://api.domain.tld/service2/v1
I have an existing project using RIAServices with Entity Framework. The project builds correctly and generates the AmsiWeb.g.cs file with all the context classes for my services.
I am converting my designer based entities and ObjectContext with Code First entities and DbContext. I installed the RIAServices.EntityFramework NuGet package to the web application that contains my services. However, now when I build the AmsiWeb.g.cs file only contains the WebContext class. It doesn't contain any generated services.
I have only at this point converted a single EDMX model to Code First and DbContext and made the requisite changes to the services that use that model to inherit from DbDomainService.
I am using EF 5.0... not sure if that matters cause I'm not sure how adding a DLL to the AmsiWeb application project would break code generation.
What would cause this to no longer work and how can I fix it?
Maybe it's a problem within the msbuild task that generates the proxy code (I mean the *.g.cs file). Probably it's looking for the wrong version of a entity framework. Have a look at this blog post http://mcasamento.blogspot.it/2012/10/entity-framework-5-code-first-and-wcf.html in the final part I wrote an assembly redirect statement that did the trick
It turns out that their needs to be a redirect for Entity Framework 5.0 (4.4.0.0 since I was using .Net 4.0) in the web.config. But, since my RIA Services were in a web application project that was not my root project the code wasn't generating.
Once I added the redirect to the web.config of the web application with the RIA services in it, the context code was correctly generated.