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.
Related
I am integrating app insights into our AspNet Core app(Target Framework .Net 4.7.1). I have two queries regarding app insights integration.
I am using SimpleInjector IOC, so does it make sense to have below line of code to inject AI into Asp Net Core DI?
services.AddApplicationInsightsTelemetry
I'm having my own Logger class which initializes TelemetryCLient and Logger class is injected using SimpleInjector. So removing above line code will cause an issue or lack of feature from ASPNet Core perspective?
In Asp.Net when we use to add AI it uses to add ApplicationInsights.config file which contains TelemetryInitializer's and TelemetryModules. Whats the best parctice in AspNet Core 2.1 for this? How do I add following TelemetryInitializers?
HttpDependenciesParsingTelemetryInitializer
AzureRoleEnvironmentTelemetryInitializer
AzureWebAppRoleEnvironmentTelemetryInitializer
OperationCorrelationTelemetryInitializer
etc...
Thanks in advance!!!
services.AddApplicationInsightsTelemetry is the easiest way to add application insights to your project. It sets up auto-collection modules for Requests, Dependencies etc, sets up default TelemetryInitializers, TelemetryProcessors (for sampling, live metrics etc.)
if you don't use services.AddApplicationInsightsTelemetry, then you have to programmatically setup all modules/initializers/sampling etc yourself.
There is no ApplicationInsights.config file, so pretty much every customization of the config is to be done through code. Following shows how to add/remove telemetry initializers.
https://github.com/Microsoft/ApplicationInsights-aspnetcore/wiki/Custom-Configuration#configure-telemetry-initializers
With ASP.NET Core 1.0 release one can run on either .NET Core or the full .NET Framework per the documentation here. I'm trying to understand the latter option of why one would select ASP.NET Core + the full .NET Framework?
I understand the difference between the full .NET Framework and .NET Core. However, if I wanted to use the full .NET Framework, why not just use ASP.NET 4.6? I thought the idea was a 1-2 punch with ASP.NET Core atop of .NET Core allowing the slew of benefits like cross platform deployment, modularization, ability to deploy to a Docker container, performance, etc. Without .NET Core I don't believe anything on that list is still valid, so what is the use case for the full .NET framework + ASP.NET Core? What does ASP.NET Core on it's own still provide to me without .NET Core?
.NET Core allowing the slew of benefits like cross platform deployment, modularization, ability to deploy to a Docker container, performance, etc.. Without .NET Core I don't believe anything on that list is still valid
The only benefit you don't have if you choose the full .NET framework over .NET Core is being cross platform. All the other benefits of deployment, modularization, docker, performance, etc... are still valid.
We actually run our ASP.NET Core web app on the full framework and now we enjoy the benefits of having Dependency Injection as a 1st class citizen, having NuGet built in, having an lean HTTP request pipeline which makes our performance better, open sourced (so all the issues can be solved by a short visit to GitHub), modularity (still have to come across something we couldn't customize to our own needs after almost a year now), and so on. And we know we don't need to deploy on any other OS than Windows, so we can still have all the benefits of the full framework.
Update from Tseng
Well, you can still target full .NET Framework under Linux for example. There you need mono 4.6 installed there. There are some limitations as not all classes are implemented in mono, but a majority is and around the corner case (i.e. encryption) you have to work around
Update from atconway
It's also worth noting at the time VB.NET is not supported by .NET Core if that's a requirement.
However, if I wanted to use the full .NET Framework, why not just use ASP.NET 4.6?
If I use ASP.NET 4.6 instead of ASP.NET Core 1, then I won't be able to use ASP.NET Core MVC. None of the features on that documentation page would be made available to me! I would have to build an MVC5 application. Boooo!
I'm trying to understand the latter option of why one would select ASP.NET Core + the full .NET Framework?
I'm assuming that another way to ask this would be: "why would you take the red path when you can take the brown path?"
One argument for doing it this way is deployment. If you've got a bunch of existing Windows servers with IIS on them, you're going to need to install additional software on each of them and set them up to run Core applications. IIS just becomes a reverse proxy for your .NET Core app.
However, if these apps were built on the .Net Framework instead, you wouldn't have to do this. You could still use web deploy (for example) to move them onto the servers. Maybe you've got some other existing IIS configuration settings that you don't want to migrate.
Using ASP.NET Core 1.0 targeting the .Net Framework, you can get the benefit of the new features in ASP.NET Core MVC without having to change your existing infrastructure.
One important benefit of using Full .NET framework with Asp.Net core is availability of mature libraries and frameworks that are developed mainly to target previous version of .NET.
But by passing of time and implementing more and more libraries to target .NET core and developing more features for .NET core itself this benefit may fade out.
Having to leverage legacy technologies like OLE DB that will never be implemented in NET Core System.Data is another reason.
One thing to consider is that it can be a migration path. Say, for example, you have an existing ASP.NET 4.6 application that you intend to migrate to .NET Core. You want to take advantage of ASP.NET Core features like TagHelpers, Dependency Injection, etc., but you aren't ready or able to use .NET Core framework. So, you develop the ASP.NET Core application, targeting just the .NET full framework. Then, you take the next step and multi-target, going for both .NET full framework and .NET Core framework. This gives you the flexibility to easily deploy to IIS with the full framework or cross-platform with the core framework. From there, you can decide if you want to eliminate the full framework or not.
When moving from OWIN to ASP.NET Core, I've found a bit of information about dependencies to migration, but I've not found information about these other topics:
The middle-ware pipeline. How is this different, or not?
The DelegatingHandler pipeline (e.g. Web API). How is this different, or not?
The startup.cs file. How is this different?
In short, it would be great to know what are the primary hot-spots that would need my attention, in order to move from OWIN to ASP.NET Core.
As a first example - ASP.NET Core does not appear to have HttpConfiguration. There are myriads of example plugins and services that assume its existence. I'd like to infer how to translate instructions for HttpConfiguration into whatever approach ASP.NET Core expects.
As another example, the Swashbuckle documentation gives instructions for setup with OWIN, but those instructions don't work with ASP.NET Core. If I understood the primary differences from OWIN, it would be easier to "guesstimate" how to install Swashbuckle into ASP.NET Core.
Note: Swashbuckle also gives instructions for self-hosted apps. That confuses me because I think of OWIN (vis-a-vis Katana) as being self-hosted already, and so it sounds redundant to me. But I don't think this is related to the present question.
My question has used Swashbuckle as an example, but I am not asking about Swashbuckle specifically.
Update
I've discovered that much of the information I'm looking for is in the article Transitioning from Web API 2 to ASP.NET MVC 6.
Middleware is quite similar between Katana and Core but you use HttpContext instead of IOwinContext.
Startup.cs is similar but there's much more DI support.
WebApi has been merged into MVC
DelegatingHandler is gone, use middleware instead.
HttpConfiguration has been split up into Routing and MvcOptions.
Also https://devblogs.microsoft.com/aspnet/katana-asp-net-5-and-bridging-the-gap/
I think you can start here. It's an entire chapter about OWIN with ASP.NET Core. Hope this helps.
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 am looking for an ioc container to use for asp.net webapi. Couple of the key feature we are looking for are as follow
Custom lifetimes
Built-in support for web request lifetime
Good integration with web api in terms of manage the dependency registration.
Mark Seemann knows his DI/Ioc and has an article on implementing it for Wep Api with Castle Windsor here. I don't know about custom lifetimes but it definitely solves the second and third requirements.
Castle is not as lightweight as say Autofac but it's been around for years and is tried and tested: I am using Castle for my Web Api and Mvc projects without issue so far.
Both should do the job though.
I personally like Unity. The reason why I use Unity is that it is build by Microsoft and with that you can expect that it is nearly up-to-date. Also I had prior experience with it and it has good support for ASP.NET Web API, but the final choice for or against a container is up to you. It really dependent on personal flavor.
There's a small part in the ASP.NET tutorials which talks about using Unity with Web API.