I'm converting all of our shared class libraries from .NET Framework to .NET Standard so that they're consumable by both our older .NET Framework and our new .NET Core applications. The goal is to get all of our applications to .NET Core, but it's a large system so will take time so we need the two worlds to coexist for a year or so in the meantime.
One of the pain points is that the shared class library code leverages HttpContext extensively. I understand that the new .NET Core way to access it from within class libraries is to use AddHttpContextAccessor. However, we still have old ASP.NET web forms applications AND new ASP.NET Core web applications that both need to call this common code. If I switch to using HttpContextAccessor with DI then it won't work from the old ASP.NET Web Forms app, as it has no concept of what HttpContextAccessor is.
I'm wondering what my options are here... Is there a way to set up access of HttpContext such that it can be consumable both in ASP.NET Web Forms and ASP.NET Core?
You have to have some common interface between both the old and new applications I would think.
Create a new IMyHttpContext and inject that type into both the old and the new. Use your DI infrastructure to instantiate a new MyClassForOld: IMyHttpContext that accesses an underlying reference HttpContext for the old apps and use your DI to instantiate another new MyClassForNew: IMyHttpContent that accesses an underlying reference to HttpContextAccessor
Related
I am building a web app that has a dashboard page in which data must be updated in real-time. I'm using ASP.NET Core 3.0, MVC, ADO.NET, SignalR, and SqlDependency in my project.
I chose SignalR and SqlDepdendency (first time i'm developing with those) because data is fed into my SqlServer database from other db sources, and data needs to be pushed to my web app and to my clients. I found a few websites to explain how to use SqlDependency but I found no code examples with ASP.NET Core 3.0.
https://learn.microsoft.com/en-us/sql/connect/ado-net/sql/detect-changes-sqldependency?view=sql-server-ver15
Where and how should I put the SqlDependency.Start() / SqlDependency.Stop() in the Startup.cs ? I currently have them inside my Repository DAL (Data Access Layer) class' method but I don't think it's correct to have the Start() and Stop() there because it doesn't make sense the SqlDependency is initiated and stopped on each call to that method is made by a client loading the dashboard page.
Also, any drawbacks or problems that you know with SqlDependency in terms of performance or bugs?
So much I could understand, Kephas does not provide its own DI container, but it builds adapters on existing ones (Kephas has its own dependecy injection container. Why another framework, why not use an existing one?). Existing adapters are for System.Composition (MEF2) and, as I learned recently, for Autofac (starting with version 6.5.0, Cannot use constructors in open generic services with Kephas).
However, ASP.NET comes with its own implementation of a DI container. In this regard, is it possible to use Kephas with ASP.NET Core now, and if yes, how?
Starting with version 6.5.0, Kephas will provide also an ASP.NET Core adapter so, yes, it will be shortly possible to use Kephas with ASP.NET Core. However, the built-in Dependency Injection does not have all the features Kephas requires, naming metadata and lazy instantiation. There will also be an adapter for Microsoft.Extensions.DependencyInjection, but without the aforementioned functionality, so I do not really recommend it. The Autofac adapter is the recommended one (event the Microsoft ASP.NET Core recommends it for advanced scenarios).
On the other hand, you could let Kephas manage its dependencies using MEF2 or Autofac and provide to ASP.NET Core a service provider aggregating the default one (or the one of your choice) and the one from Kephas. This has the following drawbacks:
You will end up with two containers.
The Kephas container will not have access to the services provided by ASP.NET Core.
Is there an MVC6 compatible version of WebTelemetryInitializerBase that would work with ASP.NET Core (on the full .NET Framework)?
See my question here where I asked how to get HttpContext in my temeletry initializers. Unfortunately I didn't specify that I was using MVC 6 and thus no System.Web.HttpContext.
Yes, there is a version of this for aspnetcore. Check out the Microsoft Application Insights for ASP.NET Core applications repo.
There is an implementation of getting the WebUser found in /src/Microsoft.ApplicationInsights.AspNetCore/TelemetryInitializers/WebUserTelemetryInitializer.cs which you can use as a guide.
The TelemetryInitializerBase class is the one that consumes the IHttpContextAccessor which is used to get the HttpContext.
From there you can get the Microsoft.AspNetCore.Http.HttpContext.User which is they type of System.Security.Claims.ClaimsPrincipal
I'm very new to Asp.Net Web Apis(which Microsoft has made a part of MVC templates though we can use Web Api template independent of MVC)....Just a little background.
Coming back to my problem when my Web Service is called by a user then along the line of what my Web Service is serving comes a point where I have to deserialize a Json file to a generic C# collection and cache it in-memory and then the code inside one of the Controller actions(which is obviously a get method) checks for the in-memory cache and if it has that deserialized C# collection it gets it from there else its calls another method inside the controller which caches this generic collection in memory.
My question is ...is this possible to cache the stuff for a Web Api like what I described above...I'm quite familiar with Asp.Net page life cycle,caching and sessions etc. But not with Web Api....And my above explanation is just an abstract idea...not sure how to execute it, will it work? If yes then what namespaces would come in handy like System.Runtime.Caching or System.Web.Caching.
Your answers will be highly appreciated....
In the .NET Framework 3.5 and earlier versions, ASP.NET provided an in-memory cache implementation in the System.Web.Caching namespace. In previous versions of the .NET Framework, caching was available only in the System.Web namespace and therefore required a dependency on ASP.NET classes. In the .NET Framework 4, the System.Runtime.Caching namespace contains APIs that are designed for both Web and non-Web applications. ASP.NET Web API doesn't have dependency in System.Web.dll so I recommend you to using System.Runtime.Caching, you can put your caching logic anywhere even in separate .dll file and use it in your ASP.NET Web API project.
I have a web application that is developed using ASP.NET MVC.
The application follows the nth-tier architecture, and I have divided the application into 4 different project which are Model, Core, Framework and the web application.
The Model, Core and Framework are DLLs, the Model contains just my POCO classes, the Core contains my DbContext, repositories and Unit of Work implementations while my framework project contains classes that would be used directly by my MVC web application such as action-link extension, custom view engines e.t.c.
In addition to my framework I created a class called service which makes method calls to the repositories in my core DLL and method in the service class are called by my web application.
My question is: Is it ideal to channel method calls from the web application to the repository through my the service class in my framework DLL or just make a direct call to the Core DLLs?
Don't add an abstraction layer unless you require it. If you don't have a strong reason to add a service layer in the middle, you will end up implementing the Poltergeist anti-pattern, where sole purpose is to pass information to another object.
In general, calling your repository directly is perfectly fine so you have to analyze if you foresee any particular restriction disallowing this schema.