C#の名前空間とは？usingの使い方からnamespaceの書き方・エラー対処まで初心者向けに解説

この記事では、C#の名前空間の役割から、namespaceとusingの書き方、エラーが発生したときの対処法、実務での設計方法まで、初心者にもわかりやすく解説します。

1. C#の名前空間とは？初心者向けに役割をわかりやすく解説

1-1. 名前空間とはクラスや型を整理するための仕組み

C#の名前空間とは、クラス、構造体、インターフェイス、列挙型、デリゲートなどの型をグループ分けするための仕組みです。

たとえば、ショッピングサイトのプログラムには、次のようなさまざまなクラスが存在します。

• ユーザーを表すUserクラス

• 商品を表すProductクラス

• 注文を表すOrderクラス

• 決済処理を担当するPaymentServiceクラス

小規模なプログラムであれば、すべてのクラスを同じ場所に置いても管理できるでしょう。しかし、クラスが数十個、数百個と増えると、それぞれの役割がわかりにくくなります。

そこで、次のように名前空間を使って分類します。

namespace ShoppingApp.Users{public class User{}}
namespace ShoppingApp.Products{public class Product{}}
namespace ShoppingApp.Orders{public class Order{}}

名前空間を見るだけで、そのクラスがどの機能に関係しているのかを判断しやすくなります。

1-2. 名前空間を使う理由：名前の衝突を防ぐ

名前空間には、型を整理するだけでなく、同じクラス名の衝突を防ぐ役割もあります。

たとえば、システム内に次の2種類のUserクラスが必要になる場合を考えてみましょう。

namespace ShoppingApp.Customers{public class User{}}
namespace ShoppingApp.Admins{public class User{}}

クラス名はどちらもUserですが、完全な名前は異なります。

ShoppingApp.Customers.UserShoppingApp.Admins.User

このように、C#では名前空間を含めた名前によって型を区別できます。

名前空間を使用しない状態で同じスコープに同名のクラスを定義すると、コンパイラがどちらのクラスなのか判断できません。規模の大きなシステムや外部ライブラリを利用するプログラムでは、名前空間による区別が特に重要です。

1-3. フォルダ・クラス・プロジェクトとの違い

名前空間、フォルダ、クラス、プロジェクトは、それぞれ役割が異なります。

名前空間は、C#の型を論理的に分類する仕組みです。

フォルダは、ソースファイルをファイルシステム上で整理する仕組みです。

クラスは、データや処理をまとめて表現する型の一種です。

プロジェクトは、ソースコード、設定、参照ライブラリなどをまとめ、アプリケーションやライブラリとしてビルドする単位です。

たとえば、次のようなフォルダ構成があるとします。

ShoppingApp├─ Users│  └─ User.cs└─ Orders└─ Order.cs

フォルダに合わせて、次の名前空間を指定できます。

namespace ShoppingApp.Users;
public class User{}

ただし、C#のコンパイラにとってフォルダと名前空間は別のものです。Usersフォルダにあるファイルだからといって、必ずShoppingApp.Users名前空間に所属するわけではありません。

次のように、フォルダと異なる名前空間を書くこともできます。

namespace MyCompany.Members;
public class User{}

技術的には問題ありませんが、フォルダ構成と名前空間が大きく異なると、目的のクラスを探しにくくなります。実務では、できるだけ両者を対応させるのが一般的です。

1-4. 名前空間が使われる具体例

.NETの標準ライブラリも、多数の名前空間に分けて整理されています。

代表的な例は次のとおりです。

SystemSystem.Collections.GenericSystem.IOSystem.LinqSystem.Net.HttpSystem.TextSystem.Threading.Tasks

たとえば、List<T>はSystem.Collections.Generic名前空間に所属しています。

System.Collections.Generic.List<string> names = new();

FileクラスはSystem.IO名前空間に所属しています。

string text = System.IO.File.ReadAllText("sample.txt");

標準ライブラリだけでなく、ASP.NET Core、Unity、Entity Framework Core、各種NuGetパッケージでも名前空間が広く使われています。

2. C#のnamespaceの基本的な書き方

2-1. ブロック形式のnamespaceの書き方

従来から使われているのが、波かっこで範囲を囲むブロック形式です。

namespace SampleApp{public class Program{public static void Main(){Console.WriteLine("Hello");}}}

namespace SampleAppから始まり、波かっこ内に書かれた型がSampleApp名前空間に所属します。

階層のある名前空間も指定できます。

namespace SampleApp.Services.Users{public class UserService{}}

このクラスの完全修飾名は、次のようになります。

SampleApp.Services.Users.UserService

2-2. ファイルスコープnamespaceの書き方

ファイルスコープnamespaceは、名前空間名の後ろにセミコロンを書く形式です。

namespace SampleApp.Services;
public class UserService{}

この形式では、宣言より後ろにあるファイル内の型が、すべて指定した名前空間に所属します。

ブロック形式と比べると、波かっことインデントを1段減らせます。

ブロック形式は次のようになります。

namespace SampleApp.Services{public class UserService{public void Execute(){}}}

ファイルスコープ形式では、同じコードを次のように書けます。

namespace SampleApp.Services;
public class UserService{public void Execute(){}}

ファイルスコープnamespaceは、1つのファイルに1つだけ宣言できます。また、同じファイル内でファイルスコープ形式とブロック形式を混在させることはできません。

2-3. namespace内にクラスを書く基本構文

名前空間内には、クラス以外の型も定義できます。

namespace SampleApp.Models{public class User{}
public interface IUserRepository{}public struct UserId{}public enum UserStatus{Active,Inactive}public delegate void UserChangedHandler(User user);
}

ファイルスコープ形式でも同様です。

namespace SampleApp.Models;
public class User{}
public interface IUserRepository{}

1つのファイルに複数の型を書くことは可能ですが、実務では原則として主要な型ごとにファイルを分けると管理しやすくなります。

2-4. 複数のnamespaceを1つのファイルに書く場合

ブロック形式であれば、1つのファイルに複数の名前空間を書けます。

namespace SampleApp.Customers{public class User{}}
namespace SampleApp.Admins{public class User{}}

名前空間を入れ子にすることも可能です。

namespace SampleApp{namespace Services{public class UserService{}}}

この場合の完全修飾名は、次のとおりです。

SampleApp.Services.UserService

ただし、1つのファイルに複数の名前空間を書くと、ファイルの役割がわかりにくくなることがあります。特別な理由がなければ、名前空間や型ごとにファイルを分けるほうが管理しやすいでしょう。

2-5. namespace名の命名規則と一般的な付け方

名前空間名には、一般的にパスカルケースを使用します。

namespace MyCompany.ShoppingApp.OrderManagement;

よく使われる構成は次のとおりです。

会社名.製品名.機能名

具体例を挙げると、次のようになります。

ExampleCompany.ShoppingAppExampleCompany.ShoppingApp.UsersExampleCompany.ShoppingApp.OrdersExampleCompany.ShoppingApp.Payments

名前空間名を決めるときは、次の点を意識しましょう。

• 内容が推測できる名前にする

• 略語を多用しない

• 単語の先頭を大文字にする

• クラス名と同じ名前を避ける

• 将来の機能追加を考えて細かく分けすぎない

たとえば、DataやCommonのような広すぎる名前空間に多くのクラスを集めると、役割が曖昧になりやすいため注意が必要です。

3. usingとは？名前空間を簡単に使うための仕組み

3-1. usingディレクティブの役割

usingディレクティブは、指定した名前空間内の型を、名前空間部分を省略して利用できるようにする構文です。

using System.Collections.Generic;
List<string> names = new();

List<T>は、本来System.Collections.Generic名前空間に所属しています。

using System.Collections.Generic;を書くことで、次の完全修飾名を省略できます。

System.Collections.Generic.List<string> names = new();

ここで扱っているのは、名前空間を取り込むusingディレクティブです。ファイルやデータベース接続などのリソースを破棄するusingステートメントとは役割が異なります。

3-2. usingを書かない場合の完全修飾名

usingを書かなくても、名前空間を含む完全修飾名を記述すれば型を利用できます。

System.Text.StringBuilder builder = new();builder.Append("Hello");

using System.Text;を書いた場合は、次のように短くできます。

using System.Text;
StringBuilder builder = new();builder.Append("Hello");

完全修飾名はコードが長くなる一方で、どの名前空間の型を使っているかが明確になるメリットがあります。

同名のクラスが存在してusingだけでは区別できない場合にも、完全修飾名が役立ちます。

3-3. using System; の意味

using System;は、System名前空間内の型を短い名前で利用するための宣言です。

using System;
Console.WriteLine("Hello");DateTime now = DateTime.Now;Guid id = Guid.NewGuid();

using System;がない場合は、次のように書けます。

System.Console.WriteLine("Hello");System.DateTime now = System.DateTime.Now;System.Guid id = System.Guid.NewGuid();

using System;を書いても、System以下のすべての子名前空間が自動的に利用可能になるわけではありません。

たとえば、List<T>を利用するには、通常は別途System.Collections.Genericを指定します。

using System;using System.Collections.Generic;

3-4. よく使うusingの例

コンソールアプリケーションや一般的な.NETアプリケーションでは、次の名前空間がよく使われます。

using System;using System.Collections.Generic;using System.IO;using System.Linq;using System.Net.Http;using System.Text;using System.Threading;using System.Threading.Tasks;

それぞれの主な用途は次のとおりです。

Systemは、Console、DateTime、Exceptionなどの基本的な型を提供します。

System.Collections.Genericは、List<T>やDictionary<TKey, TValue>などのコレクションを提供します。

System.IOは、ファイルやディレクトリを操作する型を提供します。

System.Linqは、コレクションの絞り込み、並べ替え、集計などに利用するLINQの機能を提供します。

System.Net.Httpは、HTTP通信に使用するHttpClientなどを提供します。

System.Textは、文字列操作やエンコーディング関連の型を提供します。

System.Threading.Tasksは、Taskを使用した非同期処理に利用します。

3-5. 不要なusingは削除してもよいのか

実際に使用していないusingは、基本的に削除して問題ありません。

不要なusingを削除すると、ファイルが読みやすくなり、現在使用している名前空間を把握しやすくなります。

Visual Studioでは、クイックアクションやコードのクリーンアップ機能を使って、不要なusingを整理できます。

ただし、見た目では使われていないように見えても、拡張メソッドの解決に必要な場合があります。

たとえば、次のWhereはSystem.Linqが提供する拡張メソッドです。

using System.Linq;
int[] numbers = { 1, 2, 3, 4 };var evenNumbers = numbers.Where(number => number % 2 == 0);

using System.Linq;を削除すると、環境によってはWhereが見つからないというエラーになります。IDEが「不要」と判断しているか、削除後にビルドが成功するかを確認しましょう。

4. namespaceとusingの違い

4-1. namespaceは「定義する」もの

namespaceは、クラスなどの型が所属する名前空間を定義します。

namespace SampleApp.Models;
public class User{}

このコードでは、UserクラスをSampleApp.Models名前空間に所属させています。

完全修飾名は次のとおりです。

SampleApp.Models.User

4-2. usingは「参照しやすくする」もの

usingは、別の名前空間に所属する型を短い名前で記述できるようにします。

using SampleApp.Models;
User user = new();

using SampleApp.Models;を書いても、現在のクラスがSampleApp.Models名前空間に移動するわけではありません。

あくまで、そのファイル内でSampleApp.Models.UserをUserと書けるようにしているだけです。

4-3. 初心者が混同しやすいポイント

初心者が混同しやすいのは、usingによって名前空間そのものが読み込まれたり、クラスの所属先が変更されたりすると考えてしまう点です。

次のコードを見てみましょう。

using SampleApp.Models;
namespace SampleApp.Services;
public class UserService{private readonly User _user = new();}

UserServiceの所属先は、namespaceで指定したSampleApp.Servicesです。

一方、Userはusingで参照しやすくしたSampleApp.Models.Userです。

それぞれの完全修飾名は次のようになります。

SampleApp.Services.UserServiceSampleApp.Models.User

4-4. namespaceとusingの関係をコード例で理解する

まず、モデルを定義します。

namespace SampleApp.Models;
public class User{public string Name { get; set; } = "";}

次に、別の名前空間にサービスを定義します。

using SampleApp.Models;
namespace SampleApp.Services;
public class UserService{public User Create(string name){return new User{Name = name};}}

この例では、namespace SampleApp.Services;がUserServiceの所属先を定義しています。

using SampleApp.Models;は、SampleApp.Models.UserをUserという短い名前で使用できるようにしています。

5. C#で名前空間を使ったサンプルコード

5-1. 同じnamespace内のクラスを呼び出す例

同じ名前空間に所属するクラスは、通常、usingを書かずに利用できます。

namespace SampleApp.Services;
public class MessageService{public string CreateMessage(){return "Hello";}}
public class ApplicationService{public void Run(){MessageService service = new();Console.WriteLine(service.CreateMessage());}}

MessageServiceとApplicationServiceは、どちらもSampleApp.Servicesに所属しているため、名前空間を省略できます。

別々のファイルに分かれていても、同じ名前空間であれば同様です。

5-2. 別namespaceのクラスをusingで呼び出す例

別の名前空間にあるクラスを利用する場合は、usingを書くと簡潔です。

User.csを次のように定義します。

namespace SampleApp.Models;
public class User{public string Name { get; set; } = "";}

Program.csから利用します。

using SampleApp.Models;
namespace SampleApp;
public class Program{public static void Main(){User user = new(){Name = "Tanaka"};
    Console.WriteLine(user.Name);}
}

using SampleApp.Models;があるため、SampleApp.Models.UserをUserと記述できます。

5-3. 完全修飾名でクラスを呼び出す例

usingを使わず、完全修飾名で呼び出すことも可能です。

namespace SampleApp;
public class Program{public static void Main(){SampleApp.Models.User user = new(){Name = "Tanaka"};
    Console.WriteLine(user.Name);}
}

コードは長くなりますが、使用している型の所属先が明確になります。

5-4. 同じクラス名がある場合の名前空間の使い分け

異なる名前空間に同じ名前のクラスがある場合、両方の名前空間をusingすると名前が曖昧になります。

using SampleApp.Customers;using SampleApp.Admins;
User user = new();

UserがCustomers.UserなのかAdmins.Userなのか判断できないため、コンパイルエラーになります。

この場合は、完全修飾名を使用します。

SampleApp.Customers.User customer = new();SampleApp.Admins.User admin = new();

一方だけをusingし、もう一方を完全修飾名で書く方法もあります。

using SampleApp.Customers;
User customer = new();SampleApp.Admins.User admin = new();

5-5. using aliasで名前の衝突を回避する方法

usingエイリアスを使うと、型や名前空間に別名を付けられます。

using CustomerUser = SampleApp.Customers.User;using AdminUser = SampleApp.Admins.User;
CustomerUser customer = new();AdminUser admin = new();

名前空間自体に別名を付けることもできます。

using CustomerModels = SampleApp.Customers;using AdminModels = SampleApp.Admins;
CustomerModels.User customer = new();AdminModels.User admin = new();

同名の型を何度も使用する場合は、完全修飾名を繰り返すより、エイリアスを使うと読みやすくなります。

6. C#の名前空間でよくあるエラーと対処法

6-1. 型または名前空間の名前が見つからないエラー

C#の名前空間に関する代表的なエラーは、次のようなものです。

型または名前空間の名前 'User' が見つかりませんでした

英語環境では、次のように表示されることがあります。

The type or namespace name 'User' could not be found

このエラーは、コンパイラが指定された型や名前空間を特定できないときに発生します。

主な原因は次のとおりです。

• 必要なusingがない

• 名前空間名やクラス名を間違えている

• プロジェクト参照が追加されていない

• NuGetパッケージがインストールされていない

• クラスがpublicではない

• 対象ファイルがプロジェクトに含まれていない

• 条件付きコンパイルによって型が除外されている

エラーメッセージだけで判断せず、型がどのプロジェクトと名前空間に定義されているかを順番に確認しましょう。

6-2. usingが不足している場合の対処

利用したいクラスが別の名前空間にある場合は、適切なusingを追加します。

たとえば、List<T>が見つからない場合は次の記述を確認します。

using System.Collections.Generic;

StringBuilderが見つからない場合は、次のusingが必要です。

using System.Text;

Visual Studioでは、エラーになっている型名にカーソルを合わせ、クイックアクションから候補のusingを追加できることがあります。

ただし、usingを追加するだけでは解決しないケースもあります。対象のアセンブリやプロジェクトが参照されていなければ、名前空間を指定しても型は利用できません。

6-3. namespace名のスペルミスを確認する

単純なスペルミスもよくある原因です。

using System.Collection.Generic;

正しくは、CollectionではなくCollectionsです。

using System.Collections.Generic;

自作の名前空間でも、大文字と小文字を含めて確認します。

using SampleApp.Model;

実際の名前空間が次のようになっている場合、名前が一致していません。

namespace SampleApp.Models;

C#では識別子の大文字と小文字が区別されます。

SampleApp.Modelssampleapp.models

これらは別の名前として扱われます。

6-4. 参照やパッケージが追加されていない場合の対処

usingは、参照されていないライブラリを自動的に追加する機能ではありません。

別プロジェクトのクラスを使用する場合は、利用側のプロジェクトから定義側のプロジェクトへの参照が必要です。

たとえば、次の構成があるとします。

SampleApp.WebSampleApp.Core

SampleApp.WebからSampleApp.Coreのクラスを使用するには、SampleApp.WebにSampleApp.Coreへのプロジェクト参照を追加します。

コマンドラインでは、次のように追加できます。

dotnet add SampleApp.Web reference SampleApp.Core

外部ライブラリの場合は、必要なNuGetパッケージを追加します。

dotnet add package パッケージ名

パッケージを追加した後、そのライブラリが公開している名前空間をusingで指定します。

つまり、次の2つは別の操作です。

1. プロジェクト参照やパッケージ参照によってライブラリを利用可能にする

2. usingによって型名を短く書けるようにする

6-5. クラスのアクセス修飾子が原因の場合

別のプロジェクトからクラスを利用する場合、対象のクラスがpublicである必要があります。

次のクラスにはアクセス修飾子がありません。

namespace SampleApp.Core;
class UserService{}

名前空間直下のクラスでアクセス修飾子を省略すると、既定ではinternalになります。internalの型は、原則として同じアセンブリ内からのみ利用できます。

別のプロジェクトから利用する場合は、publicを付けます。

namespace SampleApp.Core;
public class UserService{}

クラスがpublicでも、コンストラクターやメソッドがprivateまたはinternalであれば、利用できる範囲が制限されます。

public class UserService{private UserService(){}}

このクラスは外部からnew UserService()で生成できません。型だけでなく、利用するメンバーのアクセス修飾子も確認しましょう。

6-6. Visual Studioでusing候補が出ないときの確認点

Visual Studioでクイックアクションを実行してもusing候補が表示されない場合は、次の点を確認します。

まず、対象のクラスがソリューション内または参照ライブラリ内に存在するか確認します。

次に、プロジェクト参照やNuGetパッケージが正しく追加されているか確認します。

対象クラスが別プロジェクトにある場合は、publicになっているかも確認してください。

そのほか、次の操作で改善する場合があります。

• ソリューションをビルドし直す

• NuGetパッケージを復元する

• 対象プロジェクトを再読み込みする

• Visual Studioを再起動する

• binフォルダとobjフォルダを削除して再ビルドする

• ソリューション内の既存のコンパイルエラーを解消する

• 対象プロジェクトのターゲットフレームワークを確認する

同名の型が複数存在する場合は、候補が自動追加されないこともあります。その場合は、完全修飾名またはusingエイリアスを手動で記述します。

7. C#の名前空間に関する実務での使い方

7-1. プロジェクト名とnamespaceの関係

Visual Studioやdotnet newでプロジェクトを作成すると、プロジェクト名を基にした名前空間が初期値として使われることがあります。

たとえば、プロジェクト名がShoppingAppであれば、次のような名前空間が生成されます。

namespace ShoppingApp;

ただし、プロジェクト名と名前空間は必ず一致しなければならないわけではありません。

namespace ExampleCompany.ECommerce;

プロジェクト名と異なる名前空間を使用しても、C#の文法上は問題ありません。

一方で、プロジェクト名、アセンブリ名、ルート名前空間が大きく異なると、コードの所属先を把握しにくくなります。特別な命名方針がなければ、ある程度そろえると管理しやすくなります。

7-2. フォルダ構成とnamespaceは合わせるべきか

フォルダ構成と名前空間を完全に一致させる義務はありませんが、実務では対応させるのが一般的です。

次のフォルダ構成を考えてみましょう。

ShoppingApp├─ Models│  └─ User.cs├─ Services│  └─ UserService.cs└─ Repositories└─ UserRepository.cs

対応する名前空間は次のようになります。

ShoppingApp.ModelsShoppingApp.ServicesShoppingApp.Repositories

これにより、クラス名や名前空間からファイルの場所を推測できます。

ただし、フォルダを細かく分けすぎた結果、名前空間が過度に長くなる場合は、必ずしも全階層を反映する必要はありません。

ShoppingApp.Features.Users.Application.Commands.CreateUser

階層が深すぎると、完全修飾名やusingが読みにくくなります。プロジェクトの規模や設計方針に応じて、意味のある単位で分割しましょう。

7-3. 大規模開発で名前空間を整理するメリット

大規模なC#開発では、名前空間の設計によってコードの理解しやすさが大きく変わります。

適切に整理すると、次のようなメリットがあります。

• クラスの役割を把握しやすい

• 同名クラスの衝突を防ぎやすい

• 関連する機能を検索しやすい

• モジュール間の依存関係を把握しやすい

• 新しいメンバーがコード構成を理解しやすい

• 公開APIと内部実装を分類しやすい

たとえば、機能別に整理する場合は次のような名前空間を使用できます。

ShoppingApp.UsersShoppingApp.OrdersShoppingApp.PaymentsShoppingApp.Inventory

層別に整理する場合は次のようになります。

ShoppingApp.DomainShoppingApp.ApplicationShoppingApp.InfrastructureShoppingApp.Web

どちらが正解というわけではありません。重要なのは、チーム内で一貫したルールを決めることです。

7-4. ライブラリやNuGetパッケージ利用時のnamespace

NuGetパッケージをインストールしても、必ずパッケージ名と同じ名前空間をusingするとは限りません。

たとえば、あるパッケージの名前がExample.Json.Extensionsでも、公開されている型が次の名前空間に所属している可能性があります。

using Example.Json;

パッケージ名、アセンブリ名、名前空間名は、それぞれ別の名前を持てます。

利用方法がわからない場合は、次の情報を確認しましょう。

• パッケージの公式ドキュメント

• READMEのサンプルコード

• APIリファレンス

• Visual Studioのオブジェクトブラウザー

• 型の定義へ移動

• IntelliSenseに表示される完全修飾名

パッケージを追加しただけで型が見つからない場合は、正しい名前空間を使用しているか、対象のバージョンにその型が含まれているかを確認します。

7-5. ASP.NETやUnityでの名前空間の使われ方

ASP.NET Coreでは、コントローラー、モデル、サービスなどを名前空間で整理します。

namespace ShoppingApp.Web.Controllers;
public class UsersController{}

namespace ShoppingApp.Application.Services;
public class UserService{}

レイヤーや機能ごとに名前空間を分けることで、Web層、アプリケーション層、ドメイン層などの責務を明確にできます。

Unityでも、自作スクリプトを名前空間に入れることで、別のアセットやパッケージに含まれるクラスとの名前衝突を防げます。

namespace MyGame.Characters{public class PlayerController{}}

特にUnityでは、GameManager、Player、InputManagerなどの一般的なクラス名が重複しやすいため、プロジェクト固有の名前空間を使用すると安全です。

ただし、Unityのコンポーネントを別の名前空間へ移動すると、既存コードの参照やシリアライズされた情報に影響する場合があります。運用中のプロジェクトで名前空間を変更するときは、参照箇所を確認しながら進めましょう。

8. C#のnamespaceに関するよくある質問

8-1. namespaceは必ず書く必要がある？

C#では、namespaceを必ず書く必要はありません。

名前空間を指定せずにクラスを定義することもできます。

public class User{}

このクラスは、明示的な名前を持たないグローバル名前空間に所属します。

小さなサンプルコードでは問題ありませんが、実際のアプリケーションでは名前の衝突や管理の難しさにつながります。複数のクラスを持つプロジェクトやライブラリでは、基本的に名前空間を指定するのがおすすめです。

8-2. namespace名は自由に決めてもよい？

C#の識別子として有効な名前であれば、名前空間名は基本的に自由に決められます。

namespace MyApplication;

階層を表すためにピリオドも使用できます。

namespace MyCompany.MyApplication.Services;

ただし、自由に決められるからといって、短すぎる名前や一般的すぎる名前は避けたほうがよいでしょう。

namespace App;namespace Common;namespace Test;

他のライブラリと衝突しにくく、所属先を判断しやすい名前にします。

namespace ExampleCompany.InventoryApp.Services;

なお、名前空間名にピリオドを使っても、名前空間オブジェクトが実行時に階層構造を持つわけではありません。ピリオドを含む名前によって、論理的な階層を表現しています。

8-3. usingと参照の追加は何が違う？

参照の追加は、別のプロジェクトやライブラリに含まれる型を、コンパイル対象として利用可能にする操作です。

usingは、すでに利用可能な型を完全修飾名なしで記述できるようにする操作です。

たとえば、SampleApp.Coreプロジェクトを利用する場合は、最初にプロジェクト参照を追加します。

dotnet add reference ../SampleApp.Core/SampleApp.Core.csproj

その後、ソースコードで名前空間を指定します。

using SampleApp.Core.Services;

参照がなければ、usingを書いても対象の型は見つかりません。

反対に、参照が追加されていれば、usingを書かずに完全修飾名で利用できます。

SampleApp.Core.Services.UserService service = new();

8-4. global usingとは何か？

global usingは、プロジェクト内のすべてのC#ソースファイルに適用されるusingディレクティブです。

global using System;global using System.Collections.Generic;global using System.Linq;

通常のusingは、基本的に記述したファイルだけに適用されます。

using System.Text;

一方、global usingは、1か所に書けば同じプロジェクト内のほかのファイルでも有効になります。

たとえば、GlobalUsings.csというファイルを作成し、共通の宣言をまとめられます。

global using System;global using System.Collections.Generic;global using System.Linq;global using System.Threading.Tasks;

.NETのSDK形式プロジェクトでは、プロジェクト設定によって暗黙的なusingが有効になっている場合もあります。

<PropertyGroup><ImplicitUsings>enable</ImplicitUsings></PropertyGroup>

この設定が有効なテンプレートでは、using System;などを書いていなくても、よく使う名前空間が利用できることがあります。

ただし、暗黙的に追加される名前空間はプロジェクトのSDKによって異なります。コード上にusingが見当たらない場合は、プロジェクトファイルや生成されたグローバルusingを確認しましょう。

8-5. ファイルスコープnamespaceと従来のnamespaceはどちらを使うべき？

1つのファイルに1つの名前空間だけを書く一般的な構成では、ファイルスコープnamespaceが簡潔です。

namespace SampleApp.Services;
public class UserService{}

インデントが1段減るため、クラスのコードを読みやすくできます。

一方、1つのファイルに複数の名前空間を書く必要がある場合や、既存プロジェクトがブロック形式で統一されている場合は、従来の形式が適しています。

namespace SampleApp.Services{public class UserService{}}

どちらを使用しても、名前空間の基本的な機能や実行結果は変わりません。

新規プロジェクトではファイルスコープ形式を採用しやすい一方、既存プロジェクトでは現在のコーディング規約に合わせることが重要です。ファイルごとに形式がばらばらになるよりも、プロジェクト全体で統一されているほうが読みやすくなります。

まとめ

C#の名前空間は、クラスやインターフェイスなどの型を整理し、同じ名前を持つ型の衝突を防ぐための仕組みです。

namespaceは、型の所属先を定義します。

namespace SampleApp.Models;
public class User{}

usingは、別の名前空間にある型を短い名前で利用できるようにします。

using SampleApp.Models;
User user = new();

usingを使用しない場合でも、完全修飾名を指定すれば型を利用できます。

SampleApp.Models.User user = new();

C#の名前空間でエラーが発生したときは、usingだけでなく、名前のスペル、プロジェクト参照、NuGetパッケージ、アクセス修飾子も確認することが大切です。

実務では、プロジェクト名やフォルダ構成と名前空間をある程度対応させ、チーム内で一貫した命名規則を採用すると、コードを管理しやすくなります。namespaceとusingの役割を区別できれば、C#の標準ライブラリや外部パッケージ、自作クラスを迷わず利用できるようになるでしょう。