Is it good practice to bundle all required managed dlls as embedded resources to a .NET library project in order to ship just one dll?
Background: I have created an API as a .NET dll (in C#), and it's working all fine. But the library has quite some dependencies on other managed libraries (around 15 dlls) so I need to distribute those as well.
When the users of my API have created an application they again have to make sure to distribute all those dlls along with the application. To me it would seem better if they had just one dll to consider.
The main downside I can see to using embedded dlls is that they must be unpacked to a temporary folder before being loaded dynamically, which may or may not have performance and robustness issues.
There are a lot of questions around this. What happens if you're expecting to load a platform-specific dependency (i.e. x86 vs. x64), or that's true about the app consuming your API? Does that mean that you need to include specific x86 vs x64 assemblies in your package as well? It becomes hairy quickly.
You should consider using ClickOnce deployment for these types of scenarios. Then, all of the dependencies would be packaged together.
Realistically, it's a problem for the API consumer to solve, not for the API producer. Your API might be less popular if it has a lot of external dependencies, but you'll have to make decisions there about what's really crucial to your API's success.