Develop Reference

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.

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.

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.

.NET custom dependencies (no nuget)

So, I'm having trouble adding a git project to my net Core solution, and after spending hours trying to figure this out and being uncapable of finding a solution online, I decided to ask here.
I have a forked github repo (link) in which I modified some files to suit my needs, but I simply can't seem to get it to work with my current project.
The problem I'm having is that normally, when I want a package for a .NET project, I usually simply go to nuget and fetch the necessary dependencies. This is usually very simple and straight forward. But now that I have these modified files, I'm unsure on how to proceed.
I have tried adding it as a submodule, but after I built the project, I got an exception saying that the dll could not be found.
Then I've tried adding the dll itself as a reference, but the ImGui.dll depends on a C dll which couldn't be found then (nor added to the project).
Finally, I've tried adding the csproj as a project of my solution, but that didn't work either
Do you know what am I doing wrong here? Am I missing a key piece or is it just something obvious I'm not seeing? It can't be this hard to get it to work

From the look of it, that repository produces a DLL (output type Class Library). So modify it to your liking, and use the sample program build (ImGui.NET.SampleProgram) to test your changes. Once you're happy, build the DLL project (ImGui.NET) and use the resulting DLL as a Reference in your own app.
In Visual Studio:
Solution Explorer>YourApp>References>Right Click>Add Reference...>Locate your DLL
This means you should also keep track of your modifications to the ImGui.NET project itself, since you may/will be required to maintain this in the future.
Hope this gets you started -- update your question with more specific issues once you're underway.
Edit:
Like #CoolBots mentions, I probably misread your question. Seems like the build depends on cimgui.dll, which you can hotlink from the ImGui repo along with your custom DLL. In fact, the demo app is using cimgui.dll, cimgui.dylib and cimgui.so. Regardless of linking method, you want the files to copy into your build folder. I don't believe subfolder /bin is necessary.
You can find all the cimgui dependencies for various operating systems in the ~/ImGui.NET/deps/cimgui folder.
The demo also utilizes NuGet packages Velrid and Velrid.StartupUtilities.
Depending on your own codebase, you may or may not require these NuGet packages along with the aforementioned class library.

Same Assembly Version in multiple mixed .NET projects (same solution)

I've got a problem with setting up one "Shared" assembly info in my solution. I need one place to change assembly version for every project in the solution (currently > 25 project).
The problem is, that the solution contains C# projects as well as VB.NET projects - because of that, I am not able to create ONE file with assembly version (I cannot include C# files in VB.NET project and vice versa...)
Is there any way to solve the problem ?

You can use a Shared Assembly Info using file linking.
Here is a nice article from Ashish Jain:
https://weblogs.asp.net/ashishnjain/sharing-assembly-version-across-projects-in-a-solution
If the VB Project does not allow linking with the SharesAssemblyInfo.cs then we could create another library with SharedAssemblyInfo.vb.
If duplication is not wished for then a library called SharedAssemblyInfo can be created in C#/VB with public properties. These public properties could then we referred to in both C# and VB projects in their respective AssemblyInfo.cs files

Two projects with same dll, Cast issue

Hi fellow programmers,
I'm creating a ControlLibrary for future project's that uses the amazing MaterialDesignXaml library. In this ControlLib I use the MaterialDesignThemes.dll that contains several styled controls, resources and classes.
Now my problem is that I need to use the same dll's in the real application (sae sollution for now). If I want to use the mentioned control library in this project (as project reference) I always get this error:
Dll Error in Application Project
.
I understand the problem the compiler has with this, since It cannot check if two refrences (from seperate projects in the sollution) are the same dll. But how can I fix this?
The strange thing is that the designer complains like in the screenshot, but the application runs just fine...
I'm using TortoiseSVN for Version Management, maybe this has to do something with it?
Any idea's?

How to pack referenced libraries into a new libarary

When creating a new library MyAPI.dll, I am referencing many other (non-standard) libraries such as RestSharp.dll, Newtonsoft.dll,MyUtilities.dll, etc. My library works fine in my development environment because I've downloaded all of those other libraries and they're sitting in my project's bin folder, but as soon as I try to publish that library and use it in a new location, it fails because the referenced libraries cannot be found.
How to I set up my MyAPI.csproj project so that these dlls/libraries get packaged into my published .dll file, and future users of MyAPI.dll don't have to worry about downloading and referencing those dependencies?
Thought this would be simple, but my google-fu is weak today. Setting those external references to CopyLocal = False removes them from the /bin/ directory, giving the illusion that they are getting packaged into MyAPU.dll, but really Visual Studio is just adding them to my Global Assembly Cache (GAC), which doesn't help future users of the API.

There are two options (as far as i know):
ILMerge
Embeded Resource and Assembly.Resolve (see Jeffrey Richter)
First you can use ILMerge, which is comamndline program that can merge multiple .NET assemblies together, creating one output file. It cant merge WPF projects. Can be added to postbuild events to make the merge automatic.
Second is adding library as embeded resource to your project, and then registering to Assembly.Resolve event and loading assembly when its needed from resources. Article from Jeffrey Richter about this method: Jeffrey Richter.
The second method has major drawback, it doesnt work with merging multiple libraries into one (it can only be used for adding libraries to executable), at least in c# without another tool. To add library to library you have to use another tool, which is mentioned in Jeffrey's article comments at second page: (Module initializer injection).The problem with embeding library into other library is that you cant (at least in c#) register to Assembly.Resolve event before the embeded library is needed, so you need to inject the registering to module initializer using the Module initializer injection. It can also be set as build event, which is written on the apge with the tool. It may sounds complicated, but once you set it up its easy.

There is a free nuget package "Costura.Fody" it packs dependency assemblies as resources into your assembly. The solution works with WPF and other managed assemblies.
If the dependency assemblies are not in the executing folder, the packed assemblies are taken automaitcally. It also configures your msbuild targets automatically for packing the dependencies during build. You do not have to add code in your assemblies.
It also lets you configure, which assemblies to pack or not in a xml file.
It uses a combination of two methos:
Jeffrey Richter's suggestion of using embedded resources as a method of merging assemblies.
Einar Egilsson's suggestion using cecil to create module initializers.
You can find documentation here: https://github.com/Fody/Costura/blob/master/README.md

It's not free (well there's a trial) but a friend of mine told me about a program called .NET Reactor, which has the ability to package an exe with dependent DLL's into a single executable, well worth a look.
I would say the next most straight-forward alternative would be ClickOnce, a good tutorial is here.