-
Notifications
You must be signed in to change notification settings - Fork 10.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dependency injector doesn't resolve my repository (Debian and SqlLite) #1816
Comments
How would you expect the repository to be injected when you haven't configured it anywhere? |
Sure ! Sry, i forgot this line in my startup.cs : |
Can you update the example with your overall code (add the missing line). Also where is the definition for BaseRepository |
Yes, Here my BaseRepository
(My BaseController methods are under construction) And my Startup.cs
Maybe it would be easier if i create a public repostiory to share you my code ? |
I think you need to inject |
Also, that can't possibly be all of the exception? If that's the case, then the built-in container has some serious diagnostic problems. |
You said that you forgot the line in |
Ah ! Thank's ! You found my mistake ! I injected DbContext, not ApiContext... PS : I tried to watch what my container contained, but I am not all that familiar yet with debugging under Debian |
* Refactoring and of FrameConnection and Frame - Building on top of the last refactoring of FrameConnection, this change aims to clean up the communication between the Frame and FrameConnection by removing some concepts and being consistent about the communication between Frame and FrameConnection with or without connection adapters. Changes include: - Removing ConnectionLifetimeControl, ISocketOutput, StreamSocketOutput - Moving more initialization of the frame to FrameConnection after the pipes are setup - OutputProducer communicates cancellation via the IPipeWriter instead of the output's IPipeReader. - Frame always communicates via the pipes and that communications flows through the layers to the transport. This means that each 1/2 of the adapted pipeline handles closing the right side of the transport at the right time, propagating exceptions as necessary. - This is how the flow looks now: -> -> [transport] [connection adapters] [frame] <- <- - Transports need to handle a ConnectionAbortedException on the output as a signal to stop writing and end the connection. This will no longer try to drain the output but will just stop writing and end the response immediately. - Remove frame.Abort when cancellation on Write fails. - Unify the connection shutdown logic - Dispose 1/2 initialized connection adapters #1815
- Renamed StreamPipeConnection to PipeReaderFactory - Flow the transport cancellation token to the CopyToAsync routine - Other small cleanup and nits to make the style consistent with the other pipe reader loops - Return a cancelled ValueTask from PipeWriterStream.WriteAsync - Move event stream request to start itself - We no longer need to pass the tcs through. - It also cleans up handling failure in start since the application pipe hasn't been read or written to
Hi !
I got a probleme with Net.Core 1.1 dependency injector.
In my project (under Debian) i got a simple architecture:
I have a Generic Base Controller
BaseController.cs
And One Controller (the method Get() is the one called when error occurred)
ThemeController.cs
I use SqlLite and i defined my context like this :
ApiContext.cs
And finally my Startup.cs
My Repository is not resolved.
I got this error when i call the URL ---> /api/themes
The text was updated successfully, but these errors were encountered: