Generic Repository, UnitOfWork and IOC container
First, I would caution against using the generic repository + unit of work pattern that was super trendy a few years ago because it has problems not unlike the problems you're facing (along with problems stemming from the fact that EF crosses traditional DAL/Domain/BL boundaries). Simply put, I would not use repositories with EF unless absolutely necessary, and if I had to, I would not use the generic repository pattern.

If you're hell-bent on using this pattern, then you will need to understand the origins of the problem you're facing. Because you have a generic type being returned by your UnitOfWork "factory," you aren't able to instantiate it during your bootstrapping, you are being forced to to instantiate it on-demand at runtime, resolving using the type you're using in your UnitOfWork method call. 

If you are okay with using the same repository instance for all of your resolutions, then just make your objects require Repository&lt;SomeType&gt; in your object constructors or properties with public setters, then use RegisterGeneric(). You can see how that is used here. This bypasses the entire "at runtime" requirement. 

If you want to maintain the pattern of fetching a repository using a method, then you need to treat your UnitOfWork class as a factory and use dynamic instantation.