We Keep Coding

C# Adding a reference to a class in another project without referencing the project

I have two projects:
ProjectMain (class library)
LibraryProject (class library)
ProjectMain is a class library that should only be compiled as a singular library, no referenced libraries. I require a static class reference from LibraryProject BUT I don't want the LibraryProject assembly to be compiled together with the ProjectMain assembly.
I've tried 'link references' in visual studio but this is no solution as the library assembly is always compiled with the main assembly.
There are clear standard solutions to this issue but I am severely limited by the existing implementation requirements. Only one DLL can be compiled without any of the dependent assemblies being in the execution folder, GAC, private path, reflection etc.
The exact limitations are as follows:
Assembly executed in a sandbox from a third party provider, it only supports adding a single assembly with no direct references/reflection etc (it's horrible but my hands are tied)
We would like to handle the code organisation as best possible which means following standard best practices, unfortunately, due to the above limitation that's proving difficult.
What I would like to know is if there is a way to reference a class within another project without also compiling/using that referenced classes assembly. Possibly a method where the compiler 'embeds' the referenced class at compile time.

If your sandbox does not allow loading other dlls in AppDomain, load it yourself by embedding it. You can use Costura.Fody for this purpose, it is easy to use/install, just reference it from nuget.
Of course, embedding it in every scenario is madness and often comes with completely obscure bugs, which often solvable only by enabling traces in regedit.
So, in your case I would create two projects:
MyDll.csproj //it is my original project, with perfect code design and etc. Lovely.
MyDll.Sandbox.csproj //this one is the same as MyDll.csproj, except it is compiled with additional Costura.Fody reference, into single dll (every reference is put inside)
This way you just need to maintenance that MyDll and MyDll.Sandbox files are the same.

In .NET, when do I have to reference a DLL that an external library also references? [duplicate]

This question already has an answer here:
Can you use a class library if you don't reference all of it's dependencies?
(1 answer)
Closed 5 years ago.
I'm trying to understand when it's necessary for my .NET project to reference a DLL that an external library references.
A practical example: Microsoft.Bot.Builder depends on Chronic.Signed.dll
If I reference Microsoft.Bot.Builder.dll, do I always have to also add a reference to Chronic.Signed.dll in my own project, even if I'm not using it directly? Or do I only have to only under certain circumstances?

If I reference Microsoft.Bot.Builder.dll, do I always have to also add
a reference to Chronic.Signed.dll in my own project, even if I'm not
using it directly? Or do I only have to only under certain
circumstances?
When you add packages using NuGet, dependent packages are also installed with them. So when you will add Microsoft.Bot.Builder.dll it will automatically install the Chronic.Signed.dll as well.
Now comes the part, Why? Some lib packages are dependent on other packages. Like a function in Microsoft.Bot.Builder.dll might be using some helper or main function from Chronic.Signed.dll. So if you will remove the reference of Chronic.Signed.dll you will will get error of missing dependency or reference.
do I always have to also add
a reference to Chronic.Signed.dll in my own project, even if I'm not
using it directly?
Yes, Because Microsoft.bot is using it internally.
Not all packages depends on others. Some are independent and never install any other dlls but some do.

You need to do this when you make use of something in Microsoft.Bot.Builder that exposes something from Chronic.Signed in its public API. For example (and without going through the libraries myself), let's say Chronic.Signed.IFoo is an interface that Microsoft.Bot.Builder.FooImpl implements. If you reference Microsoft.Bot.Builder.FooImpl in your code then you also need to reference Chronic.Signed so that your code has access to the interface.

Unless you're referencing specific things from those packages, you shouldn't need to. If you're missing a dependency which would cause your code to be unable to compile or run, the compiler will most likely complain about it.
Just as a simple example of when multiple DLLs need to be installed, when you're installing packages through NuGet, sometimes packages will have dependencies that will install in order to be able to run the code in the package. However, most of them will install independently of any other packages. You can test the how this works across projects by putting some references in a library project that don't exist in another project, and then trying to run the code from the main project. You shouldn't need to reference the same DLLs as the library project.

How to correctly resolve DLL references through class libraries without adding the reference to the calling project

TL:DR How do I reference an assembly only in a class library rather than both the library and the calling project?
I am building a utility library in C# in order to promote code reuse. In this instance, I am wanting to do something things with a TFS server and need to reference several assemblies from the TFS side of things:
Microsoft.TeamFoundation.Client
Microsoft.VersionControl.Client
Microsoft.WorkItemTracking.Client
I include these references in the class library called, say, Utility. I then proceed to wrap objects in those assemblies in helper objects. There are no errors, intellisense works correctly, and so forth.
When I want to use that class library in another project inside the same solution, say, TestCLI, I add a reference to the Utility project by selecting the project from the solution references tab. I can then use the Utility classes without issue, until I go to build.
When I build the solution, it throws an error such as:
The type 'Microsoft.TeamFoundation.VersionControl.Client.BranchObject' is defined in an assembly that is not referenced. You must add a reference to assembly 'Microsoft.TeamFoundation.VersionControl.Client, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
In the past, I have worked around this issue by adding the same references to the calling project (TestCLI) in addition to the class library (Utility). I feel that this is defeating one of the purposes of having a class library and that I've missed a step in order to not have to worry about library references in my calling project.
Is there some way to resolve these dependencies without including the references in both the class library and the calling project? Am I structuring my solutions incorrectly? Am I thinking about class libraries in the incorrect manner?

The references are required because you are exposing objects from the other libraries, and then to use these classes the final program needs the references.
To avoid this you must hide the external objects, through a wrapper, a copy of the class or anything else, it depends primarily on what and why you are exposing those objects.

Adding references for code moved into a class library

From a solution, which I made in Visual Studio 2013, I want to transfer a method to a DLL (class library project).
When I paste the method in the DLL project, it doesn't recognize parts of the code and it's showing this error`:
"are you missing a using directive or an assembly reference?"
Because of that, the DLL can't be built. I am assuming, that a certain reference to the solution is required, but I am not sure how to proceed.
I know how to add a reference from a solution to a DLL, but I'm not sure how it's done the other way around or even if it's possible.

You can't add reference to EXE from class library (assuming EXE uses that class library) as it will introduce circular reference.
Usually you need to refactor all dependencies so class library either have them all or allow application to inject dependencies from EXE/other clients. In later case class library needs to define base classes/interfaces to allow such injection.

Yes, you need to restore the same references that the original project uses, if they are used in the code you want to move.
If you need to do this by hand (i.e. without tools like ReSharper):
Move the code to the new assembly.
For each namespace or type giving the error, find it in the Object Browser.
Locate the assembly containing that namespace and type, and add a reference to that assembly in your new project.
You may also have to add a Project Reference to the original project.

Requiring library consumers reference additional assembly when using certain types

I have library code that uses ICSharpCode.SharpZipLib under the hood to make it easy to use ZIP files as data sources when running integration tests.
As it stands, if I reference my library from another project, the other project will compile just fine, but when it accesses the code that uses SharpZipLib, I get an exception for it not finding the zip library:
failed: System.IO.FileNotFoundException : Could not load file or assembly 'ICSharpCode.SharpZipLib, Version=0.85.5.452, Culture=neutral, PublicKeyToken=1b03e6acf1164f73' or one of its dependencies. The system cannot find the file specified.
If the types in my library derived from a class in SharpZipLib, it'd generate a compile error CS0012. What other ways are there for triggering a CS0012, so that using code that requires SharpZipLib (but doesn't clearly indicate it) would cause consumer code to fail compilation?
I've had similar problems in the past when I've used libraries like DeftTech.DuckTyping under the hood. I'd add my library code to a new project, start working, compile, run, and then suddenly hit an edge case that I'd used duck typing to get around and get a runtime error.
What I'd most like is to have the same behavior as if I'd derived from a type in the 3rd-party library, so that a reference to my derived type generates a CS0012:
The type 'type' is defined in an assembly that is not referenced. You must add a reference to assembly 'assembly'.

You only get compiler errors if you are DIRECTLY interacting with libraries that aren't referenced.
If you use other libraries that internally use a third party library then you will never get a compiler error. The reason is this just doesn't make much sense having a compile error because:
It does not affect compiling at all, so why a compiler error?
Your application MIGHT run correctly, because there is no guarantee the third-party library EVER gets called.
It might actually break several libraries, that e.g. do reference external libraries for debugging, but just don't ship them for release.
Edit: If your problem is that you are forgetting about the third-party library you can simply reference it directly from your application even if you never use it. Then e.g. Visual Studio will automatically copy it to your output bin folder and includes it in setups, and so on.

If you're seeing this while in Visual Studio it's probably because the ICSharpCode.SharpZipLib.dll isn't being copied to the build folder of your "other" project.
So this won't be a problem when you distribute your library for consumption by third parties because the ICSharpCode.SharpZibLib.dll will be in the same folder as your library.
During development and testing though it can be a bit of a hassle. Generally when setting up a multi-project solution I just have all the projects target their Output folder to a single solution-wide Build folder. That way all the dependencies are copied to the same location for testing.

You just have to copy ICSharpCodeSharpZipLib.dll to C:\Windows\assembly and your problem will be solved.