CODEWITHSUNDEEP
c#.netdlldependenciesnuget
EhSan
EhSan

Reputation: 49

Missing DLL's own dependencies in consuming projects

I created a class library project using C# and .Net.

In this project I used two external dependencies(to be more specific: Microsoft.Win32.Registry(4.6.0) and System.Data.SqlClient(4.7.0) Nuget packages).

After I build this project, I can see the generated DLL file under /bin/debug folder.

Now I want to import this generated DLL in another project and consume its methods. Once imported and I run this project, it complains about not being able to find those two external dependencies I had in class library project.

As a temporary fix, I can import these two missing references in this project and it will work fine and as expected. But this is not what I want(and I guess is not a clean solution as well).

I want to know why the dependencies of class library project is not reflected in generated dll file? And is there any way to fix this?

Many thanks for your help.

Upvotes: 3

Views: 2955

Answers (2)

zivkan
zivkan

Reputation: 15082

If your class library is in the same solution or source control repository as the app that's using it, you should use a project-to-project reference, rather than referencing the assembly directly. As the docs say, this way it automatically detects changes to the class library when you compile the app, but what the docs didn't say is that dependencies flow though as well.

Otherwise, as Lance Li wrote, you should create a NuGet package from your class library. Unfortunately there's a bit of a barrier to get started. Creating the package is easy, but then you need to publish the nupkg file somewhere. For early development (before the package is ready to be shared), the easiest option is to use a local file feed. You'll then need a nuget.config in the app that will use the package to add that local feed as a source, then you can install the package in your consuming project, which will bring dependencies.

As you can see, for development, this is slow and difficult because if your consuming app finds a bug in your package, or if you're trying to develop a new feature in both the consuming app and class library at the same time, it means every time you make code changes to class library, you need to increment the version number, pack a package, publish the package, then update the package version in the consuming project. It's far, far easier to use a ProjectReference which lets you simply edit code, compile, run. Nothing else to think about.

Upvotes: 2

LoLance
LoLance

Reputation: 28216

See this, the way you reference that assembly is not a recommended way when both the projects are in same machine.

You're using the file reference(Add reference => browse...). And that's why you have to import these two missing references in this project manually.

So I suggest you add the project reference, if both the two projects are in same solution, you can right-click current project=>add reference=>project tab find that assembly you need.(instead of browsing...)

If the referenced project is not in same solution. Right-click solution in solution explorer=>add existing project to import it. Then add project reference.

Upvotes: 0

Related Questions