Develop Reference

using directive with whole program scope

How can I have a using directive that has a scope of the whole program instead of just the file it is in. For every module that I use I would only want to set this once. If there is no way to do this what is the workaround to get this to work.
I thought about putting them all into a header file but C sharp does not have a file include.

This is not possible. Fortunately.
Just wondering why you want to do this. This would be a bad programming habit anyway - put concerns and dependencies only when you really need them. If you add the same using directives everywhere, you also need the referenced assemblies everywhere, something you really don't want to do. Your project should rely on assemblies it needs, no more, no less.
Your argument about wasting time is a bit strange; if you loose so much time, you might have another problem in your architecture.
Note: Resharper is a tool that you may find useful.

Sorry, but what you are trying to achieve is not possible and I don't think that there are any workarounds. This is supported for example in WebForms or Razor views where you could declare common namespaces in the <namespaces> section of your web.config but unfortunately such artifact doesn't exist for standard C# files.

Having the using directives in each single .cs file allows you to take that file out of an existing project and drop it into another project, provided it has the same references.
Also, adding using directives is basically automatic at this point. My tool of choice, ReSharper. Place the cursor on whatever class isn't recognized, press Alt+Enter, and the using directive gets added automatically. If there are multiple choices, you get to pick the right one.

Multiple namespaces in a single project

I find that sometimes I have the need to have multiple namespaces in a project I'm working on - are there any problems that may arise from having multiple namespaces in the same project?
The alternative is obviously having multiple projects (per namespace) in the Solution.

Yes, it's fine. Often my namespaces align to the folder structure of the project. So the top-level namespace might be the same for the whole project, but there would be multiple sub-namespaces.
The purposes of namespaces are (1) organization and (2) avoiding naming collisions, not necessarily in that order. Whereas, separating things into multiple projects is more because you want multiple binaries or you want to share code between multiple solutions. These are somewhat orthogonal concerns.

Yes many classes to a single namespace. Many namespaces in a project is totally fine. It is cosmetic.

The answer to this question, without getting into best practices, is that there won't be any technical problems from using multiple namespaces in one project.
However, visual studio only supports one base namespace, which is located in the project properties (right click properties in solution explorer on the project itself) and any time you create a new file, it will be created with this default namespace (if on root), or the default namespace plus whichever folder structure you have.
Not a problem per se, but you'll need to manually check each new C# file you add to the project and change the namespace accordingly if that particular file will not be using the default namespace for the project.

Import all subclasses like Java but in C#

This is such a dumb question, but I can't figure out the lingo to ask Google.
In Java if I wanted to import all subclasses I would use something like
java.util.*
And all of util would be imported.
Firstly, what is the proper lingo for what I'm doing in C# so I can start using Google more effectively. Am I importing namespaces? Libraries? Subclasses? (Can you tell I'm new at this?)
Secondly, since I'm here, how is this accomplished in C#?
PS- I did click on every related question stackOverflow threw at me to see if the answer would pop up. No luck. I'm simply without words to describe what I'm looking for. The example should do just fine but... Anyone who can take a moment to either explain the lingo to me or perhaps simply point me at something that can (in a nutshell, I have a couple books for the long haul) that would be great.

Firstly, let's differentiate between assembly references and namespaces.
Assemblies are what you add references to in your c# project, they are the libraries that contain the actual classes you need, usually found as DLL files. The .net framework contains many such assemblies, and Visual Studio will try to reference the most commonly used ones in your project (e.g. for a WinForms project it will automatically add a reference to System.Drawing.dll).
Namespaces are logical partitions of the classes in an assembly.
Once you reference an assembly in the project, all classes in all namespaces are available for use, if you provide their full name.
This is where the using directive comes in.
It is simply syntactic sugar for not having to write very long names all the time.
For example, assuming your project references the System.Drawing.dll assembly, you would have to qualify a class from this assembly using it's full name, for example
System.Drawing.Imaging.BitmapData
Because this is tiresome and bloats the code, if you start your .cs file with
using System.Drawing.Imaging;
you could then instantiate a class using just the name BitmapData.
This will be true only for the .cs file in which you added the using directive, not for the whole project.
Also, it's important to note that using one namespace does not bring in all nested namespaces, you have to using each one individually.

You must brush up on your your Google-fu
http://www.harding.edu/fmccown/java_csharp_comparison.html#namespaces

It can be called importing / referencing/ using namespace.
Such a language feature is not available in c#.
A little explanation: Namesspaces can be spread across multiple libraries. so when you use a namespace it may refer to it from multiple referenced assemblies.

It's called namespace and it's imported by a keyword using. For example:
using System;
This statement enables you to reference all the classes that exist in that namespace. They, however don't enable you to reference any class in the subnamespace of declared namespace. You have to declare each namespace separately. For example:
using System;
using System.Text;
Of course, you need to have a proper references added to the project where you're specifying the using directive.

Within .Net, you first would need to ensure that there is a referenced assembly containing the namespace you would like to import. Once that reference exists, you can use the 'using' directive to bring that namespace into the class so as to not have to fully qualify all object names. You can find more information on this directive on MSDN.
If I misunderstood, let me know and I'll do my best to get you pointed in the right direction.

What is best thing to call your namespace in .Net

In the past I've always gone and called my namespace for a particular project the same as the project (and principle class) e.g.:
namespace KeepAlive
{
public partial class KeepAlive : ServiceBase
{...
Then from other projects whenever i've called that class its always been:
KeepAlive.KeepAlive()...
I'm now beginning to think that this might not be such a good idea, but I'm sort of stumped what to actually call my namespace. What do other people do? Do you just have one namespace for all your projects?

We have this simple scheme:
CompanyName.ProductName
Then the application layer, e.g.
CompanyName.ProductName.Data
CompanyName.ProductName.Web
etc.
And inside divided per module and/or functionality, which normally correspond to folders
CompanyName.ProductName.Web.Shop
CompanyName.ProductName.Web.Newsletter
etc.
BTW: You can find answers to similar questions here:
.NET namespaces
Should the folders in a solution match the namespace?

Having the name of a class being the same as the namespace is a bad idea - it makes it quite tricky to refer to the right thing in some cases, in my opinion.
I usually call the project (and namespace) an appropriate name and then have "EntryPoint" or "Program" for the entry point where appropriate. In your example, I'd probably call the class "KeepAliveService".

CompanyName.ProductName.AreaOfSystem.SubAreaOfSystem
Never call them the same name as a class.
Our areas include things like:
Services
Smartcard
UI
Sub-areas are used sparingly but when relevant:
Smartcard.Mifare
Smartcard.DESFire
Ours don't correspond to folders because logically that may not be the case. To ease solution explorer navigation we might section off certain bits in folders but that doesn't necessarily mean the namespaces should follow the folder structure. Especially if there are only a few files in the folder (a namespace with few types is usually silly).

i name my namespaces with the common descriptor of all the things that go into that namespace.

I like the java package way: com.stackoverflow.Data (or whatwever the primary domain name of your company may be).
That way your namespaces won't be ambiguous.

we stick to the old
uk.co.company.system.layer
scheme that way we keep collisions down to a miniumum as we use a lot of MS Server products and it helps conceptual seperations.
eg.
uk.co.acme.biztalk.bizutils.

Namespaces in C#

I am using an ASP.NET MVC project and everytime I add a class to a folder it makes really long namespaces.
Example:
Project = Tully.Saps.Data
Folder = DataAccess/Interfaces
Namespace = Tully.Saps.Data.DataAccess.Interfaces
Folder = DataAccess/MbNetRepositories
Namespace = Tully.Saps.Data.DataAccess.MbNetRepositories
Question:
Is it best to leave the namespace alone and add the using clause to the classes that access it or change the namespace to Tully.Saps.Data for everything in this project?

Leave them alone and add the usings. You're asking for trouble manually changing things like that (harder to debug, inconsistent with other projects, et cetera).

It is really up to you how you want to deal with it. If you are only going to be accessing a member of a namespace once or twice, then adding the "using" statement really doesn't do much for you.
If you are going to use it multiple times then reducing the namespace chain is probably going to make things easier to read.
You could always change the namespace so it doesn't add the new folder name if you are just looking to logically group files together, without creating a new namespace.

According to FXCop, and I agree:
Avoid namespaces with few types
A namespace should generally have more than five types.
also (and this applies to the "single namespace" suggestion -- which is almost the same to say as no namespace)
Declare types in namespaces
A type should be defined inside a namespace to avoid duplication.

Namespaces
.Namespaces help us to define the "scope" of a set of entities in our object model or our application. This makes them a software design decision not a folder structure decision. For example, in an MVC application it would make good sense to have Model/View/Controller folders and related namespaces. So, while it is possible, in some cases, that the folder structure will match the namespace pattern we decide to use in our development, it is not required and may not be what we desire. Each namespace should be a case-by-case decision
using statements
To define using statements for a namespace is a seperate decision based on how often the object in that namespace will be referred to in code and should not in any way affect our namespace creation practice.

Leave it. It's one great example of how your IDE is dictating your coding style.

Just because the tool (Visual Studio) you are using has decided that each folder needs a new Namespace doesn't mean you do.
I personally tend to leave my "Data" projects as a single Namespace. If I have a subfolder called "Model" I don't want those files in the Something.Data.Model Namespace, I want them in Something.Data.