We Keep Coding

.NET Inject transient into singleton

Suppose I have a singleton service that needs to receive other objects via constructor injection.
What should be the lifetime of these dependencies, they should also be added as singletons?
Are any drawbacks for injecting transient services into singleton objects? I am thinking that even they are transient they will be in memory until the app shuts down because they are injected into a singleton object.
How do we handle such cases?

This doc has some guidance on the matter: https://learn.microsoft.com/en-us/dotnet/core/extensions/dependency-injection#service-lifetimes
In general I think the standard guidance is to ensure dependencies are registered with longer lifetimes than dependents. If you break this model, you run the risk of causing bad state between requests.

ASP.NET Core 2.0 service life time

I have api application ,service & repository class library application . Service part i write business logic and repository only communicate for database. My question which type of dependency is best for repository and service .
services.AddScoped<ITicketRepository, TicketRepository>();
services.AddTransient<ITicketRepository, TicketRepository>();
services.AddSingleton<ITicketRepository, TicketRepository>();

Like always, it depends. My suggestion is the following:
Scoped: in my opinion, there can be two main reasons for using this:
Your dependency has a dependency which has a scoped lifetime. In this case, you cannot use singleton, but can use scoped or transient. Which one you should take is based on the other criteria.
Your dependency has some state which makes it unsuitable to be used in singleton scope, but it is heavyweight enough that you don't want to register it as transient. Another possibility is that, again, it cannot be used in singleton scope, but it is fine to share the same instance per request (scope) and you don't want to add the overhead of constructing new ones if two types depend on the same thing and both of them are used to serve a single request.
Transient: this is the simplest approach. Every time an instance of a dependency registered in this manner is required, a new instance is created. This is probably the most foolproof, but can cause serious overhead if its usage is not justified. #Tony Ngo pointed out in his answer, quoting from the official docs, that this works best for lightweight, stateless objects, but I'd argue that statelessness is a very good indicator that you may want to use singleton lifetime as statelessness guarantees that the same object can be used concurrently just fine. Whether you choose transient or singleton lifetime in this case really depends whether you care about such aspects of performance like GC cost, which is obviously much, much higher if you create a new instance every time such a dependency is required, even if you could avoid doing so. Having said that, transient is used by many developers in this scenario as well, probably due to its foolproofness, or simply because they tend to think about it as the default choice.
Singleton: the points above basically summarize this one: you can choose this when there is absolutely no reason to create a new instance of the dependency for each request (scope) or to use an other dependent instance. Note that like said before, you cannot use singleton lifetime when the type has a dependency which is registered as scoped.

Transient lifetime services (AddTransient) are created each time
they're requested from the service container. This lifetime works best
for lightweight, stateless services.
Scoped lifetime services (AddScoped) are created once per client
request (connection).
Singleton lifetime services (AddSingleton) are created the first time
they're requested (or when Startup.ConfigureServices is run and an
instance is specified with the service registration).
So depend on what you need you can choose correct liftetime you can view it more here

I am assuming your TicketRepository is depend on your EF Core DbContext and your
EF Core DbContext is by default registered as ScopedSerivce so here registering TicketRepository as SingletonService is out of consideration as because:
It's dangerous to resolve a scoped service from a singleton. It may cause the service to have incorrect state when processing subsequent requests.
For more details: Dependency injection in ASP.NET Core-Service lifetimes
Now you can choose between AddTransient<> and AddScoped<> where:
Transient lifetime services (AddTransient) are created each time they're requested from the service container. This lifetime works best for lightweight, stateless services.
Scoped lifetime services (AddScoped) are created once per client request (connection).

IOC/DI CastleWindsor returns same instance every time

The project am working implements IOC/DI using castle windsor. There are many modules in project. There is a module called ProcessEngine that send the Invoices to my module for Automatic Process which involves 7 steps.
Up to now ProcessEngine module use to send Invoices one by one as in a queue and my module worked perfectly. But now ProcessEngine send many invoices that are ready by spanning them in different threads each invoice having there own thread so the problem arises.
The problem I see is that the instances are created by using Castle Windsor and it returns the same object everytime. That means all threads are having same instance and it creates the chaos. Then I created instances of major classes that have some private properties by using new keyword and it worked fine.
Is there any way I can restrict Castle Windsor container to return new instance everytime for some of the classes of my module? It is Architecture guideline of the project that object must be instantiated using Castle Windsor not using new keyword. Is there any solution for this?
Any help will be highly appericiated. I dont have much knowledge of Castle Windsor but I observed It is kind of Singleton Pattern as it returns same object everytime using Castle Windsor.

You need to check lifestyles.
Default behaviour is singleton, which means it will indeed return the same instance when you ask for resolve.
You can use PerThread or Transient lifestyle.

Limit instance lifetime to a single iteration

I'm working on a web application that uses a couple of services to synchronize data with external resources. The application and the services share the same data layer and use Castle Windsor to implement IoC.
In the web application there is the a PerWebRequest lifestyle which limits the lifetime of an instance to the lifetime of a request. I want to use something similar in the services.
The services are triggered every once in a while to do the synchronization. I want the services and repositories in the datalayer to be singletons within the a single iteration of the service, similar to the PerWebRequest lifestyle in the web application.
What I've come up with is the concept of a Run. A run is a single invocation of the synchronization code within the service. That looks like this:
using( _runManager.Run() )
{
var sync = _usageRepoFactory.CreateInstance();
sync.SynchronizeUsage();
}
The implementation of IRun will release all instances with the PerRunLifeStyle resolved since it's creation when it is disposed, at the end of the using block.
This code looks quite clean, but I wonder if there is a better way of doing this. I have tried using child containers but found these rather 'heavy' after profiling the solution.
Any feedback is welcome. If needed I can post the IRun implementation as well.
Update
Based on the comments I've cleaned up the code a bit. I've introduced a new service IRunManager which is basically a factory for IRun. I've also started using a factory to get rid of the ServiceLocator invocation.

Take a look at this contextual lifestyle

Why does Castle Windsor hold onto transient objects?

Recently I noticed my application appears to be eating memory that never gets released. After profiling with CLRProfiler I've found that the Castle Windsor container I'm using is holding onto objects. These objects are declared with the lifestyle="transient" attribute in the config xml.
I've found if I put an explicit call to IWindsorContainer.Release(hangingObject), that it will drop its references.
This is causing a problem though, I wasn't expecting that with a transient lifestyle object CastleWindsor would keep a reference and effectively create a leak. It's going to be a rather mundane and error prone task going around inserting explicit Release calls in all the appropriate places.
Have you seen this problem, and do you have any suggestions for how to get around it?

I think the answers here are missing a vital point - that this behavior is configurable out of the box via release policies - check out the documentation on the castle project site here.
In many scenarios especially where your container exists for the lifetime of the hosting application, and where transient components really don't need to be tracked (because you're handling disposal in your calling code or component that's been injected with the service) then you can just set the release policy to the NoTrackingReleasePolicy implementation and be done with it.
Prior to Castle v 1.0 I believe Component Burden will be implemented/introduced - which will help alleviate some of these issues as well around disposal of injected dependencies etc.
Edit:
Check out the following posts for more discussion of component burden.
The Component Burden - Davy Brions
Also component burden is implemented in the official 2.0 release of the Windsor Container.

One thing to note is that this seems to have been fixed in the Castle Trunk. In r5475, Hammett changed the default release policy in MicroKernel to LifecycledComponentsReleasePolicy.

You can set a lifestyle of singleton or transient though on objects in the container. Singleton objects I understand should last the life of the application, but I don't understand the usefulness of this behvaviour being the same for transient ones!
Custom lifestyles can be created by implementing ILifestyleManager. Maybe it's possible to implement this suitably to create a ReallyTransient lifestyle type!