Develop Reference

What is the difference between a dSYM folder and an mSYM folder?

I am working on an Xamarin.iOS application that is crashing when being deployed via an Ad-hoc process. As documented by Apple, when an application crashes, a .crash file is generated. The document also states that, as a developer, we must keep the dSYM folder.
Turns out, in my case, I (only?) have a mSYM folder.
Question
What is the difference between an MyApplicationName.App.dSYM folder and a MyApplicationName.App.mSYM folder?

.dSYM
A dSYM file is a "debug symbols file". It is generated when the "Strip Debug Symbols" setting is enabled in the build settings of your project.
When this setting is enabled, symbol names of your objects are removed from the resulting compiled binary (one of the many countermeasures to try and prevent would be hackers/crackers from reverse engineering your code, amongst other optimisations for binary size, etc.).
dSYM files will likely change each time your app is compiled (probably every single time due to date stamping), and have nothing to do with the project settings.
.mSYM
mSYM means MonoSymbolArchive.It contains debug info of mono.
Edit the iPhone release configuration in the csproj file to include <MonoSymbolArchive>True</MonoSymbolArchive> which will generate symbol data in bin/iPhone/Release/.mSYM

What is the use of folders inside a Solution or Project (in Visual Studio)

I've been messing around with some public and work Git repos (all Github), as I grow my burgeoning C# expertise...
Especially for tutorial and course repos, they use a lot of folders. I also noticed you can add a "Solution Folder". However, I've also noticed Visual Studio has this love-hate relationship with folders, and sometimes they map to the physical folder, and sometimes they... just don't.
So - what can I use them for? Is there a good use case beyond just logically grouping files in a project to organize things a bit?
Oh! And one time I opened a folder from my drive directly in Visual Studio, and it showed up just like a solution - but it was just an open folder... it was kinda weird. What's up with that?
Links to Info
This Q&A (Actual folders in Visual Solution Explorer?) explains some more about how to keep folders in a solution mapped to the physical folders, which VS is very picky about and doesn't even try to keep in sync...

If I'm understanding your question correctly, there is essentially two most common uses for folders within your solution/project.
First and probably most obvious, folders are used to organize and group together relevant files. While this is more of a personal preference thing - I often use folders to organize my code similar to that of MVC (Model View Controller).
Second and usually less common but still something to be familiar with are folders that get copied into the output directory. These folders get created when you have a file with its advanced property Copy to Output Directory set to Copy always or Copy if newer. These files then become a part of the Build Action - upon building your solution, these files get copied to the output directory. This is used when there is a need for certain files within your solution such as a data file or external resource needed to interact with.
Example: I recently worked on a project that required my solution to interact with PhantomJs, which is an external standalone executable. I needed my code to make calls and pass data to this application - thus making it a vital part of my solution. PhantomJs was placed in a folder and set to Copy if newer which ensured my copy of the executable was an available resource during runtime.

Remove debug information from an ".exe" [duplicate]

This question already has answers here:
C# release version has still .pdb file
(6 answers)
Closed 6 years ago.
If I put my C# program exe in a text editor, I can find debug information in it:
How can I remove that?
EDIT: I dont care about the pdb file, i only care about that there is a path to the pdb file in the executable. This path contains my name (coincidence in this example), my question is how i can remove THAT Path from the executable, NOT how to remove the pdb file itself.

OK, so yours is actually a curious question because what you are asking for is really nothing you normally would be concerned about. PDB files are not "personal information" and neither is the path found in the .exe that points to the .PDB file. Your example is pure coincidence. Moving on...
Easiest fix Based on Best Practices
Don't keep your Visual Studio code inside your Windows User Profile Documents folder. Instead move it to one of the following
c:\development or better yet, a folder on a non-OS drive if you can
When you are ready to ship, ensure you build your code on a CI server. In this day and age there is no excuse for not using a CI server in the same way as you should be using source control
That will fix the coincidental username appearing in your exe. Unless of course you are running your build agent in your user context instead of a dedicated build account.
Also, I like to keep Documents for, well documents and not get polluted with code; Git or SVN caches. It just creates noise for real-time back-up apps like CrashPlan.
Alternative
Just build without debug information.
Consider this default debug build, note the path to the associated PDB File:
Release with No debug settings
Settings
Yours is a debug build which you can tell by the path to the PDB file, a file containing debug information about the application. Normally you don't deploy a debug build of your application.
Make a release build of your application. Release builds by default do not generate a .pdb file.
Also, .pdb files don't give away "source code" to avid readers if that is your fear. At most it may list the path to a file, but a filepath doesn't constitute source code content.
See also:
You might want to check this out as to why its a good idea to always deploy PDB files

Altering 1 C# controller file

I've worked with PHP but never C#, and I need to make 1 change to a file, and was hoping I could get some guidance, or suggested resources to learn more.
I have 1 cs controller file where I want to change the [Authorize(Roles="A")] to [Authorize(Roles="A,B")]
I made the change but nothing happens, so I've come to the conclusion that this cs file probably needs to be compiled.
The question is, is there a way to compile this one file? Or does the entire site need to be compiled?
When I open the cs files, it opens with "Visual Studio Tools For Application 2.0 2008".
Is this sufficient to make the changes?
My thinking is that one of the following needs to happen:
Scenario 1:
Open the .cs file in the appropriate compiler (of which I do not know
what it is) Compile it and copy the newly compiled file into the
appropriate folder.
Scenario 2:
Open the whole project in a compiler - of which I'm guessing the
".csproj" file to open. Compile the whole project Copy the desired
compiled file to replace the old file.
Scenario 2b:
Open the whole project in a compiler - of which I'm guessing the
".csproj" file to open. Compile the whole project Copy everything
back to the server.
Scenario 3:
The code I have is not sufficient to do the changes, and I need some
other source code.
That's all I've got, if someone can suggestion which one(s) may be on the right track, and how I may go about doing this, it would be greatly appreciated.
Thanks

The fact you are talking about a Controller would strongly suggest you are working on an ASP .NET MVC project. You will have a .sln file which is a solution file which is the master document if you will:
YourWebsiteSolution.sln
YourWebsiteProject.csproj
YourController.cs
Once you open the .sln file with Visual Studio (you need to know what version but you can get the latest here: Download VS2012 Web Express). You can the choose Build -> Build -> ReBuild Solution from the menu and that will re-compile all of your .cs and associated files into DLLs that will be in your \Solution\Project\bin\Debug folder (or Release depending on build).
When you deploy to the server you only deploy the .DLL files (in this instance). You NEVER deploy the actual .cs files as they contain the code and you don't want people peeking into them (this differs from PHP where the code is on the server).
Because you have not changed any of the views you don't need to follow this step but for a full deploy you would also copy any .cshtml or .aspx files and the usual suspects such as .css and .js etc to same folders on server as on the project.
I hope that is a good starter to get you going?

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.