I'm planning to start using Ninject 2.2 in enterprise-like project after playing with it for some time. Can anyone confirm no issues with these extensions in production use? I especially worry about IDisposable scenarios (client WCF proxies in MVC controllers, etc).
We consider 2.2 as stable. If you find a bug we try to fix it fast.
Related
I have created a sample project in .NET Core 3 using NuGet package Microsoft.Extensions.Caching.StackExchangeRedis for distributed caching. Everything is working fine but I am not sure what would happen if multiple clients asynchronously and concurrently used some particular resource.
I am not able to find any new articles/solutions regarding the concurrent access and therefore using some mechanism for locking. There are many old articles but nothing that has been posted lately so I am not sure to what extend those solutions work years after their release.
Are locks necessary for asynchronous access and concurrent use of resources in .NET Core using Microsoft.Extensions.Caching.StackExchangeRedis package? If that's the case - some help (code/articles/links) would be much appreciated.
I have been very happily using Ninject for a long time now, and I really like it, but I am faced with a difficult choice since the release of ASP.NET Core and MVC Core.
Basically, out of the gate, Microsoft has revealed their own dependency injection system; Which is one that to my knowledge has gotten a lot of criticism. But my bigger problem lies with how it affects other libraries.
From another question I asked and other resources online, it seems that Ninject does not work out of the box with MVC Core. Though there is a "solution" given in the form of a verbose library Microsoft.Framework.DependencyInjection.Ninject and Ninject. This is even trickier because that library requires adding https://www.myget.org/F/aspnetmaster/ to your list of NuGet feeds.
I have done some digging and found where this library is hosted; It looks fine, it seems to work okay from what I can tell, but there are a few things that trouble me.
The library does not really appear to be headed by the Ninject creators
The library is buried pretty deep in an obscure repository
The actual Ninject resources online never mention it
So basically, I am very concerned that this is some kind of band-aide, and that support for Ninject (and even other container libraries) is dying out. Is there some hidden information that I'm just not discovering?
There is a discussion going on between maintainers of the existing DI libraries, whether or not to build, maintain and support an adapter for the new ASP.NET built-in DI system. The Autofac maintainers have confirmed that they will create and support an adapter, while the Ninject team has been silent, and other teams such as the Simple Injector team (that includes me) have explained that they won't support an adapter.
Personally, I think that the ASP.NET Core built-in DI library is a nice and clean DI library, but it is limited to simple applications. As I explained here, many features that are required for developing maintainable applications built around the SOLID principles are not supported. However, just like the Unity DI library did a couple of years ago, I think that this built-in container might actually trigger developers to start using dependency injection, which is a win for our industry.
These limitations make the built-in container especially suited to configure and extend the ASP.NET system itself. To build large maintainable applications, you will need to use a different DI library. This of course is fine; you will have to pick the right tools for the job.
Unfortunately, up until now, the ASP.NET team has communicated publicly that using a different DI library, means you will have to write/use an adapter. This unfortunately is the wrong message IMO, because most DI libraries are incompatible with the API presented by the built-in container (as I explained here and here in detail). Only Autofac seems reasonably in sync, which explains why the Autofac team choose to maintain an adapter. But do note that even Autofac has proven to be incompatible with the abstraction that Microsoft defined, and they (just like StructureMap) had to make big changes to their product to even be able to comply with the abstraction. And the Autofac maintainers are severely frustrated about the whole process and the abstraction in general. And as I explained here, even the ASP.NET provided adapter implementation of Ninject is broken.
This message by the ASP.NET team to use an adapter is IMO a big error, because this stifles innovation (while the DI library itself doesn't; it's just another DI library). The ASP.NET team is promoting a model where both your application components and the ASP.NET system (and all other sub systems that will plugin in the future) will be registered in your custom container. It is much more reasonable and practical to keep your application configuration separate from the configuration of the ASP.NET system (as explained here).
Because of this, I find the use of an adapter for any container rather useless. As I shown here it is really easy to plugin your own DI container, while keeping it completely separate from ASP.NET's registrations. This means that you don't need support for Ninject to be able to effectively use Ninject on an ASP.NET Core project. The only thing Ninject needs to do is to create a version that is compatible with .NET Core (in case your product needs to run on that new platform).
UPDATE: "Ninject 3.3.0 was released September 26th 2017 and now targets .NET Standard 2.0 and thus also runs on .NET Core 2.0." source
So in a nutshell, I'm not sure that support 'is dying out', although some DI maintainers (such as the Simple Injector team, and probably Castle Windsor and Ninject as well) have chosen not to build, maintain and support an adapter implementation for ASP.NET Core, because it is not needed, and is only in the way.
UPDATE November 2016
I've been discussing some improvements to ASP.NET Core with Microsoft to make it easier to plugin a container that don't have an adapter (take a look at my example repository and especially to the Startup.cs of the Ninject sample project), but until now Microsoft seems to stall progress because (as Fowler states hisself) their "bias towards conforming containers [is] clouding [their] vision".
The library does not really appear to be headed by the Ninject
creators
That library, and it would seem these also, look to be Microsoft created samples of Dependency Injection providers that were removed in beta7. Note that the link to DI in MVC 6 referenced by your original question says the following;
These DI container adaptors are temporary and are there for reference;
we expect that they will eventually be removed and replaced by the
respective container owners.
As they should be. Microsoft should not be responsible for maintaining 3rd party providers.
The library is buried pretty deep in an obscure repository
If you are not aware, ASP.NET 5 is still in development. Beta 7 is available on nuget as a pre-release, but there are other sources as well including;
https://github.com/aspnet/ (source code)
https://www.myget.org/gallery/aspnetvnext (nuget dev branch builds of the above)
https://www.myget.org/gallery/aspnetmaster (nuget master branch builds of the above [same as your question])
These sources are maintained by Microsoft.
The actual Ninject resources online never mention it
As with any new development, 3rd party library providers must themselves determine when (if at all) they will provide implementations of their products that support the new codebase. For some, it will be seen as most efficient to wait until the new framework is officially released, as API breaking changes are still highly likely to occur until that point. Whether support will be implemented at all is of course up to the providers resources, and/or in the case of open source the community.
We are considering to change our present .net2 on IIS6 server to .net4 (or 4.5). Can someone help us with some basics about this?
After we install .net4 to our production IIS. Is every .net site defaulting to .net4?
we have had some dificulties with 64-bit version so we have forced IIS6 to run in 32-bit mode. Does update do something to this? After installing .net4, how can we force specific application pool to operate on .net2 mode and on 32.bit mode?
What problems there might come out on transforming .net2 sites directly to .net 4 sites? Or is there any?
It's been a while since I've last used .NET, but here's my general suggestion.
First, Migrate to .NET 4! .NET 4 offers better security and new features. Consider that as your first option.
Second, in my experience, if you have multiple versions of framework installed on the server, you should be able to choose which version to operate that site.
Lastly, I'm not sure about 32/64 bit thing, but my suggestion is to simply fix it! Applications, especially heavy-load applications can operate better in 64-bit mode.
Make you application as future-proof as possible!
As for what problems you might run into, I really depends on what kind of APIs you're using, chances are, they will be a few deprecated methods, properties. Also, look at some new features, there might be new APIs worth trying, try that at a development server, it might increase overall user experience and even application performance.
Good luck!
Is every .net site defaulting to .net4?
When you add some website to IIS, it is assigned "DefaultAppPool" by default. So, it depends on what version of .NET framework set for your "DefaultAppPool". You can change application pool to target specific .NET framework.
After installing .net4, how can we force specific application pool to operate on .net2 mode
You can define more than one Application Pools in IIS targeting different .NET frameworks and then assign different Application Pools to different websites.
What problems there might come out on transforming .net2 sites directly to .net 4 sites? Or is there any?
I think it usually depends on your website; the libraries referenced, the patterns used, etc. No one can give you clear answer of it.
I know SysCache uses ASP caching under the hood, but since I'm not aware of the implementation of the ASP cache (and if it depends on anything IIS), I was wondering if SysCache would work in a non-web application (like a Windows Service)?
Activating it and using NHprofiler seems to show it is not.
No it doesn't, Syscache is an abstraction over asp.net cache. You have to use a different cache for the service.
EDIT:
I remember this blog post: http://www.hanselman.com/blog/UsingTheASPNETCacheOutsideOfASPNET.aspx
They say it should be usable outside a web-environment. It's just not recommended because microsoft maintains it to be usable in a web environment. That means that you can use it now, but you might have trouble when .Net 4 (or 5, 6, 7, ...) is released.
I am just curious to know the reason why it's not possible to host an ASP.Net web service other then IIS ? While in WCF it's possible to host a service in IIS, WAS or any console application.
Please clear the doubt..
ASP.NET is actually not specifically bound to IIS. The .NET Framework includes an HttpRuntime which may be used to write a custom hosting platform. You could easily write a console application, like you can for WCF, that will provide the ASP.NET runtime without IIS.
Technically speaking, you could also write an Apache module that hooked into either a separate .NET process hosting the ASP.NET HttpRuntime, or possibly hook directly into a .NET assembly. I don't know much about writing extensions to Apache, however assuming you can bridge the Apache unmanage to .NET managed gap, you would be able to host ASP.NET in Apache (which should be possible, you might need a native & managed C++ library to mediate.)
Microsoft's .NET framework is amazingly extensible. You can pretty much achieve whatever you set your mind to, if you have the will and the time (and perhaps the funds.) However, the .NET platform does encapsulate an immense amount of functionality, and it is up to Microsoft to choose how they spend their money. Naturally, they have their own business to worry about, and I would not expect them to expend tremendous amounts of money giving a leading edge to their competitors (it would be bad business, and quite a disappointing competitive practice, if you ask me.)