2

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.

EhSan
  • 39
  • 6
  • `want to import this generated DLL in another project `, which way do you use to import the reference? Can add project reference helps for this situation? target .net core or .net framework? – LoLance Oct 30 '19 at 11:44
  • I do this: right click on Dependencies, then add reference, then browse for the generated dll and I add it. Once added, it appears under dependencies. – EhSan Oct 30 '19 at 11:46
  • target: .net framework – EhSan Oct 30 '19 at 11:47
  • See the answer here: https://stackoverflow.com/questions/42775876/nuget-packages-are-there-but-missing-references/42778916 Helped in my case – zed101 Feb 08 '21 at 07:40

2 Answers2

2

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.

zivkan
  • 12,793
  • 2
  • 34
  • 51
  • Thanks for the explanations. I appreciate it. I still wonder why is not possible to have a dll with all the dependencies? Suppose that I just developed that dll and I want to hide its functionality from consumers. It is also that I do not want to change the code anymore. On the other hand, I completely understand the process for nuget package creation and I know that after all it is working. But as you mentioned this is not a very easy approach to follow. Compare this with having just a single dll which could be simply distributed to any device which want to consume it. Am I wrong? – EhSan Oct 30 '19 at 14:08
  • You can, but the build system still needs to know how/where to find all the dependencies. Since both your dependencies are assemblies that are built into the runtime, you might be able to reference the assembly (no path or version) rather than package references, but it might depend if you're targeting .NET Standard. Another possibility is to put your assembly's dependencies in the same directory as your assembly, so [ResolveAssemblyReferences](https://github.com/microsoft/msbuild/blob/master/documentation/wiki/ResolveAssemblyReference.md) has a chance to discover them. – zivkan Oct 30 '19 at 15:50
0

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.

LoLance
  • 25,666
  • 1
  • 39
  • 73
  • Thanks for reply. But that is not what I want. I want to have a dll with all necessary dependencies and later on, consume that dll on ANY machine(not only mine). – EhSan Oct 30 '19 at 12:31
  • @EhSan According to your description, you need to create a nuget package from your referenced project. The created nuget package(you can consider it as a xx.zip file) will contain your assembly and the definitions about which nuget package your assembly depends on. Then any project in any machine consume your created package can reference those assemblies easily. – LoLance Oct 30 '19 at 12:54
  • Thanks. I confirm that Nuget package creation works for this case. However, I am still wondering is it possible to do this using dlls and not packages? – EhSan Oct 30 '19 at 13:57
  • If you want assmebly way without nuget packages, you have to manually copy and import the missing assemblies... I don't know any way to do this without using nuget... :( – LoLance Oct 30 '19 at 14:31