We Keep Coding

Inject a C# file in a DLL

I have a DLL written in C# for which I don't have the sources. I have tried different C# decompiler to modify the DLL, but they all give me errors in my attempts to recompile with the modifications, I suppose due to IL decompilation limitations. Is it possible to add a .cs file to the root of the DLL in order or inject a method to add a functionality ?
PS: This is not intended to hack a software but to create a mod of a game which requires DLL modification.

Your best approach may be to just create a wrapper project around the dll to add the functionality that you want. Your code could them reference the project instead of the dll. As long as the classes aren't sealed you should be able to inherit from them.
Modifying code you don't have access to probably isn't a good idea to begin with. Especially if the dll could be updated in the future.

You can also create a new DLL with the same namespace. This might make things look as if they're in the same location, but it's not the best practice and it could be confusing since namespaces are expected to match the project/dll name.
Benjamin's solution with the wrapper seems reasonable.

The Reflexil plugin for .NET Reflector could inject a method or a class in a DLL as illustrate in a video by its creator.
It prevents decompilation-compilation errors as it just injects IL code in the assembly.
To install this plugin follow these steps.

How to compile localization DLLs (MyLibrary.resources.dll) into a single DLL?

Using C# .NET with COM interop in VS2012, I'm developing a common library for use in several other programs. To keep the integration simple, I would like to keep the entire library down to one DLL. One of the features of this library is localization. It has string tables with messages in multiple languages, each language having it's own ResX file.
Presently, a MyLibrary.resources.dll is being created for each language and placed in its own subdirectory, like this:
Release\MyLibrary.dll
Release\ja\MyLibrary.resources.dll
Release\fr\MyLibrary.resources.dll
What I want to see is just this:
Release\MyLibrary.dll
Here are my current ResX settings.
I have tried using ResXFileCodeGenerator and GlobalResourceProxyGenerator for the "Custom Tool" generators. I also tried a few options for "Build Action" including Compile, but so far only Embedded Resource works. Other than that I'm not sure what else to try or if I'm on the right track. There aren't really that many settings to work with.
I am aware that there are a variety of tools that may work to do this after building the DLL, but I'm looking for a compile-time solution. Third party tools are challenging from a maintenance standpoint -- I will not be the only one updating this library.

There are two main ways of embedding libraries into a single DLL or executable. The first uses ILMerge, combines all assemblies as if it was a single assembly; the second is dynamically loading dependencies from embedded resource(s) at runtime (offers a bit more flexibility, but has its own set of pros and cons). The sample project is intended to be portable (the only dependency is Powershell -- all required libraries are included in the project).
It's important to know the difference between the two techniques. I've written articles outlining both approaches with a sample project on github for both approaches.
Articles:
Assembly Loading: Combine Assemblies & Executables Using ilMerge
AND
Assembly Loading: Dynamic Assembly Loading & Compression
Sample Project:
Application Demonstrating Both ILMerge and Runtime Loading of Embedded Assemblies
If you have any questions regarding either approach, don't hesitate to get in touch. I'll gladly refine the posts based on your feedback.

Obsolete library class

What is the best way to prevent C# programmer from using particular library class?
Class is from external assembly so it is impossible to use [Obsolete] attribute on it. I tried to use Resharper custom patterns but it seems not to support generics types.

Patch the library method/class (there are several plugins for Reflector) - add DeprecatedAttribute, or modify its code to throw an exception, for example.
You can also make a special unit test which runs at CI server and fails if a particular deprecated item usage indicated.

You can disassemble the library with ildasm, add [Obsolete(true)] attributes and reassemble with ilasm.
You might be able to find some assembly edit tool, like Reflexil together with a trial of Reflector.
Note that if you edit an assembly you loose all signing and stuff.

Using tlbimp without needing a second assembly?

I am trying to implement a COM interface in my C# dll for others to consume. I have defined an interface in foo.idl.
I've run foo.idl through tlbimp to produce foo.dll, a .Net assembly. Now to implement my interface, I can reference foo.dll in my dll to implement the interface.
This works perfectly as it stands with one exception: I now have to distribute two dlls instead of one. This actually goes against the requirements of the project I'm working on: deliver one DLL.
Is there a way to merge the tlbimp dll into mine, or any other way to do this (implement a COM interface in C# without the second dll)?

A good disassembler gets the job done, like Reflector. You can simply disassemble the interop assembly and copy the generated C# interface declarations into your source code. Of course you should only do this if the interface declarations and IIDs are stable.
And definitely consider upgrading to VS2010. Its "embed interop types" feature allows you to ship your assembly without the interop assembly.

You could probably cheat by using a .tlb instead of the 'glue' dll.
I'd suggest you create a mixed-mode assembly using MSVC++/CLR
http://msdn.microsoft.com/en-us/library/k8d11d4s(v=vs.100).aspx
Interop (How Do I in Visual C++)
This might have the drawback that you can't use C# in the same assembly. Should you want to add C# code to the mix, you might be able to squeeze out of your tough situation using
IlMerge
For other, possibly interesting, thoughts see my earlier answer:
Is it possible to compile a console application into a single .dll file?

Linking statically in C#

I'm working on a module for a CMS. This module is distributed as a class library DLL.
I have several utility libraries I'd like to use in this module. Is there anyway I can link these libraries statically so I won't have to distribute several DLL's (thereby distributing my utility libraries separately)?
I would like to have only one DLL.

You can merge your many DLLs with ILMERGE:
http://research.microsoft.com/~mbarnett/ILMerge.aspx
Haven't tried it myself. Hope it helps.
Download here:
http://www.microsoft.com/downloads/details.aspx?familyid=22914587-B4AD-4EAE-87CF-B14AE6A939B0&displaylang=en
Brief Description (from download-page)
ILMerge is a utility for merging multiple .NET assemblies into a single .NET assembly. It works on executables and DLLs alike and comes with several options for controlling the processing and format of the output. See the accompanying documentation for details.

If you don't want to use ILMerge, see this page:
http://blogs.msdn.com/b/microsoft_press/archive/2010/02/03/jeffrey-richter-excerpt-2-from-clr-via-c-third-edition.aspx
editor's note: Jeffrey Richter advices to put your dlls into exe file as resources (For each DLL file you add, display its properties and change its “Build Action” to “Embedded Resource.”). Then a custom class loader is needed to make the executable work (At runtime, the CLR won’t be able to find the dependent DLL assemblies, which is a problem. To fix this, when your application initializes, register a callback method with the AppDomain’s ResolveAssembly event).
Be sure to change the resourceName string to point to your actual resources. (e.g. change AssemblyLoadingAndReflection to your project name.)

The short answer for this is no!
You can not link in a dll during compilation.
I don't know if there is some subtle way to do this, but you would probably have to distribute the dlls along with your cms.
The best way to do this is to make some kind of re-distributable.