Develop Reference

Different DLLs, different project, same version and name between each, both invoked from the same Console App

I have two DLLs with separate code inside them, but with the same NAME and same VERSION. Neither of these can be changed. They are in two separate C# projects, which do not reference each other, but are instead class libraries loaded within the same Console app. I've got a small diagram listed below.
When running the app it seems to take one of these in compilation, seen in the output directory, and thus throws a reflective exception trying to call code from the other DLL in the code of the second class library. In Visual Studio, everything seems fine in the IDE - and references the contents of each DLL as different per library project.
I was wondering if there was any way to get this working without editing the DLLs at all, like a build step that I can set up easily, to ensure these DLLs aren't confused with each other, so to speak.
To clarify, many other questions on this platform question have different versions of the same named DLL. In this, identifiers like the name and version are identical - what's not, is the code inside each. I know this should never happen unless you're doing something really hacky.
Thanks in advance!

Reference seemingly not working, no apparent error thrown

I have superficial knowledge on referencing libraries in projects. Usually most of the time a simple 'add reference' and then browsing to the appropriate path, just works. I am following an issue I will try to explain , and show all the approaches I tried to tackle it.
I am trying to use AutoIt. In their website it is stated that simply adding the .dll and using it, is enough to integrate their functionality in visual studio.
I am doing just that but for the moment I can not get my head around what is happening.
AutoItX is a public static class, as also the Run function is the same (public static). After adding the reference I can navigate to the appropriate .cs (if I control click on it for example). So the class AutoItX is not something unknown for the project. Moreover, the function Run indeed exists
however not inside the project itself. AutoItX also needs staff from (dont know if it is important):
The main error is that AutoItX doesnt exist in this context.
I have tried to register the dll, I have tried to add the com reference and remove it, I have tried to move the .cs files inside the project. None of those corrected the issue.
Any help would be valuable. If I missed something and you need extra info, I am willing to provide it. (Latest vs, latest autoit version, .net framework type of project).

Actually the above works.
For future reference.
The reason I did not try it first was, that they propose in their website to reference the autoItX.assembly.dll. This is probably deprecated and does NOT work anymore.
Second, if you have already referenced it , downloading this from NuGet WONT fix it.
Finally, the NuGet package does NOT work with .net CORE but ONLY with .net Framework project

I installed AutoItX.Dotnet 3.3.14.5, my test is no problem.
You can refer to my steps to create a new project to test it.
Right click References=>Manage NuGet Packages=>Browse=>AutoItX.Dotnet=>Install
Running result:

Use .dll to store other .dlls or .libs

I am using Visual Studio 2010 and I'm trying to create a .dll. My .dll uses an external library .lib. This Library also contains a collection of other libraries (.lib).
So: My main.lib is a container for the collection of libs - and as a result it is about 300mb big.
Now when I use the lib in my dll, its linking fine and it works correctly on my pc. But when I deploy my compiled program to another computer, then it couldn't load the .lib. It simply can't find it, even when I've put it into the directory of the .dll.
Now my question: Is there a way I can store all functionality of my .lib in a .dll? So that the .dll file will be about 300mb big but I don't need to deploy the .lib anymore?
Update:
Thank you all very much for your answers. To descripe my problem I want to show you this output of my program:
Unhandled Exception: System.Runtime.InteropServices.SEHException: External componennt has thrown an exception.
I've spent many hours of using google to solve this error. I've found out that it's a problem with a missing file (one of my "external components" (.dll)) couldn't find definitions of classes and so on or otherwise a problem with access rights.
I tried my best to fix this and with one try I had success and could use this program. I know that this is because I have put the main.lib into the right folder, so my program could find it. But now I don't know where to put this main.lib. So: my program is broken again and now I want to fix it... I hope this description helps. It's hard to describe it because I don't know exactly what the problem is...
Update 2:
Thanks to your help I solved my problem. At first I misunderstood the principle of how .dll's and .lib's are working. If anyone else has this problem and will be redirected to this post then #D Stanley's answer will help.
Thanks to #David Heffernan I've found out that it's not any missing .lib or something else which is causing this error. It's a problem in my native C++ Code (which is in the .lib). So I fixed this problem (which caused an exception) and now everything is working fine.
Thank you all for your help.

You can not statically link static libraries in other static libraries. What you should be doing instead is statically linking all those individual static libraries in your DLL. Does the linker not warn you about this?
Also, you can't deploy static libraries to another machine, as they can't be linked at run time.

If I understand your situation:
You have several static libraries (.lib)
They are linked together into one big static library (main.lib)
You want to use this library in your dynamic library (.dll)
I'm not certain what's happening locally, but lib files are not "loaded" at run-time - they are linked into either a dynamic library that is loaded at run time (hence the name "dynamic" or into the executable itself. So if your application is working now, then either you're already linking part of it into your dll or it's getting linked into the executable.
So to answer your question, yes, you can link your lib file into your dll - and it will include all of the necessary object code into it. Note that it may not be as big as the source library - that depends on how much of the original code is used by your library.
I also don't see how c# is part of your situation.

From your description it seems that you are linking with *.lib stubs that accompany DLLs for their static loading. You have those DLLs on your computer but not on other computers where you try to use your DLL. So to make everything work, find and copy those DLLs together with your DLL.

Namespace Reference Bug (or me being an idiot)

I have a solution that contains to class library projects named "CompanyName.Data" and "ComanyName.Utilities".
If I create another class library project and reference the two projects, everything works fine. If, however, I choose a web app then, despite adding the reference, the other namespaces cannot be referenced in the project.
It's as if I haven't imported the namespace or done the reference at all.
FYI, I'm running VS2012. Any advice? Am I missing something obvious? I'm going to do some more experimenting.
Regards,
Chris.
UPDATE: The issue seems to not be a web app but be when the web app project is named "Company.Something".

For anyone who reads this and thinks the same. This 'feature' is by design. It's a safety measure to prevent clashing against the plethora of namespaces created in a web application. I don't quite understand myself, but that's the official word.

How do I compile C# code as a library instead of an executable?

I have a C# console application in Visual Studio 2010. It has a Main() method as well as a bunch of utility classes. I'd like those utility classes to be available to other solutions. From reading online it seems that I need to compile it as a Class Library (DLL). So here's what I did:
Went in Visual Studio to "Project > [ProjectName] Properties > Application" and changed "Output type" from "Console Application" to "Class Library"
Rebuilt; ProjectName.dll was created in bin/Debug.
Created a new Console Application
Solution Explorer > Add Reference > browse to ProjectName.DLL, select it.
However, neither IntelliSense nor the Object Browser could find the classes inside that DLL.
I tried recompiling several different Console Applications as Class Libraries and got the same result. I also noticed that it works if I initially create the solution as a Class Library, but not if I convert it to one later.
Any tips?

You do not need to build it as a dll. VS 2010 (and IIRC 2008) allow referencing exe assemblies. All you need is for they relevant types to be declared public - top-level classes defualt to internal if you don't add a specifier.

You can switch output type to Class library in project properties as well - then you will have an output as dll instead exe file

What I've always done (since this is what you do with C++ static libraries, which is what I normally use - though I think it has some advantages for C# too) is add the class library's project to the solution, then add a reference to it in the project (or projects) that uses it.
When you go to add a reference, the list of potential references includes items from the solution, so it should be fairly obvious what to do. You should then get intellisense for your library.
One advantage of doing things this way is that if you need to edit files in the library project, it's very straightforward because they are close to hand, and the project then gets rebuilt automatically when you compile the solution.

Make sure that the classes in your dll project are public.

At first, from the point of view of managed libraries it does not matter what kind of Output type is your managed library. I mean that you can successfully reference ConsoleApplication1.exe from ConsoleApplication2.exe project (so you have no reason to convert ConsoleApplication1.exe to ConsoleApplication1.dll).
At second, I've tried to reproduce your situation, but... without effect. My VS displays types/methods from ConsoleApplication1.dll. One reason I can suppose is that you have forgotten to set visibility modifier (public keyword) for your utility classes.