Adding a dll file to a C# project

Answer 1

If an assembly (Bass.Net.dll in your case) contains classes you want to use, you must add a reference to that assembly to your project.

Answer 2

No reason, really. It could be that Visual Studio is set to display files not in the project (hard to tell from the picture) and the dll's happen to be in the main directory. The text is pretty clear that the extra files are

• bass.dll
• bassenc.dll
• lame.exe

The .net one happens to be with the others in the same directory and you need to add it as a reference.

Answer 3

No point the best thing to do is get all your dependenicies and store them in a seperate folder and only reference them do not copy them to your solution ;)

Answer 4

Having those in your project and output directory allows the final executing code to reference them without any issues running on different machines.

It sounds as it they put the reference dlls in the project directory, reference them from there, and also include them in the project. That way, when the project directory is copied, the reference dll will be copied with it. Additionally, if the reference dll is missing, the project will complain in Visual Studio.

Answer 5

Within Windows, a DLL is a dynamic link library, which packages a set of programmatic functionality together. In this example, bass.dll exposes the features and functionality relevant to audio processing through this file (and any files it depends on). In order to use this functionality, you need the reference in the solution, so that Visual Studio can link it at compile time. The DLL will then typically be copied to your output directory when the application is built.

That's all that is necessary to get the code to work properly, the rest is really just preference or convention. Some people prefer to have all the files that exist in the project directory in the solution, so that the Solution Explorer reflects the file system. Typically you will want to have libraries your application depends on somewhere in your solution directory hierarchy so that the entire application is packaged together (making source code control use easier, for instance). You won't want to put this library in the BIN directory or any directory that Visual Studio generates, though, to avoid accidental deletions. In any event, having the reference is the important part, the file being in the project or solution is not necessary.

Typically, you'll want to keep external libraries out of your source directories, though, so I wouldn't actually recommend this structure. I tend to use a structure like this, but, again, this is all preference:

• Source: Source code and project files
• Libraries: DLLs
• Support: Miscellaneous code or projects, but not actually part of the application (perhaps deployment scripts)

Answer 6

It's really hard to guess why someone else did something, but if I really had to guess, I'ld say that the guy thought to embed the necessary dlls as resources to be sure it was availale to the application. I have seen this technique used to embed fonts or sounds and am not sure if it works at all with dlls; but it's just a guess.
Of course the best way to be sure the files were available would have been to create a deployment project, with Visual Studio or some other installation tool loke Wise or InnoSetup, just to name a few.

Answer 7

This actually might be a good idea in a lot of circumstances. In my opinion their are 3 types of dependencies

1. Assemblies from the .Net standard library. Never include those locally.
2. Assemblies that you expect other developers to install as part of an MSI or exe setup package. This usually means their strongly signed and have a copy in the GAC.
3. Assemblies that you don't expect other developers to install via an MSI or exe installer. Maybe because you have a third party or in house library not in the GAC.

In the third case, the simplest thing to do is store a copy of the DLL in the source repo.