A Microsoft acumulou em muitos anos um conhecimento no desenvolvimento de aplicações e elaborou uma coleção de ferramentas auxiliares para desenvolvimento. Mas simplesmente organizar não era o suficiente, devido ao enorme conjunto de funcionalidades tornou-se fundamental separar esses 'códigos auxiliares'.
Fazendo uma analogia se você fizer um site web com muitas imagens. A primeira vez você é obrigado a publicar todas as imagens mas você vai fazer isso em todas as suas publicações ? Mesmo se fossem muitas imagens e sua Internet lenta ? Não há motivo para fazer isso, por isso eu publicaria tudo na primeira vez e excluiria a pasta de imagens do projeto para não perder tempo publicando muitas imagens.
Mesmo com os computadores de hoje seria um tremendo disperdício ficar adicionando um monte de funcionalidades que o programa não usa. É uma questão de bom senso.
Realmente, com os anos acumulamos muitos recursos e uma empresa como a Microsoft então nem se fala. Sendo assim qual seria o critério de separação ? A Microsoft fez o seguinte : Separou os códigos por suas funcionalidades. Sendo assim, ela agrupou as funcionalidades que possuia em bibliotecas de funcionalidades com propósitos específicos. Por exemplo todas as funções que trabalham com arquivos do sistema operacional em uma biblioteca ( digamos lib, abreviação de library). As funcionalidades que mexem com imagens em outra biblioteca, as que trabalham com gráficos, em outra.
Sendo assim a Microsoft agrupou as bibliotecas de funcionalidades em grupos e ao invés de chamar de 'biblioteca de funcionalidades' eles chamaram de 'NameSpace'. Portanto, NameSpace são coleções de funcionalidades que atuam com o mesmo objetivo .
Portanto, se você vai trabalhar com arquivos texto deve saber que precisará incluir a NameSpace SYSTEM.IO para trabalhar com eles. Com o tempo você acaba memorizando as principais NameSpaces do .NET e sempre que você procurar no google por uma funcionalidade os sites vão te informar a qual NameSpace ela pertence, já que é um mar de códigos.
Uma NameSpace é uma biblioteca de funcionalides pertinentes ao .NET nativamente que agregam recursos facilitando o desenvolvimento de aplicações.
Uma referência é a utilização de um recurso externo áo Visual Studio mas que já está instalado no Windows, por exemplo. Citando um exemplo quando você instala o OFFICE na sua máquina um conjunto de recursos é adicionado ao sistema para abrir o OFFICE. Mas e se você quiser abrir um documento do Office na sua aplicação ? Já que o recurso está adicionado ao sistema operacional a Microsoft deixa alguns elementos como 'publicos' para que as aplicações 'enxerguem' e possam acessar estas funcionalidade do OFFICE. Com isto podemos abrir uma planilha do Excel dentro da nossa aplicação como se o Excel fosse parte da nossa App e para incorporar este recurso (OFFICE) na nossa aplicação basta fazer a referência a um objeto público do OFFICE chamado Microsoft.Interop.
1. Microsoft.VisualBasic: Contêm as classes que suportam a compilação e geração de código em linguagem Visual Basic.
2. Microsoft.Win32: Contêm as classes que suportam os eventos originados pelo sistema operacional e a manipulação do registro.
3.System: Contêm as classes fundamentais e básicas do framework.NET, tais como: tipos, eventos, handlers, interfaces, atributos, exceções etc.
4. System.CodeDom: Contêm as classes que suportam os elementos e estrutura de source code document.
5. System.CodeDom.Compiler: Contêm as classes que suportam a geração e compilação de Code Document Object Model (CodeDOM).
6. System.Collectíons: Contêm as classes que suportam a definição de coleções de objetos, como listas, vetores, etc.
7. Collections.Spedalized: Contêm as classes que suportam coleções específicas, como vetores de bits. coleção de strings, etc.
8. System.ComponentModel: Contêm as classes que suportam a implementação de comportamento em tempo de: -ojeto e de compilação dos controles.
9. System.ComponentModel.Design: Contêm as classes que suportam os serviços em tempo de projeto.
10. System.ComponentModeLDesign.Serialization: Contêm as classes que suportam a serialization de componentes.
11. System.Configuration.Assemblies: Contêm as classes que suportam a configuração de um Assembly.
12. System.Configuration.Install: Contêm as classes que suportam a criação de instaladores customizados para os componentes customizados.
13. System.Data: Contêm as classes que constituem a arquitetura ADO.NET.(*)
14. System.Data.Common: Contêm as classes compartilhadas dos ADO.NET Data Providers.
15. System.Data.OleDb: Contêm as classes que suportam o objeto OLE DB Data Provider.(*)
16. System.Data.SqlClient: Contêm as classes que suportam o objeto SQL Server Data Provider.(*)
17. System.Data.SqlTypes: Contêm as classes que suportam os tipos nativos do SQL Server.
18. vSystem.DirectoryServices: Contêm as classes que suportam Active Directory.
10. System.Drawing: Contêm as classes que suportam as funcionalidades gráficas GDI+.
11. System.Drawing.Design: Contêm as classes que suportam extensões lógicas e desenho da interface de usuário (Ul).
12. System.Drawíng.Drawing2D: Contêm as classes que suportam funcionalidades gráficas adicionais de vetores e 2D.
13. System.Drawing.Imaging: Contêm as classes que suportam funcionalidades avançadas de imagens como GDI+.
14. System.Drawing.Printing: Contêm as classes que suportam a impressão customizada.
15. System.Drawing.Text: Contêm as classes que suportam funcionalidades avançadas de tipografia com GDI+ (fontes, por exemplo).
16. System. Globalization: Contêm as classes que suportam a definição de culturas, regional settings, idiomas, etc.
17. System.IO: Contêm as classes que suportam leitura e escrita assíncrona e síncrona em arquivos e streams.(*)
18. System.IO.IsolatedStorage: Contêm as classes que suportam dados isolados do sistema.
19. System. Diagnostícs: Contêm as classes que suportam as ferramentas de depuração da aplicação, trace, event logs, etc.
(*) Estas Namespaces você deverá manter na sua mente porque são muito utilizadas.