Develop Reference

c# Use dll with different versions in one directory

How can I use different dll's (other Version) with the same name in one directory?
For Example, LibA (ExternalLib.dll) has Version 1 and LibB (ExternalLib.dll) has Version 2.
I'm deploying all my programs to the same directory (this is our companys standard and I can't change this fact). The problem is if ProgramB which is using the LibB is deployed in the directory where ProgramA is using the LibA then ProgrammA would not longer work.
For my own Libs I use a Major-Version-Number (.01, .02) if there are big changes. But the Lib I'm using is an external Lib and each version of it requires different licensing-keys (which are handled by the programs itself).
I tried to rename the external libs from "ExternalLib.dll" to "ExternalLib.v1.dll" and "ExternalLib.v2.dll", but when I run my fresh compiled programm it throws an exception that says "ExternalLib.dll could not be found". The reference in my project is set to "ExternalLib.v1.dll" and compilation works fine.
Any ideas / suggestions to handle different assembly versions in the same directory?

Unfortunately, the filename of the DLL file has very little do do with how .Net is loading these types. The actual name is written into the meta data of the assembly as part of the compilation process. So at runtime, it will be probing for ExternalLib.dll regardless of what you renamed the file to. The usual way to fix this is to install to the GAC and use Strong Naming to reference the specific version.
Given you may not be able to do this, there are 4 things you could try:
Ask the vendor to produce version specific DLL's for you. They could compile such that the version name is part of the filename and included in the assembly manifest. This would be the simplest solution for you.
Handle the AssemblyResolve event and manually try and use Assembly.Load to point at the file you want such that you can specify specifically which dll to use. See http://support.microsoft.com/kb/837908 for more information, but effectively you'll be using Assembly.LoadFrom(specific_path) to choose the file where the code will load from.
If possible, you might also be able to use ildasm.exe to decompile the dll's to Intermediate Language (IL), then use ilasm.exe to recompile it to a new dll name. You would then reference this new DLL name in your project.
If the assembly is not signed, then you may be able to edit the manifest yourself; you can either use a compatible binary editor or possibly MT.exe.

My C# and DLL Data Woes

I'm trying to see if it is possible to pull data from a DLL. I did some research and found that you can store application resources within a DLL. What I couldn't find, was the information to tell me how to do that. There is a MS article that explains how to access resources within a satellite DLL, but I honestly don't know if that is what I'm looking for. http://msdn.microsoft.com/en-us/library/ms165653.aspx I did try some of the codes involved, but there are some "FileNotFoundExceptions" going on.
The rest of the DLL information is showing up: classes, objects, etc. I just added the DLL as a resource in my Visual Studio Project and added it with "using". I just don't know how to get at the meat of it, if it is possible.

If dlls are .net, you can use reflection.
Using System.Reflection;
....
Assembly A= Assembly.LoadFrom(YouDllFileName);
string[] STA;
STA= A.GetManifestResourceNames();
// STA contains all the resource names in the dll
...
// to extract them
Stream str= A.GetManifestResourceStream(STA[I]);
// then, you can make that stream became a file if you wish
You can also extract a .net assembly resources by using ildasm

I'm not totally sure what you might be running into based on your description, but a couple of general pointers...
If what you are trying to find is files you've added to the project you do this:
Right click on the resource in solution explorer, hit properties and set the "Build Action" to "Embedded Resource".
For strings and icons, add a .resx file to the project and insert them in there. If that's what you're doing and still running into issues, check the Build Action.

There is two types of dll.
Managed dll - dll that writen on any .net language (like csharp)
The link that you provide is working with managed dlls.
Unmanaged dll - classic c/cpp dll.
in this case you need to link between managed (your code) and unmanaged.
To find what the type of your dll, you need to add this dll as reference.
In visual studio open project, right click on references(in Solution Explorer).
Then "add reference"->browse-> add your dll.
Then at references, you can see your dll.
Right click on him, and add view in Object Browse.
If you see something like class "c" inside namespace "b", you working with managed dll.
In Object Browser you can learn a lot about your dll (maybe this is more important, than just extract resources)
At this point you can do the way that "Daniel Dolz" answer to you.

Since you say you are able to add the DLL in a using directive you can probably use the methods that the DLL exposes. If you do not have the documentation for the DLL then you may just have to try using the object browser to see what it has to offer.
assume:
using MyDll;
you should them be able to call the methods like this:
string x = MyDll.SomeType.GetValue();
is that what you were asking?

Help with Assembly Information File in C#

What is the Assembly Information File for in C# and how do I use it?

The AssemblyInfo file is used to document your dlls or exes to describe where the code comes from, its version etc. If your code is publicly available then its certainly good practice to make sure you add useful information too it.
http://www.codinghorror.com/blog/archives/000141.html
If you build your project with NAnt there is also a useful target that allows you to build the assembly info dynamically.
http://nant.sourceforge.net/release/latest/help/tasks/asminfo.html

Right-click on any program icon, and select 'Properties'. Navigate to the 'Version' tab. That information you see is what is contained in the AssemblyInfo.cs file, among other things.

It holds information about your assembly. Author, Company, Version Numbers (build/minor/major/etc)
Try this article:
http://msdn.microsoft.com/en-us/library/1h52t681.aspx

It's a file created by the default project templates under the "Properties" folder that has attributes defined at the assembly-level that the C# compiler and framework use to store various bits of metadata like the title of the assembly, the version, the publisher, etc. There's other framework-specific attributes that you can throw in there such as XAML namespaces, Data Contract namespaces, etc. Basically any attributes that you define at the assembly level are typically placed in here.
There's nothing special about the name though. These attributes can actually appear anywhere in any code file.
I posted a neat little tip about dealing with the issue of having multiple AssemblyInfo files in different projects in a solution that all have common attributes.

What information can I find about a build from the assembly info?

Following on from my previous question, what useful information can you retrieve from a .net assembly about the build process? I know I can look at the AssemblyVersion to get major and minor application version, and when the build took place.
Can I find:
Who did the build? i.e. user name.
On what machine?
Which O/S version?
Anything else useful?

From my (limited) investigations (into assemblies I've built) you're basically limited to what the author put into the file.
About the only thing that's automatically assigned are the "Internal Name", "Original File name" and "Language".
There might be some IDE's that put in the information you require, but by default Visual Studio isn't one of them.

By default, you don't have any of that information. Jon's answer to your previous question is actually the correct way to do this. You want to create custom attributes for each piece of information you want (or one attribute with properties for each) that apply to an assembly. This is how the attributes typically found in your AssemblyInfo file work.

Embedding assemblies inside another assembly

If you create a class library that uses things from other assemblies, is it possible to embed those other assemblies inside the class library as some kind of resource?
I.e. instead of having MyAssembly.dll, SomeAssembly1.dll and SomeAssembly2.dll sitting on the file system, those other two files get bundled in to MyAssembly.dll and are usable in its code.
I'm also a little confused about why .NET assemblies are .dll files. Didn't this format exist before .NET? Are all .NET assemblies DLLs, but not all DLLs are .NET assemblies? Why do they use the same file format and/or file extension?

ILMerge does merge assemblies, which is nice, but sometimes not quite what you want. For example, when the assembly in question is a strongly-named assembly, and you don't have the key for it, then you cannot do ILMerge without breaking that signature. Which means you have to deploy multiple assemblies.
As an alternative to ilmerge, you can embed one or more assemblies as resources into your exe or DLL. Then, at runtime, when the assemblies are being loaded, you can extract the embedded assembly programmatically, and load and run it. It sounds tricky but there's just a little bit of boilerplate code.
To do it, embed an assembly, just as you would embed any other resource (image, translation file, data, etc). Then, set up an AssemblyResolver that gets called at runtime. It should be set up in the static constructor of the startup class. The code is very simple.
static NameOfStartupClassHere()
{
AppDomain.CurrentDomain.AssemblyResolve += new ResolveEventHandler(Resolver);
}
static System.Reflection.Assembly Resolver(object sender, ResolveEventArgs args)
{
Assembly a1 = Assembly.GetExecutingAssembly();
Stream s = a1.GetManifestResourceStream(args.Name);
byte[] block = new byte[s.Length];
s.Read(block, 0, block.Length);
Assembly a2 = Assembly.Load(block);
return a2;
}
The Name property on the ResolveEventArgs parameter is the name of the assembly to be resolved. This name refers to the resource, not to the filename. If you embed the file named "MyAssembly.dll", and call the embedded resource "Foo", then the name you want here is "Foo". But that would be confusing, so I suggest using the filename of the assembly for the name of the resource. If you have embedded and named your assembly properly, you can just call GetManifestResourceStream() with the assembly name and load the assembly that way. Very simple.
This works with multiple assemblies, just as nicely as with a single embedded assembly.
In a real app you're gonna want better error handling in that routine - like what if there is no stream by the given name? What happens if the Read fails? etc. But that's left for you to do.
In the rest of the application code, you use types from the assembly as normal.
When you build the app, you need to add a reference to the assembly in question, as you would normally. If you use the command-line tools, use the /r option in csc.exe; if you use Visual Studio, you'll need to "Add Reference..." in the popup menu on the project.
At runtime, assembly version-checking and verification works as usual.
The only difference is in distribution. When you deploy or distribute your app, you need not distribute the DLL for the embedded (and referenced) assembly. Just deploy the main assembly; there's no need to distribute the other assemblies because they're embedded into the main DLL or EXE.

Take a look at ILMerge for merging assemblies.
I'm also a little confused about why .NET assemblies are .dll files. Didn't this format exist before .NET?
Yes.
Are all .NET assemblies DLLs,
Either DLLs or EXE normally - but can also be netmodule.
but not all DLLs are .NET assemblies?
Correct.
Why do they use the same file format and/or file extension?
Why should it be any different - it serves the same purpose!

You can embed an assembly (or any file, actually) as a resource (and then use the ResourceManager class to access them), but if you just want to combine assemblies, you're better off using a tool like ILMerge.
EXE and DLL files are Windows portable executables, which are generic enough to accomodate future types of code, including any .NET code (they can also run in DOS but only display a message saying that they're not supposed to run in DOS). They include instructions to fire up the .NET runtime if it isn't already running. It's also possible for a single assembly to span across multiple files, though this is hardly ever the case.

Note ILMerge doesn't work with embedded resources like XAML, so WPF apps etc will need to use Cheeso's method.

There's also the mkbundle utility offered by the Mono project

Why do they use the same file format and/or file extension?
Why should it be any different - it serves the same purpose!
My 2¢ bit of clarification here: DLL is Dynamic Link Library. Both the old style .dll (C-code) and .net style .dll are by definition "dynamic link" libraries. So .dll is a proper description for both.

With respect to Cheeso's answer of embedding the assemblies as resources and loading them dynamically using the Load(byte[]) overload using an AssemblyResolve event handler, you need to modify the resolver to check the AppDomain for an existing instance of the Assembly to load and return the existing assembly instance if it's already loaded.
Assemblies loaded using that overload do not have a context, which can cause the framework to try and reload the assembly multiple times. Without returning an already loaded instance, you can end up with multiple instances of the same assembly code and types that should be equal but won't be, because the framework considers them to be from two different assemblies.
At least one way that multiple AssemblyResolve events will be made for the same assembly loaded into the "No context" is when you have references to types it exposes from multiple assemblies loaded into your AppDomain, as code executes that needs those types resolved.
https://msdn.microsoft.com/en-us/library/dd153782%28v=vs.110%29.aspx
A couple of salient points from the link:
"Other assemblies cannot bind to assemblies that are loaded without context, unless you handle the AppDomain.AssemblyResolve event"
"Loading multiple assemblies with the same identity without context can cause type identity problems similar to those caused by loading assemblies with the same identity into multiple contexts. See Avoid Loading an Assembly into Multiple Contexts."

I would suggest you to try Costura.Fody. Just don't forget to Install-Package Fody before Costura.Fody (in order to get the newest Fody!)