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.
Related
I want to use Azure DocumentDb in my ASP.NET 5 project and it seems that DocumentDb .NET SDK doesn't work with DNX yet. Is it so? And if Yes maybe there is a workaround here?
You can get ASP.NET 5 to target the full .NET Framework as opposed to Core. The biggest advantage of targeting Core is that it would allow you to run outside of Windows, but if this is not a requirement for you then the full framework should be fine.
I don't know the status of work on supporting DNX, but assuming that's not going to come in time, I can think of several ways to work around it:
Hit the DocumentDB REST API directly
Run edge.js in process inside .NET and use the node.js SDK although there seems to be some question about what platforms are supported by edge.js.
Use node.js instead of .NET. My experience helping .NET developers ramp up on DocumentDB has convinced me that the JavaScript-centric design of DocumentDB means, it's much easier to use from node.js than it is from .NET, IMHO. Many of the .NET problems come from the difference between strongly typed .NET and highly dynamic JavaScript. Stored procedures are written in JavaScript not .NET.
Im required to write a Silverlight application using WCF.
I'm also required to use Dependency Injection to gain access to this service in another library.
(I add a Silverlight enabled WCF Service)
The problem is in trying to use Dependency Injection (Prism/MEF in this case). When I make a Silverlight Shared library that will have interfaces for this service, I cannot add this library in the ASP.Net project due to the fact that it is Silverlight library. If I make a non-Silverlight library I cannot add that library to other projects to share that common interface.
Basically I need a library I think to share between projects in Silverlight so I can do this service injection.
Any information is appreciated
As slugster said - this done via linking to windows library files from silverlight library.
You do it as described here: http://www.dotnetmafia.com/blogs/dotnettipoftheday/archive/2010/01/20/linking-files-in-visual-studio.aspx
I just wanted to add.. Since you go there - what you need is another Framework/Technology. Usually those classes you talking about depend on other classes/namespaces that live in windows only or silverlight only world. And then you need to transfer object data via wire.
Microsoft's solution to this - RIA Services. What it does - it takes your Windows classes and generates proxy classes on Silverlight side. Kind of what you need. And it works with WCF services.
There is 3rd party solutions like CSLA and DevForce.
I use DevForce and it does many things automatically, but instead of generating proxy classes - it creates links just like what you want.
Whether you realise it or not, your question is a duplicate of this one: Shared data object between WCF service and Silverlight app While not asked the same way, the answer is the same.
You need to create a separate project, and share the code files (as links) from one project to the other. Your problem is that the Silverlight project is compiled for a different runtime to the ASP.NET/WCF project. Because they cannot reference a common library, linking the shared files as mentioned is the easiest way to share code between the two projects targetting different runtimes.
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.
I work at a financial institution, in a team whick takes care of a "home-made" corporate component. This component was built using .NET 1.1, and the other teams use it a lot, specially along with the legacy systems (the ones which are still in .NET 1.1 too)!
Now we want to upgrade this component to .NET 4.0 so we can use some new features (in fact, we want to use Websphere MQ, and its .NET library was build over .NET 2.0). However, can't simply change the runtime of our component, because our internal clients can't afford with an upgrade to their systems.
So, we need to keep a .NET 1.1 component working as a proxy to some service built in .NET 4.0. This was where my question came from: how this interoperability can be made? My first answer was using .NET Remoting 4.0 to comunicate these two parts. Although we can use a WCF service exposed with a HTTP binding (the .NET 1.1 component uses it as it was a ASMX web service), .NET Remoting has proven its performance advantage over the previous solution, but it's a legacy framework (http://msdn.microsoft.com/en-us/library/kwdt6w2k.aspx).
What I'd like to know is if you guys have another idea to do this interop. Is there a way to call a WCF service exposed with the netTCP binding by a .NET 1.1 client?
Thanks a lot!
The real solution is to get over the problems that are forcing you to use unsupported software (.NET 1.1). Then you won't have to do horrible things like the following:
Create a .NET 4.0 class library.
Add a Service Reference to your WCF service.
Create classes and interfaces which can be used to call the WCF service.
Expose them as COM classes and interfaces
Have your .NET 1.1 code consume the COM object and make calls through it
Would be, "compare the amount of effort you just spent on trying to make obsolete unsupported code work vs. the amount of new, useful work you just did".
Note also that this technique quite rightly places .NET 1.1 in the same category as Classic ASP in terms of its ability to use modern software like WCF.
Finally, note that I haven't found a way to make the WCF client in this situation to use a config file. It was necessary to configure it in code.
Is there a reason why you can't port the component and have two versions (a 1.1 version and a 4.0) version? That would let the legacy apps continue to use the component, but your 4.0 stuff could use a newer version without all the complexity required in your proposed solution.
Different versions of .net assemblies can play nice with each other, you aren't forced to only have one version of the component.
I'm somewhat familiar with WCF in that I can build Web Services in VS.Net ... I understand some of the concepts...
But, the other day I cam across this option in Eclipse (I also use Java to code) to create a WSDL. Playing around with it it looks great since it has a GUI method of building itself.
I guess I just wanna know what the difference is.
1) Are they different technologies like WSDL vs WCF? Or, is it that WCF uses WSDLs?
2) I read that WSDLs are a top-down approach... so what about WCF, is that top-down or is that bottom-up?
3) Will this WSDL in Eclipse actually be able to generate CSharp code for my server and client efficiently, or will it require a lot of fixing?
Windows Communication Framework and other services frameworks use standards like the Web Service Definition Language to communicate specifications.
WSDL is neither inherently top-down nor bottom-up. You can do it either way; that is, you can design your interface using WSDL and then code your service to the WSDL, or you can design your application and use a tool like those built into Visual Studio and Eclipse to automatically generate the WSDL. There are pros and cons (and proponents and opponents) to both approaches.
IDEs like Visual Studio and Eclipse usually do a good job (probably better than humans) of generating WSDL. I haven't used the Eclipse plugin for C# (I'm assuming there is one and that's what you're using if you want to generate C# in Eclipse), so I can't speak for its functionality.
EDIT: I answered question 3 backwards, but the answer still applies. The WSDL-to-code generators also generally do a good job just like the code-to-WSDL generators.