I'm developing tool that migrates issues from old to new issue tracking system. I have separated everything with interfaces, but I'm not sure what's the best way to glue it back together. I have 3 dependencies, that require runtime data:
These 3 dependencies are dependencies of many others. I couldn't figure out other way to glue everything, than registering these 3 as singletons (via DI container). I also know, that singletons are considered a bad pattern, so I'm considering switching to abstract factory.
Example relationship which forced me to use singleton:
INewSystemClient requires runtime data like user, pw, host etc.
Should I switch to abstract factory and make factory create objects instead of DI container?
I think you are confusing terms just like a Singleton pattern (most say it's an anti-pattern now) is not the same as a singleton instance in your IOC, an Abstract factory pattern is not the same as a DI factory. What you need to think about is scopes or when the object is created and disposed.
In your desktop app there can be multiple scopes in which you can register an object (On an App level or "a singleton", on a Module level, on a thread level, on a Page level...) This usually depends on the framework you are using (Prism, MvvmLight, caliburn.micro...) if you are building you own system you might want to look how some of the other frameworks did it. I know Unity has a cool way of handling factories and lazy initializations.
Usually a singleton instance is best used for stuff that won't be accessed in multiple threads that will change some values. This is when you need to create locks and you can slow things down in a big way like blocking your UI thread. For example if you have an HttpClient that just call a single backend api that every one can use it would make sense to make it a singleton scope.
If for example you want to write to a database you might want to have a different EF context per page so the entity tracking doesn't happen on two page.