Scenario:
I've set up the Ninject MVC3 using the link below:
https://github.com/ninject/ninject.web.mvc/wiki/Setting-up-an-MVC3-application
I followed Nuget version. And, code looks like below:
private static void RegisterServices(IKernel kernel)
{
kernel.Bind<IService>().<Service>();
}
Could someone help me to understand when and where does the code below gets excuted?
var test=Kernel.Get<Service>();
Basically I'm trying to understand where do we resolve the concrete type.
UPDATE:
my question is more of where does the MVC use Kernel.Get() to resolve the given Interface to the concrete type.
Is this done by Ninject.MVC?
Kernel.Get<Service>() shouldn't be called anywhere. You should request an IService in the constructor of the controller that needs this dependency. When MVC requires this controller then it asks Ninject to create the controller instance and Ninject will inject the service into the controller.
Related
I am working on an ASP.NET Core 7.0 MVC app. I have created a data access layer using EF Core 7.0 with a database-first approach. I was trying to create a Razor view through the "AddView" option from the controller for the "Create" process.
However, I am getting this error:
This is how I inject my DbContext:
builder.Services.AddDbContext<NorthwindContext>(options => options.UseSqlServer(
builder.Configuration.GetConnectionString("DefaultConnection")));
I am new to ASP.NET Core. It looks like I have to pass additional options in the Program.cs file. I did a Google search, but couldn't find any help!
If I create the view manually it might work. However, I would like to create it through the scaffolding process.
This is my NorthwindContext code:
After removing the parameterless constructor as per Neil I am getting the new error:
More specifically to my comment, the AddDbContext registers the context class in the asp.net core DI container so it can be provided whenever any class or process wants an instance of the DbContext.
The view generator will want that. However, if the DI container find a parameterless constructor it will use that first, and therefore not use the constructor that passes in the options.
The outcome is a context is provided that does not have the "UseSqlServer" options set.
Hence the error that a database provider has not been configured.
Remove that parameterless constructor from the DbContext and you should be good to go.
The latest error indicates the constructor requires an object of type DbContextOptions.But the injector cannot create the instance.
You could try with the parameterless constructor and configure the options in OnConfiguring method
And the picture you've shown indicates you've seprated Modes from your MVC projects,Make sure you've setted the right startup project(right click on your solution -- Set startup projects) and configrue which projects would contain the migration classes
public class SomeDbContext : DbContext
{
public SomeDbContext()
{
}
public DbSet<SomeEntity> SomeEntity { get; set; }
protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
optionsBuilder.UseSqlServer("connectionstring", b => b.MigrationsAssembly("MVCProj"));
}
}
Regist it as below:
services.AddDbContext<SomeDbContext>();
If you still got the error,please upload the minimal codes that could reproduce the error
I've been using asp.net core dependency injection and I have seen an not expected behavior, at least for me. I'm adding a new service to the container like this:
services.AddScoped<IMyClass>(provider =>
{
return new MyClass(
"anyValue"
});
After that, I inject the class into another class to use it:
public class AnotherClass(IMyClass xxx){
}
The thing is that there are a couple configurations that are made on the MyClass constructor based on request information. The problem is that I've seen the MyClass constructor be executed at the application startup only. After that, the class seems to use the same instance for all calls. As I'm using Scoped service I'm expecting to have a new instance for each request, am I wrong?
Thanks.
Ok. The problem was that the class that was receiving the injection was added to the container as singleton. I just changed it to Scoped and everything worked well.
Thanks!
I have created an ActionFilterAttribute
public class LoggingNHibernateSessionAttribute : ActionFilterAttribute
The purpose of the filter as name indicates is logging and opens and commits a transaction, before and after target action respectively.
I have a WebApi(myAPI) project (MVC4) and a WebApplication(myContent).
Each Api Controller in myAPI is decorated with this attribute.
using myApp.Web.Common.Filters;
namespace myAPI.Web.Api.Controllers
{
[LoggingNHibernateSession]
public class CategoriesController : ApiController
{
When a Http action (Get/Post) is executed inside the ApiController, the ActionFilter gets executed and it works fine as expected.
The problem:
In the WebApplication(myContent), I have decorated those controllers as well with the ActionFilter.
using myApp.Web.Common.Filters;
namespace myContent.Web.Content.Places.Controllers
{
[LoggingNHibernateSession]
public class PlacesController : Controller
{
But here, when an action is executed inside the controller, the ActionFilter is not getting executed.
The ActionFilter belongs to System.Web.Http.Filters;
I have read some posts, and they said to use System.Web.Mvc filters. So I changed the ActionFilter to be from System.Web.Mvc
And when I switched that, the ActionFilter stopped working in WebApi as well.
What am I doing wrong here?
Although WebApi and MVC are very similar and technically consist of largely the same code, WebApi was created by copying all the code rather than through reuse. This happened, I'm told, because the WCF team didn't want a dependency on the MVC assemblies.
Therefore, code (such as your custom filter) compiled against one assembly will not work in the context of the other.
The solution is to duplicate your own code and compile against both sets of assemblies. You could also set up a build system to cross-compile the same code files using different reference assemblies.
It's truly sad when internal company politics result in something like this. The least they could do was acknowledge the problem and add some proper cross-compile support to their tooling, but alas, I digress.
I'm using the WCF REST Template where services are implemented with just a class and registered in the Global.ascx (much like MVC controllers are).
RouteTable.Routes.Add(new ServiceRoute("Games/Games", new WebServiceHostFactory(), typeof(Games.Games)));
Games.Games has a ctor accepting a Dal.Games.IGames and I have a NinjectModule with the Bindings ready but I cant for the life of me figure out where to pass the kernel to to have it control the creation of the service classes.
My services dont have a markup (svc) file so I'm guessing that it will have something do with replacing the WebServiceHostFactory with one from Ninject. I was able to find one in the Ninject Web extension but just dropping that in didnt change anything not to mention I coulnt find anywhere to setup the kenel in that class.
Any solutions, hints or tips are greatly appreciated.
Let me preface this by saying, someone who actually knows inner workings of Ninject could probably provide a much cleaner solution. I've been wrestling with the same issue as you mentioned though.
Mostly through trial & error I determined that if you make the following code changes in the Ninject.Extensions.Wcf library, Ninject will work its magic on your service classes.
In NinjectServiceHostFactory.cs, i changed the base class and the type passed to .Get<T>
public class NinjectServiceHostFactory : WebServiceHostFactory //<-- Changed base class
{
protected override ServiceHost CreateServiceHost( Type serviceType, Uri[] baseAddresses )
{
var serviceTypeParameter = new ConstructorArgument( "serviceType", serviceType );
var baseAddressesParameter = new ConstructorArgument( "baseAddresses", baseAddresses );
return KernelContainer.Kernel.Get<NinjectServiceHost>( serviceTypeParameter, baseAddressesParameter );
}
}
In the NinjectServiceHost.cs i changed the base class to WebServiceHost.
Also, I added this reference to both:
using System.ServiceModel.Web;
I'm sure this solution breaks this extension for other WCF service types so hopefully a Ninject guru will come along and provide a real solution.
I have a plugin that I will instantiate at runtime and I want to pass it a WCF service from the application host. The application host is responsible for creating the connection to the service. The reason for this is that a single service can be used by multiple plugins, but the plugins should only know about its interface since there may be several implementation of IMyPluginServices. For instance, the Run method of the plugin instance would be:
public void Run(IMyPluginServices services)
{
services.DoSomething();
}
The problem I am running into is that I don't know how to create a service of type IMyPluginServices and pass it to the Run function. The service reference generated by VS 2010 doesn't seem to create an object of type IMyPluginServices that I can pass to it. Any help would be greatly appreciated. Thanks.
When you add a service reference in VS 2010 for a service it generates an interface named IMyService which contains methods for each OperationContract in your service. It also generates a concrete class named MyServiceClient, which can be constructed and then used to invoke your service.
Now, the problem that you're running into, I believe, is that MyServiceClient is a subclass of ClientBase<IMyService>, and does not implement the generated IMyService interface (which is a real pain).
To get around this problem I ended up making a new interface:
public interface IMyServiceClient : IMyService, IDisposable, ICommunicationObject
{
}
(Note: IDisposable and ICommunicationObject are only required if you want your module to be able to detect/react to faulted channels and other such things).
I then extend MyServiceClient with a partial class (in the assembly that contains my WCF Service reference):
public partial class MyServiceClient : IMyServiceClient
{
}
Now in my modules I can accept an IMyServiceClient instead of an IMyService, and still execute all of the methods that I need to. The application in control of the modules can still create instances of MyServiceClient as it always did.
The beauty of this is that your new interface and partial class don't need any actual code - the definitions suffice to get the job done.