Develop Reference

Packaging files into one executable (C#)

I developed a small project using C# and got everything working perfectly.
The only problem is that this app will be regularly sent via emails, therefore I'm trying to assemble all the files as one executable. The user will only have to open and see one executable, which will load the needed files and start the application.
The app does not use any external libraries. The only .dll file is for the IWshRuntimeLibrary.
The files that need to be assembled:
Note that I know that some files can be removed (svhost etc.). However this won't help because I'll still have more than one file. Also I've tried some free assemblers online but none of them worked.

In Solution Explorer, select the reference of Interop.IWshRunctime... and in the property window, change the value of Embed Interop Types to True.
This will not generate a separate dll for Interop Types.
PS: This is not a generic solution, but works with Interop Type only.

I've used https://github.com/Fody/Costura in the past. Nuget install Install-Package Costura.Fody (https://www.nuget.org/packages/Costura.Fody/)
Description about what it does from the source:
Take all assemblies (and pdbs) that have been marked as "Copy Local" and embed them as resources in the target assembly.

Actually you are looking for a method to merge some assemblies and resources into one executable file.
Custora.Fody, ILMerge, Obfuscators with assembly merging feature are some examples that can be used for this purpose.
You can find some answers here:
Embedding DLLs in a compiled executable
How to merge multiple assemblies into one?
List of obfuscators for .NET

If this is not about security reason, I would create the directory structure as follow:
- root
└　Startup.bat
└　lib
└　DiagnosticsSwitch.exe
└　DiagnosticsSwitch.exe.config
└　DiagnosticsSwitch.exe.manifest
└　Interop.IWshRuntimeLibrary.dll
And inside the Startup.bat
"lib/DiagnosticsSwitch.exe"

References can not be reinitialized after check-in from visual studio team service

I did check-in to download source code for the first time, but i got some missing references. I've tried following ways but it doesnt work for me:
Add references: Right click -> add references then find references (after adding the references, there is nothing change, you can see in the photo below)
Dlls were set to Copy Local (I even can not change the copy local to
true)
Adding namespaces to both web.configs did nothing.
I used VS2015. is there any way to update it correctly? thanks

Generally, source code does not contain dll's, since they are vey big files. So I would not normally expect to get dll's from source control. You would usually have to build the solution and hope that Nuget is enabled to download the dll's from where they are stored.
However, the dll's you are showing come with the .net framework, so this should not be an issue, unless of course, the solution file is expecting to find the dll's in some /bin directory.
You can find which directory the dll's are expected to be in by right clicking on the missing dll and then clicking on 'properties'. This should show you the referenced dlls path in the properties window.
If the dll is not in that path you can do one of 2 things:
Delete the reference and add a new reference to the dll, where it actually exists
paste the dll in the path that is being referenced by the solution.

Why does VS2010 allow for the concept of "include in project"?

I'm still learning the basics of how VS2010 sees the world. Apparently, you can optionally "include" a file in a project. I'm a bit confused by this: If a file is version-controlled, AND the file is within the project directory, shouldn't it implicitly be "included" in the project? If not, what's the use case where a version-controlled file in the project directory should NOT be included in the project?
=== Addition ===
Based on the answers I've gotten so far, maybe I should rephrased my question: What does it mean for a file to be "included" in a project?

A project needs to know about files in order for compilation and distribution to occur. Just because you have a file that's under source-control, doesn't mean that it will be compiled if the project is unaware of it.
Also, you may want to include files as part of a distribution package. We do this quite often for our web projects that we distribute using web app gallery.
Conversely, you could have documentation or sql scripts that you version control, but do not want them to be part of the project.
EDIT: In answer to your update, what it means for a file to be included in a project is that the file is actually added to the .csproj or .vbproj file and will be used during compilation and/or distribution. VS does differentiate if the file is Content or if it needs to Compile it. This can be seen by clicking on the file in Solution Explorer and looking at the Build Action property.

No, you don't want random files that happen to be in the project directory included in source control.

We do sometimes put documentation (pdfs) or drawings/schematics in the project folder and under version control but you don't need them inside the visual studio project (especially when they are not being distributed because they are for internal use only).

Excluding the file from your project can be useful if the file is related to the project but not necessarily needed in the solution.
Example
If I need some test XML for an application that i'm writing; that is designed to normally be pulling this from a WCF service, it can be useful to keep that file in the directory for a development environment where I use IO to get the XML for testing, but I don't necessarily want it in my solution which is source controlled.

When you exclude a file from a project is no longer compiled or embedded, then when you want to include it again you can do so without having lost your settings.

If you e.g. copy a file (containing a helpful class which want to have in your project) into a folder of your project, then you will see ... nothing. You have to check the option "Show all files" of the solution explorer and the copied file can be seen, but it is still "greyed out". No you can choose the menuitem Include in project and that file will be integrated in your project and a pending change (add) for your source control is added too. Visual Studio doesn't include all files it can find in the project folder automatically to the project - and that is a good feature.

One of my colleagues explained to me a scenario in which a version-controlled file should NOT be part of the project. Here's the idea:
A developer writes some new code.
The code is experimental, and not intended to be part of the normal build.
The easiest way to exclude the file from the build is to NOT include it in the project, but still version-control it.
This way, the file can be shared with other developers, but not break the build.

Possible to package all needed files in an EXE?

I wrote an EXE that uses a third party dll and a template excel document. Anytime someone uses it they have to copy all three files (which is a pain).
Is there any way I can package everything that is needed into the EXE so there is only one file to worry about?

This is something that ilmerge is used for, atleast for combining assemblies. There is more information here and here.
There are several known problems with this though.

Yes - drag it into your project resources (My Project > Resources tab) and from there you can access it using global::Resources.resourceFile (I think - that might not be the right syntax, an alternative is here) as a byte stream and write it locally from there.

You can add files to your project in visual studio and set Build Action to None and Copy to Output directory to Copy always.
or
You can add these files to assembly resources. Adding and Editing Resources (Visual C#)
I suggest doing the first.
Also, for 3rd party dll: set Copy Local to true for the reference.
After you have your project set like this. Create setup project in VS and it will make one exe as you want.
How to: Create or Add a Setup Project

Software installation is a pain, but I think you can get away with an xcopy style deployment by using the compression tool of your choice (like winzip) and creating a self extracting executable.

Adding a dll file to a C# project

It's a beginners question, but...
Image of dll reference and dll included in project file http://a3.vox.com/6a00c2251e5b66549d00e398ca81eb0003-pi
If you look at the image above, there is the "Bass.Net" dll added as reference and also directly as file in the project.
Can someone tell me what's the point of doing that?

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.

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)

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.

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.

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 ;)

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.

This actually might be a good idea in a lot of circumstances. In my opinion their are 3 types of dependencies
Assemblies from the .Net standard library. Never include those locally.
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.
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.