We Keep Coding

Creating a Class in C#, which file should I use?

As I told you in a question before, I'm starting to learn C# and right now I'm beginning with the classes theory, so when I was going to create a class I found there was two 'templates' to do it [I'm using Xamarin on a Mac], one under C# -> General, and the other one in C# -> MonoGame. Both seems pretty much the same, but I want to know which one should I use, or what are the differences between both?
This is the one located in General:
using System;
namespace Application
{
public class stack
{
public stack ()
{
}
}
}
And this is the one in MonoGame:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Microsoft.Xna.Framework;
using Microsoft.Xna.Framework.Audio;
using Microsoft.Xna.Framework.GamerServices;
using Microsoft.Xna.Framework.Graphics;
using Microsoft.Xna.Framework.Input;
using Microsoft.Xna.Framework.Input.Touch;
using Microsoft.Xna.Framework.Storage;
using Microsoft.Xna.Framework.Content;
using Microsoft.Xna.Framework.Media;
namespace Application
{
class stack
{
}
}

The using System is the basic framework that needs to be uploaded to do thing like Console.write(). With out it, you'd have to do System.Console.write.
In your second example, you are just importing other framework that you might need depending on what you are developing. From the looks of it, it is a basic game framework set: audio, graphics, touch, etc.
The using is just a way to import frameworks that you might need. See: https://msdn.microsoft.com/en-us/library/zhdeatwt.aspx

Both the code you displayed are correct.
The second one contains the namespace references for your application.
For example :
using System.Text;
The System.Text namespace contains classes that represent ASCII and Unicode character encodings; abstract base classes for converting blocks of characters to and from blocks of bytes; and a helper class that manipulates and formats String objects without creating intermediate instances of String.

DataAnnotations missing attributes

I have using System.ComponentModel.DataAnnotations; at the top of the file, but essentially the only attributes I have are [DisplayName] and [Readonly]. Even [Display(Name...] does not exist. What am I missing?

Tools like Resharper allow you to analyze the using statements in a code file.
If you find that you do not need the using statement, remove it.

Use the following namespaces:
using System.ComponentModel;
using System.ComponentModel.DataAnnotations;

Can "using <namespace>;" directives be made more efficient in .NET?

When I create a new class file in C#, the usual structure is as follows:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace UnitTest
{
class Class1
{
}
}
StyleCop doesn't like having using directives outside of the namespace, so ideally, I would refactor my code as such:
namespace UnitTest
{
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
class Class1
{
}
}
From my days as a Java programmer, I was taught that it was better to import only the references that were necessary, rather than the entire package like so:
import foo.bar.MyObject;
instead of
import foo.bar.*;
I know that this can also be done in C#, with the added feature that you can use aliases for types (sometimes useful when working though native code):
using StringBuilder = System.Text.StringBuilder;
or when using aliases:
using HANDLE = System.IntPtr;
using HDC = System.IntPtr;
So my questions, regarding best practice and efficiency of using directives:
Is is more efficient to keep using statements inside a namespace, or is this purely a stylistic preference?
If is more efficient to only include the necessary items, as opposed to the entire namespace?

There are some fringe cases where it makes a difference but for the majority of cases it is just a stylistic preference.
The using statements just tell the compiler where it can locate the types. It has no influence on the runtime.

nope; stylistic preference, as long as it doesn't introduce any semantic changes; the cases where it changes the meaning are very rare (although there used to be a bug with the LINQ-to-SQL code generator that did care about where you put them - this is now fixed)
nope; unused directives are not used, and they don't massively impact the compiler
Note that having too many directives can cause ambiguities; for example there are a myriad of classes called Timer. For that reason it is worth keeping things tidy.

Using statements before or after Namespace in C# [duplicate]

This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Should Usings be inside or outside the namespace
So there are two approaches to where you have your using statements in regard to the namespace. You can either have them outside the namespace declaration or inside. What is the pro/con between the two approaches and which is generally preferred.
using System;
namespace MyNamespace
{
}
or:
namespace MyNamespace
{
using System;
}

I typically see the former in use. These using statements are typically at the very top of a source file, making it easy to see at a glance what a particular file makes use of. It also allows you to easily see the start of new code, as the namespace signals the new stuff.
The other way is a little bit less easy to follow from an organizational standpoint. The only benefit is that you could have different using statements in two different namespaces in the same file, but using two namespaces in the same place like that is bad coding practice, so it should be avoided.

Does it matter if I include more references and namespaces in a class

For example:
using System;
using System.Web;
using System.Collections;
using System.Web.Services;
using System.Web.Services.Protocols;
using System.Web.Script.Serialization;
using System.Web.Script.Services;
using System.Web.Security;
using System.Data;
using System.IO;
using System.Net;
using System.Text;
using System.Xml;
using System.Xml.XPath;
using System.Web.Configuration;
using System.Collections.Generic;
I have something like that in a class that I have inherited. I could remove each namespace one by one to see if the class builds, BUT does it matter?
If I am not sure if System.Xml is needed, should I remove it?

In general all they do is add clutter.
However, they can in some specific circumstances cause problems with duplicate names in scope, or duplicate extension methods. For example, if there are classes Foo.SomeType and Bar.SomeType, and you have using Foo; and using Bar;, then references to SomeType will need disambiguating. The extension methods work similarly where static classes in different namespaces contribute conflicting extension methods.
The VS2008 tools (including express) include options to remove unnecessary using statements, which is very useful for tidying the code.

In general I like to remove unused using statements as they clutter up the code.
ReSharper grays out unused using statements.
It has a right click menu for, "Remove unused using statements" also.

Using statements are only used by the compiler for type resolution so feel free to remove them if they are not needed. Having extra will not hurt performance and removing them will only slightly improve compilation time.

If classes with simular names exists in different namespaces it could make it harder to follow the code.

The unused ones will be removed on compile time so it makes no difference, don't worry.

Here is probably the definitive post on performance of using statements: Do namespace using directives affect Assembly Loading?

The only harm it could cause would be if two of the namespaces happened to have a class of the exact same name within it: but at that point, the IDE would warn you.

Code tools will tell you if they are superfluous. I would just leave them. They don't do any harm. (Resharper for instance)

In the past when I manually hand removed unused INCLUDEs, it had no effect on memory or speed.
As others have mentioned here, there could be collision issues but if they're all .NET classes, I wouldn't worry too much about it.