PowerShell Add-Type コマンドレット徹底解説：C#連携からDLL利用まで

はじめに

PowerShellは、Microsoft .NET Frameworkまたは.NET Core/.NET 5以降の上に構築されており、その強力な機能は基盤となる.NETプラットフォームに深く根ざしています。通常、PowerShellスクリプトは組み込みコマンドレットや外部ツールとの連携によって様々なタスクを実行しますが、時には.NETのより低レベルな機能に直接アクセスしたり、既存の.NETアセンブリ（DLL）を利用したり、あるいはその場で独自の.NETコード（C#など）をコンパイルして実行したりする必要が出てきます。

このようなシナリオで不可欠となるのが、今回解説するAdd-Typeコマンドレットです。Add-Typeは、PowerShellセッション内に.NETの型定義をロードするために使用されます。これにより、スクリプト内でそれらの型を利用してオブジェクトを作成したり、静的メンバーにアクセスしたりすることが可能になります。

本記事では、Add-Typeコマンドレットの基本的な使い方から、C#コードをその場でコンパイルして実行する方法、既存のDLLを読み込む方法、そしてより高度な機能や利用上の注意点まで、徹底的に解説します。PowerShellの能力を最大限に引き出し、より複雑で効率的なスクリプトを作成するための一助となれば幸いです。

Add-Type とは何か？

Add-Typeコマンドレットは、PowerShellセッションの現在のランタイム環境（AppDomain）に.NETの型（Classes, Structures, Interfaces, Enumsなど）をロードします。これにより、これらの型がPowerShellセッション内で認識され、利用可能になります。

型をロードする方法は主に以下の3つです。

インラインでのC#または他の.NET言語コードのコンパイル: スクリプト内に直接記述したC#（デフォルト）やVisual Basicなどのコードを、実行時にコンパイルしてその型をロードします。
既存の.NETアセンブリ（DLLファイル）のロード: ファイルパスを指定して、コンパイル済みのDLLファイルをロードし、その中に含まれる型を利用可能にします。
.NET Framework / .NET Core の標準アセンブリのロード: アセンブリ名（例: System.Windows.Forms）を指定して、GAC (Global Assembly Cache) やフレームワークディレクトリにインストールされている標準アセンブリをロードします。

Add-Typeの目的は、PowerShellと.NETコードの間にある壁を取り払い、両者の強みを組み合わせて利用できるようにすることです。

なぜ Add-Type を使うのか？

Add-Typeを使用する理由はいくつかあります。

パフォーマンスの向上: 特定の処理（特にループ処理や複雑な計算など）において、PowerShellスクリプトよりもコンパイルされた.NETコードの方がはるかに高速に実行される場合があります。パフォーマンスが重要な部分をC#で記述し、Add-Typeでロードして利用することで、スクリプト全体の実行時間を短縮できます。
.NETの低レベル機能へのアクセス: PowerShellコマンドレットや.NETの公開されたラッパーでは利用できない、特定の低レベルなAPIや機能（例: Windows APIのP/Invoke、特定のCOMオブジェクトへのアクセスなど）に直接アクセスする必要がある場合。
既存の.NETライブラリ（DLL）の再利用: 既に開発されている.NETライブラリや、NuGetなどで提供されているライブラリを利用したい場合。これらのDLLをAdd-Typeでロードすることで、PowerShellスクリプト内からその機能を利用できます。
複雑なデータ構造の利用: 標準のPowerShellオブジェクトでは扱いにくい複雑なデータ構造（例: 特定のグラフ構造、高度なコレクション型など）を.NETの型として定義し、スクリプト内で利用する場合。
カスタム型の作成: PowerShellスクリプト内で使用する独自のオブジェクト型を定義したい場合。特に、複雑なメソッドやプロパティを持つオブジェクトが必要な場合に有効です。
UI要素の利用: Windows FormsやWPFなどのGUI要素をPowerShellスクリプトから利用したい場合。これらのライブラリは通常、アセンブリとして提供されており、Add-Typeでロードする必要があります（例: System.Windows.Forms）。

このように、Add-TypeはPowerShellの機能を大幅に拡張し、よりパワフルで柔軟なスクリプト開発を可能にします。

Add-Type の仕組み (舞台裏)

Add-Typeがどのように機能するかを理解することは、適切に使用し、問題を解決するために役立ちます。

C#コードの場合:
- Add-Type -TypeDefinition パラメータで指定されたC#コードは、PowerShellの背後で実行されている.NETランタイムによって、その場でコンパイルされます。
- このコンパイルは、PowerShellのセッションが動作しているアプリケーションドメイン（AppDomain）内でインメモリで行われます。DLLファイルとしてディスクに保存されるわけではありません（ただし、一時ファイルが使用されることはあります）。
- コンパイルが成功すると、生成されたアセンブリ（Assemblyオブジェクト）が現在のAppDomainにロードされ、そのアセンブリに含まれる型がPowerShellセッション内で利用可能になります。
- コンパイル中にエラーが発生した場合、Add-Typeはエラーを出力し、型のロードは行われません。
DLLファイルの場合 (-Path):
- 指定されたパスにあるDLLファイルは、.NETランタイムによって現在のAppDomainにロードされます。
- DLLに含まれるすべての公開された型がPowerShellセッション内で利用可能になります。
- DLLが依存する他のアセンブリがある場合、それらのアセンブリもロードされる必要があります。Add-Typeは、デフォルトでDLLと同じディレクトリや、GACなどを検索しますが、明示的に-ReferencedAssembliesで依存関係を指定することも重要です。
標準アセンブリの場合 (-AssemblyName):
- 指定されたアセンブリ名（例: System.Data, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 または単に System.Data）を持つアセンブリが、GACやフレームワークのインストールディレクトリなど、既知の場所に検索されます。
- 見つかったアセンブリが現在のAppDomainにロードされ、その中の型が利用可能になります。

重要な点として、Add-Typeによってロードされた型は、そのPowerShellセッションが終了するまで利用可能です。同じセッション内で同じアセンブリや型を複数回ロードしようとしても、通常は最初の一回だけが実際にロードされ、それ以降は既にロード済みとして扱われます（ただし、バージョンなどが異なる場合は例外）。

また、Add-Typeはデフォルトではグローバルスコープで型をロードします。つまり、スクリプト内や関数内でAdd-Typeを実行しても、その型はそのセッション全体のどこからでもアクセス可能になります。

Add-Type コマンドレットの主要パラメータ

Add-Typeコマンドレットには多くのパラメータがありますが、ここでは特に重要なものを解説します。

powershell Add-Type [-TypeDefinition] <String> [-Language <Language>] [-ReferencedAssemblies <String[]>] [-Namespace <String>] [-Name <String>] [-MemberDefinition <String[]>] [-IgnoreWarnings] [-CompilerParameters <CompilerParameters>] [-UsingNamespace <String[]>] [-PassThru] [<CommonParameters>]

powershell Add-Type [-Path] <String[]> [-ReferencedAssemblies <String[]>] [-IgnoreWarnings] [-CompilerParameters <CompilerParameters>] [-PassThru] [<CommonParameters>]

powershell Add-Type [-AssemblyName] <String[]> [-IgnoreWarnings] [-PassThru] [<CommonParameters>]

これらのパラメータセットからわかるように、Add-Typeは主に-TypeDefinition、-Path、-AssemblyNameの3つのパラメータセットで動作します。

`-TypeDefinition <String>`

目的: その場でコンパイルするC#などのコードを指定します。コード全体を文字列として渡します。
説明: このパラメータは、独自の型を動的に作成したい場合に使用します。通常、C#コードを複数行ヒアストリング（@"..."@）で囲んで渡します。
例:
powershell Add-Type -TypeDefinition @" public class MyClass { public string Greeting = "Hello from MyClass!"; public string SayHello(string name) { return $"Hello, {name}!"; } } "@

`-Path <String[]>`

目的: ロードする既存の.NETアセンブリ（DLLファイル）のパスを指定します。複数のパスを指定することも可能です。
説明: 既にコンパイルされている.NETライブラリを利用したい場合に使用します。指定されたパスからDLLを読み込み、その中の型を利用可能にします。
例:
“`powershell
# 特定のDLLファイルをロード
Add-Type -Path “C:\Libraries\MyCustomLibrary.dll”

複数のDLLファイルをロード

Add-Type -Path “C:\Libraries\Util.dll”, “C:\Libraries\Data.dll”
“`

`-AssemblyName <String[]>`

目的: ロードする標準の.NET Framework / .NET Coreアセンブリの名前を指定します。複数の名前を指定することも可能です。
説明: System.Windows.FormsやSystem.Dataなど、GACやフレームワークディレクトリにインストールされているアセンブリをロードしたい場合に使用します。アセンブリ名は、完全修飾名（Full Name）または単純名（Simple Name）で指定できます。単純名の場合、ランタイムが適切なバージョンや公開キーを検索します。
例:
“`powershell
# Windows Formsアセンブリをロード (MessageBoxなどを使用可能に)
Add-Type -AssemblyName System.Windows.Forms

System.Dataアセンブリをロード (ADO.NET関連の型を使用可能に)

Add-Type -AssemblyName System.Data
“`

`-Language <Language>`

目的: -TypeDefinitionで指定したコードの言語を指定します。
説明: デフォルトはCSharpです。他にVB (Visual Basic)などが指定可能です。
例:
powershell Add-Type -TypeDefinition @" Public Module MyMath Public Function Add(a As Integer, b As Integer) As Integer Return a + b End Function End Module "@ -Language VB

`-ReferencedAssemblies <String[]>`

目的: -TypeDefinitionでコンパイルするコードや、-PathでロードするDLLが依存する他のアセンブリを指定します。
説明: 独自のC#コード内で標準ライブラリ以外の型（例: System.Net.Http.HttpClientなど）を使用する場合や、ロードするDLLが他のカスタムDLLに依存している場合に使用します。アセンブリ名（シンプル名または完全修飾名）またはDLLへのパスを指定します。指定がない場合、Add-Typeは既知のアセンブリ（System.*など）や、-Pathで指定したDLLと同じディレクトリなどを自動的に検索しますが、依存関係を明示的に指定する方が安全です。
例:
powershell # C#コードでSystem.Net.Httpを利用する場合 Add-Type -TypeDefinition @" using System.Net.Http; public static class HttpHelper { public static async Task<string> GetContentAsync(string url) { using var client = new HttpClient(); return await client.GetStringAsync(url); } } "@ -ReferencedAssemblies System.Net.Http, System.Threading.Tasks # System.Threading.Tasksも必要になることがある

`-Namespace <String>`, `-Name <String>`, `-MemberDefinition <String[]>`

目的: -TypeDefinitionパラメータの代替または補助として、型を定義するためのより構造化された方法を提供します。
説明:
- -Namespace: 定義する型が属する名前空間。
- -Name: 定義する型の名前（クラス名など）。
- -MemberDefinition: 型のメンバー（フィールド、メソッド、プロパティなど）の定義を文字列配列として指定します。
- これらのパラメータを使用すると、シンプルな型定義をコードブロックとしてではなく、個別のパラメータで指定できます。ただし、複雑な型定義には-TypeDefinitionを使う方が一般的です。
例:
powershell # MyNamespace.MySimpleClass という型を定義 Add-Type -Namespace MyNamespace -Name MySimpleClass -MemberDefinition @' public string Message { get; set; } = "Default Message"; public void PrintMessage() { System.Console.WriteLine(Message); } '@

`-IgnoreWarnings`

目的: コンパイル時の警告を無視します。
説明: C#コードのコンパイル時に警告が発生しても、エラーとして扱わず、コンパイルを続行します。ただし、警告は潜在的な問題を示しているため、通常は無視せずに対処すべきです。

`-CompilerParameters <CompilerParameters>`

目的: コンパイラに渡す詳細なパラメータを指定します。
説明: .NET FrameworkのSystem.CodeDom.Compiler.CompilerParametersオブジェクトを渡します。これにより、コンパイルのオプション（例: 生成するアセンブリの種類、インクルードするライブラリパス、定義済みのシンボルなど）を細かく制御できます。非常に高度な用途向けです。

`-UsingNamespace <String[]>`

目的: -TypeDefinition内のコードの先頭に自動的に追加されるusingディレクティブを指定します。
説明: C#コード内で頻繁に使用する名前空間をここで指定しておくと、コード本体で毎回usingディレクティブを記述する必要がなくなります。コードが少し簡潔になります。
例:
powershell Add-Type -TypeDefinition @" public static class DateTimeHelper { public static DateTime GetNow() { return DateTime.Now; // System名前空間はusing不要 } } "@ -UsingNamespace System # これでSystem名前空間が自動的にusingされる

`-PassThru`

目的: ロードされたSystem.TypeオブジェクトまたはSystem.Reflection.Assemblyオブジェクトを出力します。
説明: デフォルトでは、Add-Typeは何も出力しません。-PassThruを指定すると、ロードされた型定義の場合はそのSystem.Typeオブジェクト、アセンブリの場合はSystem.Reflection.Assemblyオブジェクトがパイプラインに出力されます。これは、ロードされた型やアセンブリに関する情報を後続のコマンドレットで処理したい場合に便利です。
例:
“`powershell
# ロードしたSystem.Windows.Formsアセンブリの情報を取得
Add-Type -AssemblyName System.Windows.Forms -PassThru | Select-Object FullName, Location

ロードしたカスタム型のTypeオブジェクトを取得し、静的メソッドを呼び出す

$myType = Add-Type -TypeDefinition “public static class MyUtil { public static string Greet() { return \”Hello!\”; } }” -PassThru

“`

実践例

ここからは、具体的なシナリオに基づいたAdd-Typeの使用例を見ていきましょう。

例1: インラインC#コードでシンプルな型を作成

最も基本的な使い方です。クラスを定義し、その静的メソッドを呼び出してみます。

“`powershell

C#コードをヒアストリングで定義

$csharpCode = @”
public static class MyUtils {
// 静的メソッド
public static string GetCurrentTime() {
return System.DateTime.Now.ToString(“yyyy/MM/dd HH:mm:ss”);
}

// 静的プロパティ
public static string AppName { get; } = "PowerShell Add-Type Example";

}
“@

Add-Typeで型をロード

Add-Type -TypeDefinition $csharpCode

ロードされた型（MyUtils）の静的メンバーにアクセス

静的メソッドの呼び出し

静的プロパティの取得

“`

解説:
1. ヒアストリング$csharpCodeの中に、MyUtilsという静的クラスを定義しています。このクラスには、現在の時刻を返すGetCurrentTimeメソッドと、アプリケーション名を持つAppNameプロパティがあります。staticキーワードが付いているため、クラスのインスタンスを作成せずに直接クラス名でアクセスできます。
2. Add-Type -TypeDefinition $csharpCodeで、このC#コードをコンパイルし、MyUtils型を現在のPowerShellセッションにロードします。
3. ロード後、[MyUtils]::GetCurrentTime()のように、静的メンバーアクセス演算子::を使ってメソッドやプロパティにアクセスできます。

例2: インスタンス化可能なクラスの作成と利用

オブジェクトのインスタンスを作成して、そのインスタンスのメンバー（プロパティやメソッド）を操作する例です。

“`powershell

インスタンス化可能なC#クラスを定義

$csharpCode = @”
public class Person {
// プロパティ
public string FirstName { get; set; }
public string LastName { get; set; }

// コンストラクタ
public Person(string firstName, string lastName) {
    FirstName = firstName;
    LastName = lastName;
}

// メソッド
public string GetFullName() {
    return $"{FirstName} {LastName}";
}

// プロパティのオーバーロード
public override string ToString() {
    return $"[Person: {GetFullName()}]";
}

}
“@

Add-Typeで型をロード

Add-Type -TypeDefinition $csharpCode

ロードされた型（Person）のインスタンスを作成

PowerShellで.NETオブジェクトを作成するには New-Object または [型名]::new() を使う

$person = New-Object Person -ArgumentList “Taro”, “Yamada”

または $person = [Person]::new(“Taro”, “Yamada”) # PowerShell 5.0 以降

インスタンスのプロパティにアクセス

Write-Host “First Name: $($person.FirstName)”
Write-Host “Last Name: $($person.LastName)”

インスタンスのメソッドを呼び出し

Write-Host “Full Name: $($person.GetFullName())”

ToString() メソッドはオブジェクトの文字列表現を取得する際に自動的に呼ばれることがある

Write-Host “Person object representation: $($person)”
“`

解説:
1. Personというクラスを定義しています。このクラスにはFirstNameとLastNameというプロパティ、それらを初期化するコンストラクタ、フルネームを返すGetFullNameメソッド、そしてToStringメソッドのオーバーライドが含まれています。staticキーワードがないため、このクラスはインスタンス化して使用します。
2. Add-TypeでPerson型をロードします。
3. New-Object Person -ArgumentList "Taro", "Yamada" または [Person]::new("Taro", "Yamada")を使って、Personクラスの新しいインスタンスを作成し、コンストラクタに引数を渡しています。作成されたインスタンスは$person変数に格納されます。
4. $person.FirstNameや$person.GetFullName()のように、ドット演算子を使ってインスタンスのプロパティにアクセスしたり、メソッドを呼び出したりしています。PowerShellオブジェクトを操作するのと同じ感覚で利用できます。

例3: 既存のDLLファイルをロードして利用する

特定の機能を提供するカスタムDLL（例えばMyCustomLibrary.dll）があるとして、それをPowerShellから利用する例です。

まず、簡単なC#のクラスライブラリプロジェクトを作成し、DLLをビルドしておくと、以下の例を試すことができます。

“`csharp
// MyCustomLibrary.cs (クラスライブラリプロジェクトの一部としてコンパイル)
namespace MyCustomLibrary
{
public static class Calculator
{
public static int Add(int a, int b)
{
return a + b;
}

    public static int Subtract(int a, int b)
    {
        return a - b;
    }
}

public class StringHelper
{
    public string Concat(string s1, string s2)
    {
        return s1 + s2;
    }
}

}
“`

上記のC#コードをコンパイルして、例えばC:\Libraries\MyCustomLibrary.dllというパスにDLLが生成されたとします。

“`powershell

ロードするDLLファイルのパス

$dllPath = “C:\Libraries\MyCustomLibrary.dll”

DLLファイルをロード

Add-Type -Path $dllPath

DLL内の静的クラスのメンバーにアクセス

DLL内のインスタンス化可能なクラスのインスタンスを作成し、メンバーを呼び出す

$stringHelper = New-Object MyCustomLibrary.StringHelper
$stringHelper.Concat(“Hello, “, “World!”)
“`

解説:
1. $dllPath変数に、ロードしたいDLLファイルのフルパスを指定します。
2. Add-Type -Path $dllPathで、指定されたDLLファイルを現在のPowerShellセッションにロードします。DLLがロードされると、その中に定義されているMyCustomLibrary.CalculatorやMyCustomLibrary.StringHelperといった型が利用可能になります。
3. ロードされた型を、インラインC#の例と同じように、静的メンバーアクセス(::)やオブジェクトのインスタンス作成(New-Object)を通じて利用します。注意点として、DLL内の型を参照する場合は、名前空間を含めた完全修飾名（例: MyCustomLibrary.Calculator）で指定することが一般的です。

例4: 標準の.NET Framework / .NET Coreアセンブリをロードする (System.Windows.Formsの例)

Windows Formsアセンブリをロードして、GUIのメッセージボックスを表示する例です。これは特にWindows環境でよく利用されるアセンブリです。

“`powershell

System.Windows.Formsアセンブリをロード

必要に応じてSystem.Drawingもロードすることが多い

Add-Type -AssemblyName System.Windows.Forms
Add-Type -AssemblyName System.Drawing # メッセージボックスのアイコンなどに使用される

System.Windows.Forms.MessageBox クラスのShow静的メソッドを呼び出し

“`

解説:
1. Add-Type -AssemblyName System.Windows.FormsとAdd-Type -AssemblyName System.Drawingで、必要な標準アセンブリをロードします。これらのアセンブリは、Windows OSにインストールされている.NET Frameworkまたは.NET Core/.NET 5以降の環境に含まれています。
2. アセンブリがロードされると、その中の型（例: System.Windows.Forms.MessageBox、System.Windows.Forms.MessageBoxButtons、System.Windows.Forms.MessageBoxIconなど）が利用可能になります。
3. [System.Windows.Forms.MessageBox]::Show(...)という形式で、MessageBoxクラスの静的メソッドShowを呼び出しています。第3引数と第4引数には、それぞれMessageBoxButtonsとMessageBoxIconという列挙型（Enum）の静的メンバーを指定しています。これらの列挙型もAdd-TypeでロードされたSystem.Windows.Formsアセンブリ内に定義されています。

例5: 依存関係のあるDLLをロードする

ロードしたいDLLが、別のDLLに依存している場合の例です。例えば、MyApp.dllがMyUtil.dllに依存しているとします。

まず、依存される側のDLL (MyUtil.dll) を作成します。

csharp // MyUtil.cs namespace MyUtilLib { public static class StringProcessor { public static string Reverse(string input) { char[] charArray = input.ToCharArray(); Array.Reverse(charArray); return new string(charArray); } } }

次に、このMyUtil.dllを参照して、依存する側のDLL (MyApp.dll) を作成します。

“`csharp
// MyApp.cs (MyUtil.dllを参照設定に追加)
using MyUtilLib; // MyUtilLib名前空間を使用

namespace MyApp
{
public static class AppLogic
{
public static string ProcessString(string input)
{
// MyUtilLib.StringProcessorクラスのReverseメソッドを使用
return StringProcessor.Reverse(input.ToUpper());
}
}
}
“`

これらのDLLが、例えばC:\Appという同じディレクトリに配置されているとします。

“`powershell

ロードする主となるDLLのパス

$appDllPath = “C:\App\MyApp.dll”

依存するDLLのパス (同じディレクトリにある場合はAdd-Typeが自動的に見つける可能性があるが、明示するのが安全)

$utilDllPath = “C:\App\MyUtil.dll”

MyApp.dllをロードし、MyUtil.dllを依存関係として指定

Add-Type -Path $appDllPath -ReferencedAssemblies $utilDllPath

MyApp.dll内の型を利用

“`

解説:
1. $appDllPathと$utilDllPathにそれぞれのDLLのパスを指定します。
2. Add-Type -Path $appDllPath -ReferencedAssemblies $utilDllPathを実行します。-Pathで主要なMyApp.dllを指定し、-ReferencedAssembliesで依存するMyUtil.dllを指定します。Add-Typeはまず依存関係のアセンブリをロードしようとし、その後、主となるアセンブリをロードします。
3. ロードが成功すれば、MyApp.dll内のMyApp.AppLogic型が利用可能になり、その静的メソッドProcessStringを呼び出すことができます。

もし依存するDLLを-ReferencedAssembliesで指定しなかった場合でも、PowerShellのランタイムは通常、ロードしようとしているDLLと同じディレクトリや、既にロードされているアセンブリの中から依存関係を自動的に解決しようとします。しかし、複数の場所にあるDLLや、複雑な依存関係の場合は、-ReferencedAssembliesで明示的に指定することが推奨されます。また、PowerShell 7以降の.NET Core環境では、アセンブリのロードに関する挙動が.NET Frameworkから変更されている部分があるため、-ReferencedAssembliesの使用がより重要になる場合があります。

例6: Add-Type をスクリプトや関数内で使用する場合の考慮事項（スコープ）

Add-Typeでロードされた型は、デフォルトではグローバルスコープにロードされます。これは、スクリプトファイル内でAdd-Typeを実行しても、そのスクリプトが終了した後もそのセッション内で型が利用可能であるということです。また、関数内で実行した場合も同様にグローバルにロードされます。

“`powershell

スクリプトファイル MyScript.ps1 内での使用例

スクリプト内で型を定義・ロード

Add-Type -TypeDefinition @”
public static class ScriptHelper {
public static string GetMessage() {
return “Message from script!”;
}
}
“@

定義した型をスクリプト内で利用

Write-Host “[Script] Message: “([ScriptHelper]::GetMessage())

スクリプト終了後も、このPowerShellセッション内ではScriptHelper型が利用可能になっている

“`

このスクリプトを実行した後、同じPowerShellセッションで以下を実行してみてください。

“`powershell

スクリプト実行後

[ScriptHelper]::GetMessage() # スクリプト内で定義した型がまだ利用できる
“`

これは、型定義が現在のAppDomainにロードされるためであり、AppDomainは通常PowerShellセッション全体で共有されるからです。

ほとんどの場合、このグローバルスコープは意図した挙動ですが、以下のような点に注意が必要です。

名前の衝突: 異なるスクリプトやモジュールが、同じ名前（名前空間とクラス名）の型を定義しようとすると、エラーになるか、最初ロードされた型が使われることになります。衝突を避けるために、ユニークな名前空間を使用することが推奨されます。
再ロード: 同じセッション内で、同じ名前（完全修飾名）を持つ型を異なる定義で再ロードすることは、通常できません。変更を加えたC#コードを再コンパイルしてロードしたい場合は、新しいPowerShellセッションを開始するか、セッションをリセットするなどの対応が必要になります。開発中のデバッグ時には、この点が少し扱いにくい場合があります。

関数内でローカルに型をロードしたいというニーズは稀ですが、もしそのような制御が必要な場合は、より低レベルなReflection API（例: [System.Reflection.Assembly]::Load()）を使ってバイト配列からインメモリでロードし、特定のAppDomainやAssemblyLoadContext（.NET Core以降）に関連付ける方法などが考えられますが、これはかなり高度なトピックになります。一般的なPowerShellスクリプトの文脈では、Add-Typeのグローバルなロード挙動を理解しておくことが重要です。

高度な使用法と考慮事項

Add-Type のエラーハンドリング

Add-Typeの実行中にエラーが発生する可能性があります。最も一般的なのは、-TypeDefinitionで指定したC#コードのコンパイルエラーや、-Path/-AssemblyNameで指定したアセンブリが見つからない、または依存関係が解決できないといったエラーです。

Add-Typeは、エラーが発生するとPowerShellの標準エラー出力ストリームに書き込み、スクリプトの実行を停止する可能性があります（$ErrorActionPreferenceの設定によります）。エラーを捕捉して適切に処理するには、try...catchブロックを使用します。

“`powershell
$badCode = @”
public static class BadCode {
// Syntax Error: Missing semicolon
public static void MyMethod() {
System.Console.WriteLine(“This will fail”)
}
}
“@

try {
# エラーが発生する可能性のあるAdd-Typeの呼び出し
Add-Type -TypeDefinition $badCode -ErrorAction Stop
Write-Host “Type loaded successfully.” # エラー発生時はここは実行されない
}
catch {
# エラーが発生した場合の処理
Write-Error “Failed to load type:”
$.Exception.Message # 例外メッセージを表示
$.ScriptStackTrace # エラー発生箇所のスタックトレースを表示
}

この後もスクリプトの実行を続けたい処理があれば記述

Write-Host “Script continues.”
“`

解説:
* tryブロック内に、エラーが発生する可能性のあるAdd-Typeコマンドを配置します。
* Add-Typeの-ErrorAction Stopを指定することで、エラーが発生した場合に例外がスローされるようにします（デフォルトのContinueやSilentlyContinueでは例外が発生しない場合があります）。
* catchブロックでは、発生したエラー（$_変数に格納される）を処理します。$_.Exception.Messageでエラーメッセージを取得し、$_.ScriptStackTraceで呼び出し元の情報などを確認できます。
* この例では、セミコロンがないC#コードをコンパイルしようとするため、コンパイルエラーが発生し、catchブロックが実行されます。

アセンブリロードエラーの場合、エラーメッセージから原因（ファイルが見つからない、依存DLLがないなど）を特定しやすいため、メッセージを詳しく確認することが重要です。

パフォーマンスに関する考慮事項

Add-Typeは非常に便利ですが、パフォーマンス面で考慮すべき点があります。

C#コードのコンパイル時間: -TypeDefinitionで指定したC#コードは、Add-Typeが実行されるたびに（そのセッションでまだロードされていない場合）コンパイルされます。このコンパイル処理には時間がかかります。大規模なC#コードの場合、コンパイル時間が無視できない場合があります。パフォーマンスが求められるスクリプトで、何度も同じ型を定義・ロードする必要がある場合は、一度だけロードするようにスクリプトの構造を工夫するか、事前にDLLとしてコンパイルしておく方が効率的です。
DLL/アセンブリのロード時間: DLLファイルや標準アセンブリをロードする際にも、ファイルI/Oやアセンブリの解析に時間がかかります。これも同様に、スクリプトの実行中に何度も同じアセンブリをロードしようとするべきではありません。Add-Typeは同じアセンブリを重複してロードしようとした場合に、既にロード済みであれば何もしないようになっていますが、チェックのオーバーヘッドは発生します。

結論として、Add-Typeはスクリプトの開始時など、一度だけ実行するのが最も効率的です。ループ内や頻繁に呼び出される関数内でAdd-Typeを繰り返し実行することは避けるべきです。

セキュリティに関する考慮事項

Add-Typeは、任意のC#コードをコンパイルして実行したり、任意のDLLファイルをロードしたりできる強力なコマンドレットです。この能力はセキュリティ上のリスクを伴います。

信頼できないソースからのコード/DLL: インターネットからダウンロードしたスクリプトやDLL、信頼できないソースから提供されたコードを含むスクリプトなどを安易に実行するべきではありません。悪意のあるコードが実行され、システムに損害を与えたり、機密情報を漏洩させたりする可能性があります。
Code Injection: スクリプトが外部からの入力（例: ユーザー入力、ファイルの内容、ネットワークデータ）を受け取り、それを-TypeDefinitionのC#コードの一部として使用する場合、適切な検証やサニタイズを行わないと、コードインジェクション攻撃につながる可能性があります。

Add-Typeを使用する場合は、そのコードやDLLが信頼できるソースからのものであることを常に確認し、セキュリティ上のリスクを理解しておく必要があります。

Add-Type の代替手段

すべてのシナリオでAdd-Typeが最適な選択肢とは限りません。以下にいくつかの代替手段と、それぞれが適している可能性のあるシナリオを挙げます。

既存の.NETアセンブリのロード ([Reflection.Assembly]::Load*):
- [System.Reflection.Assembly]::LoadFrom(): ファイルパスからアセンブリをロードします。Add-Type -Pathに似ていますが、より低レベルなコントロールが可能です。
- [System.Reflection.Assembly]::Load(): アセンブリの名前やバイト配列からロードします。GACにあるアセンブリを単純名でロードする場合などに使えます。
- [System.Reflection.Assembly]::LoadFile(): 指定したパスからアセンブリをロードします。依存関係の解決方法がLoadFromと異なる場合があります。
- これらのメソッドは、Add-Typeのようなエラーメッセージの整形や依存関係の自動解決機能は限定的ですが、より詳細なロード制御や、バイト配列からのロードなど、Add-Typeでは直接サポートされていないシナリオで有用です。
C# Cmdlet の作成: PowerShellのモジュールとして、C#で記述されたカスタムコマンドレットを作成する方法です。これは、再利用性の高い機能や、複雑なロジックを含むコマンドレットを開発する際に最適です。Add-Typeはセッション内に一時的に型をロードするのに対し、C# Cmdletは独立したバイナリモジュールとして配布・インストールされます。
P/Invoke (Platform Invoke): .NETから直接Windows APIなどのネイティブコードを呼び出すための機能です。これは、特にOSの低レベルな機能にアクセスする必要がある場合に使用されます。C#コード内で[DllImport]属性を使用してネイティブ関数を宣言し、そのC#コードをAdd-Typeでロードして利用する形式になることが多いです。つまり、P/Invoke自体は代替手段というより、Add-Typeと組み合わせて使われることが多い技術です。
COMオブジェクトの利用: New-Object -ComObjectや[Runtime.InteropServices.Marshal]::GetActiveObject()などを使用して、COMコンポーネントを利用できます。これは、レガシーなWindowsアプリケーション（Officeアプリケーションなど）やOS機能と連携する場合に有用です。
外部EXE/スクリプトの実行: 単に特定のタスクを実行するだけであれば、Start-Processや&演算子を使って外部の実行ファイルやスクリプトを起動するのが最もシンプルかもしれません。

どの方法を選択するかは、目的、必要な制御レベル、再利用性の要件、開発コストなどを考慮して決定する必要があります。一時的なタスクや簡単な機能拡張にはAdd-Typeが手軽で便利ですが、本格的なツールや再利用可能なライブラリを作成する場合は、DLLとして事前にコンパイルしたり、C# Cmdletとして開発したりする方が適しています。

.NET Framework と .NET Core/.NET 5+ での違い

Add-Typeコマンドレット自体はPowerShellのバージョンによって提供されているため、PowerShell Core (v6+) や PowerShell 7以降でも利用できます。しかし、その基盤となる.NETランタイムが.NET Frameworkか.NET Core/.NET 5+かによって、アセンブリの検索パスやロードの挙動に一部違いがあります。

アセンブリの検索パス: .NET FrameworkではGACが重要な役割を果たしましたが、.NET Core/.NET 5+ではGACの概念がなくなり、NuGetパッケージやアプリケーションの依存関係としてアセンブリが管理される方法が主流になりました。Add-Type -AssemblyNameで指定した場合の検索挙動や、依存関係の自動解決の挙動に違いが出る可能性があります。
AssemblyLoadContext: .NET Core/.NET 5+では、アセンブリの分離や動的なアンロードを可能にするAssemblyLoadContextという概念が導入されました。Add-Typeが内部的にどのAssemblyLoadContextを使用するかは、PowerShellの実装に依存しますが、これにより.NET Framework時代とは異なるロード挙動を示す場合があります。

ほとんどの場合、Add-Type -TypeDefinitionによるインラインC#のコンパイルや、-PathによるDLLのロードは、両方の環境で同様に機能します。しかし、特定のアセンブリのバージョン解決や、複雑な依存関係を持つDLLのロードなどで問題が発生した場合は、ランタイムの違いを考慮する必要が出てくる可能性があります。特に、.NET Framework用にビルドされたDLLをPowerShell Coreでロードしようとする場合やその逆の場合、互換性の問題が生じる可能性があります。可能な限り、PowerShellの実行環境と同じバージョンの.NETでビルドされたDLLを使用するのが望ましいです。

Add-Type 使用上のベストプラクティス

Add-Typeを効果的かつ安全に使用するために、以下のベストプラクティスを考慮してください。

ユニークな名前空間を使用する: -TypeDefinitionで型を定義する場合、他のスクリプトや既にロードされているアセンブリとの名前の衝突を避けるために、組織名やプロジェクト名を含むユニークな名前空間を使用してください。
コードをヒアストリングに含める: C#コードを-TypeDefinitionに渡す際は、複数行に対応できるヒアストリング（@"..."@または@'...'@）を使用するのが一般的です。これにより、可読性が向上し、特別な文字のエスケープも容易になります。
必要なアセンブリのみをロードする: 不要なアセンブリをロードすると、メモリ使用量が増加し、起動時間にも影響を与える可能性があります。必要な機能を含む最小限のアセンブリのみをロードするようにしてください。
依存関係を明示的に指定する: -PathでDLLをロードする場合や、C#コード内で標準ライブラリ以外の型を使用する場合は、-ReferencedAssembliesで依存するアセンブリを明示的に指定するのが安全です。これにより、アセンブリ解決の失敗を防ぎ、スクリプトの移植性も向上します。
エラーハンドリングを実装する: Add-Typeの呼び出しはtry...catchブロックで囲み、エラーが発生した場合に適切にログを記録したり、ユーザーに通知したりするなどの処理を実装してください。特に、-ErrorAction Stopを指定して例外を捕捉するようにします。
一度だけロードする: パフォーマンスの理由から、PowerShellセッション中に同じアセンブリや型定義を複数回Add-Typeでロードしようとしないでください。スクリプトの冒頭や、特定の機能が初めて必要になったときに一度だけロードするように構造化します。
信頼できるソースのコード/DLLのみを使用する: セキュリティリスクを理解し、信頼できるソースから提供されたコードやDLLのみをAdd-Typeで利用してください。
DLLとして事前にコンパイルすることを検討する: 複雑な機能や、複数のスクリプトで再利用される可能性のあるコードは、DLLとして事前にコンパイルし、-Pathでロードすることを検討してください。これにより、スクリプトの可読性が向上し、コンパイル時のエラーを事前に発見しやすくなります。
PowerShellのオブジェクトと連携させる: ロードした.NETの型から作成したオブジェクトは、PowerShellのパイプラインで他のコマンドレット（Select-Object, Where-Object, Format-Tableなど）と組み合わせて使用できます。.NETの強力な機能をPowerShellの使い慣れた構文で操作できるのが、Add-Typeの大きな利点です。

トラブルシューティング

Add-Typeを使用している際に遭遇する可能性のある一般的な問題と、その解決策をいくつか紹介します。

型の定義が見つからない (Type [TypeName] not found.):
- 原因: Add-Typeが正常に実行されなかった（エラーが発生した）か、指定した型名がロードされたアセンブリ内に存在しない。
- 解決策:
  - Add-Typeの実行結果を確認します。エラーメッセージが出ていないか確認し、もし出ていればそのメッセージに従ってコードやパスを修正します。try...catchで囲んでエラーを捕捉することも有効です。
  - 型名が正確か確認します。大文字・小文字、名前空間を含めた完全修飾名が正しいか確認します。
  - -PassThruパラメータを付けてAdd-Typeを実行し、ロードされたアセンブリや型のリストを確認します（アセンブリの場合は$assembly.GetTypes()などで）。
  - -TypeDefinitionの場合は、C#コードにシンタックスエラーがないか、定義したクラスやモジュールの名前が正しいか確認します。
  - -Pathの場合は、指定したDLLファイルがその場所に存在し、PowerShellプロセスがそのファイルにアクセスできる権限を持っているか確認します。DLL内に目的の型が含まれているか、.NETリフレクターツールなどを使用して確認することもできます。
  - -AssemblyNameの場合は、アセンブリ名が正しいか確認します。完全修飾名で試してみるか、PowerShellのバージョンに対応した標準アセンブリであるか確認します。
コンパイルエラー (Add-Type : (n, m) : error CSxxxx: ...):
- 原因: -TypeDefinitionで指定したC#コードに文法エラーや参照エラーがある。
- 解決策:
  - エラーメッセージの行番号と列番号 ((n, m)) を確認し、C#コードのその箇所を修正します。
  - エラーコード (CSxxxx) を検索して、エラーの詳細を確認します。
  - C#コード内で使用している型（クラス、メソッドなど）が、参照可能なアセンブリに含まれているか確認します。標準ライブラリ以外の型を使用している場合は、-ReferencedAssembliesパラメータで必要なアセンブリ（パスまたはアセンブリ名）を指定しているか確認します。
  - usingディレクティブが適切に記述されているか確認します（または-UsingNamespaceパラメータを使用します）。
依存するアセンブリが見つからない (Could not load file or assembly 'DependencyName,...' or one of its dependencies.):
- 原因: ロードしようとしているアセンブリ（-Pathまたは-AssemblyName）が依存する別のアセンブリが、PowerShellのランタイム環境で見つけられない。
- 解決策:
  - 依存するアセンブリが、ロードしようとしているDLLと同じディレクトリにあるか確認します。
  - 依存するアセンブリが標準アセンブリの場合、Add-Type -AssemblyNameで明示的にロードしてみます。
  - 依存するアセンブリがカスタムDLLの場合、Add-Typeの-ReferencedAssembliesパラメータでそのDLLへのパスまたはアセンブリ名を指定します。
  - 依存するアセンブリがGACに登録されているか、またはフレームワークディレクトリに存在するか確認します（.NET Frameworkの場合）。
  - .NET Core/.NET 5+環境の場合、依存関係がNuGetパッケージによって適切に管理されているか、またはアプリケーションの出力ディレクトリに含まれているか確認します。
型が既に存在するというエラー (Add-Type : Cannot add type. The type name 'TypeName' already exists.):
- 原因: 同じ名前空間と名前を持つ型が、現在のPowerShellセッションに既にロードされている。
- 解決策:
  - 同じセッション内でAdd-Typeを重複して呼び出していないか確認します。通常、一度ロードすれば十分です。
  - もし異なる定義の同じ名前の型をロードしたい場合は、PowerShellセッションを再起動するか、名前を変更する必要があります。
  - 別のスクリプトやモジュールが同じ名前の型をロードしている可能性があります。衝突を避けるために、独自の型にはユニークな名前空間を使用するベストプラクティスに従います。

これらのトラブルシューティングのステップは、Add-Type関連の問題を診断し、解決するのに役立ちます。

まとめ

Add-Typeコマンドレットは、PowerShellスクリプトから.NET Frameworkまたは.NET Coreの強力な機能にアクセスするための不可欠なツールです。インラインでのC#コードのコンパイル、既存のDLLのロード、標準アセンブリの利用といった方法を通じて、PowerShellの能力を大幅に拡張できます。

本記事では、Add-Typeの基本的な目的と仕組みから、主要なパラメータの詳細な解説、そして多くの実践的な使用例を通じて、その使い方を具体的に示しました。また、スコープ、エラーハンドリング、パフォーマンス、セキュリティといった高度な考慮事項や、代替手段、トラブルシューティングについても触れました。

Add-Typeを習得することで、より効率的で、より低レベルなシステム機能にアクセスし、既存の.NETライブラリを活用するなど、PowerShellスクリプトで実現できることの幅が大きく広がります。ただし、その強力さゆえに、セキュリティや安定性に関する考慮も重要です。常に信頼できるソースのコードやDLLを使用し、エラーハンドリングを適切に行うように心がけましょう。

これで、あなたはAdd-Typeコマンドレットを使って、PowerShellと.NETの世界をより深く連携させる準備が整いました。ぜひ、あなたのPowerShellスクリプト開発にAdd-Typeを活用してみてください。

PowerShell Add-Type コマンドレット徹底解説：C#連携からDLL利用まで

はじめに

Add-Type とは何か？

なぜ Add-Type を使うのか？

Add-Type の仕組み (舞台裏)

Add-Type コマンドレットの主要パラメータ

-TypeDefinition <String>

-Path <String[]>

複数のDLLファイルをロード

-AssemblyName <String[]>

System.Dataアセンブリをロード (ADO.NET関連の型を使用可能に)

-Language <Language>

-ReferencedAssemblies <String[]>

-Namespace <String>, -Name <String>, -MemberDefinition <String[]>

-IgnoreWarnings

-CompilerParameters <CompilerParameters>

-UsingNamespace <String[]>

-PassThru

ロードしたカスタム型のTypeオブジェクトを取得し、静的メソッドを呼び出す

実践例

例1: インラインC#コードでシンプルな型を作成

C#コードをヒアストリングで定義

Add-Typeで型をロード

ロードされた型（MyUtils）の静的メンバーにアクセス

静的メソッドの呼び出し

静的プロパティの取得

例2: インスタンス化可能なクラスの作成と利用

インスタンス化可能なC#クラスを定義

Add-Typeで型をロード

ロードされた型（Person）のインスタンスを作成

PowerShellで.NETオブジェクトを作成するには New-Object または [型名]::new() を使う

または $person = [Person]::new(“Taro”, “Yamada”) # PowerShell 5.0 以降

インスタンスのプロパティにアクセス

インスタンスのメソッドを呼び出し

ToString() メソッドはオブジェクトの文字列表現を取得する際に自動的に呼ばれることがある

例3: 既存のDLLファイルをロードして利用する

ロードするDLLファイルのパス

DLLファイルをロード

DLL内の静的クラスのメンバーにアクセス

DLL内のインスタンス化可能なクラスのインスタンスを作成し、メンバーを呼び出す

例4: 標準の.NET Framework / .NET Coreアセンブリをロードする (System.Windows.Formsの例)

System.Windows.Formsアセンブリをロード

必要に応じてSystem.Drawingもロードすることが多い

System.Windows.Forms.MessageBox クラスのShow静的メソッドを呼び出し

例5: 依存関係のあるDLLをロードする

ロードする主となるDLLのパス

依存するDLLのパス (同じディレクトリにある場合はAdd-Typeが自動的に見つける可能性があるが、明示するのが安全)

MyApp.dllをロードし、MyUtil.dllを依存関係として指定

MyApp.dll内の型を利用

例6: Add-Type をスクリプトや関数内で使用する場合の考慮事項（スコープ）

スクリプトファイル MyScript.ps1 内での使用例

スクリプト内で型を定義・ロード

定義した型をスクリプト内で利用

スクリプト終了後も、このPowerShellセッション内ではScriptHelper型が利用可能になっている

スクリプト実行後

高度な使用法と考慮事項

Add-Type のエラーハンドリング

この後もスクリプトの実行を続けたい処理があれば記述

パフォーマンスに関する考慮事項

セキュリティに関する考慮事項

Add-Type の代替手段

.NET Framework と .NET Core/.NET 5+ での違い

Add-Type 使用上のベストプラクティス

トラブルシューティング

まとめ

コメントする 返信をキャンセル

`-TypeDefinition <String>`

`-Path <String[]>`

`-AssemblyName <String[]>`

`-Language <Language>`

`-ReferencedAssemblies <String[]>`

`-Namespace <String>`, `-Name <String>`, `-MemberDefinition <String[]>`

`-IgnoreWarnings`

`-CompilerParameters <CompilerParameters>`

`-UsingNamespace <String[]>`

`-PassThru`

コメントする返信をキャンセル