【C#】DLL配置場所のベストプラクティスと参照エラーを防ぐ設定手法

2025-04-30更新日: 2025-04-30

DLLファイルは実行ファイルと同じディレクトリかbin\Debugやbin\Releaseに置くのが基本です。

別フォルダに分けたい場合はApp.configのprobingでパスを指定するかSetDllDirectoryで検索パスを追加し、またはGACに登録して参照切れを防ぎます。

開発ではプロジェクト参照でCopy Localを有効にし、公開時は依存DLLを同梱すると安全です。

目次から探す

DLL配置の基本
実行ファイル同梱方式
サブフォルダー配置とパス拡張
- App.configのprobing要素設定
- SetDllDirectory APIによる動的設定
グローバルアセンブリキャッシュ (GAC) への登録
外部パッケージマネージャーの活用
Self-Contained Deploymentの選択肢
プラットフォーム依存DLLの扱い
バージョン衝突の回避テクニック
- BindingRedirectによる強制リダイレクト
- AssemblyResolveイベントでのカスタムロジック
サードパーティDLL更新時の運用
セキュリティ観点での留意点
クロスプラットフォームプロジェクトでの共有DLL
インストーラー利用による配置
テスト環境でのDLL運用
エラー例と解決フロー
依存関係の可視化ツール
まとめ

C#を使った求人

読み込み中…

DLL配置の基本

C#で開発を進める際、DLL(Dynamic Link Library)の配置はアプリケーションの動作に大きく影響します。

ここでは、DLLの基本的な概念や配置の仕組みについて詳しく解説します。

DLLとアセンブリの違い

C#や.NETの世界で「DLL」と呼ばれるファイルは、実は単なるファイル形式の名前以上の意味を持っています。

まずはDLLとアセンブリの違いを理解しましょう。

管理対象アセンブリとネイティブDLL

管理対象アセンブリ(Managed Assembly)

C#やVB.NETなどの.NET言語で作成されるDLLは、管理対象アセンブリと呼ばれます。

これらは中間言語(IL)でコンパイルされ、実行時にCLR(Common Language Runtime)がJITコンパイルして動作します。

管理対象アセンブリはメタデータを含み、型情報や依存関係が明確に管理されています。

ネイティブDLL(Unmanaged DLL)

一方、C++などのネイティブコードで作成されたDLLは、直接CPUの命令セットで動作します。

これらは.NETの管理対象ではなく、P/Invoke(Platform Invocation Services)を使って呼び出すことが多いです。

ネイティブDLLはメタデータを持たず、依存関係の解決はOSのローダーに任されています。

この違いは、DLLの配置場所や参照方法に影響します。

管理対象アセンブリは.NETのアセンブリ探索ルールに従い、ネイティブDLLはOSのDLL検索パスに従います。

CLRのアセンブリ探索順序

.NETアプリケーションが実行時にDLLを読み込む際、CLRは決まった順序でアセンブリを探します。

これを理解することで、DLLの配置場所を適切に決められます。

アプリケーションベースディレクトリ

最初に探されるのは、実行ファイル(EXE)が存在するディレクトリです。

ここにDLLがあれば、すぐに読み込まれます。

たとえば、MyApp.exeと同じフォルダにMyLibrary.dllを置くと、特別な設定なしで参照可能です。

既定の検索パス

アプリケーションベースディレクトリの次に、以下の場所が探索されます。

グローバルアセンブリキャッシュ(GAC)

共有アセンブリとして登録されたDLLはGACに格納され、どのアプリケーションからも参照可能です。

バージョン管理や共有が容易ですが、GAC登録には管理者権限が必要です。

サブフォルダー(probing設定がある場合)

App.configのprobing要素で指定されたサブフォルダーも探索対象になります。

たとえば、dllフォルダーを指定すると、MyApp.exeの隣にあるdllフォルダー内のDLLも読み込めます。

コードベース指定

アセンブリの参照にcodeBase属性を使うと、特定のパスから読み込むことも可能です。

ただし、セキュリティ制約があるため注意が必要です。

フレームワークによる差異

.NETのバージョンや種類によって、DLLの配置や探索方法に違いがあります。

ここでは代表的な2つの環境について説明します。

.NET Framework

従来のWindows向けフレームワークである.NET Frameworkでは、DLLの配置は主に以下の方法が使われます。

実行ファイルと同じフォルダーにDLLを置く
GACに登録して共有する
App.configのprobingでサブフォルダーを指定する

この環境では、App.configの設定が有効で、probingによるサブフォルダー探索が標準的に使われています。

また、ネイティブDLLはWindowsのDLL検索パスに従うため、PATH環境変数やSetDllDirectory関数でパスを追加することもあります。

.NET Core / .NET 5+

.NET Core以降のクロスプラットフォーム対応フレームワークでは、DLLの配置と探索に新しい仕組みが導入されています。

自己完結型デプロイ(Self-Contained Deployment)

アプリケーションと必要なランタイム、DLLをすべて一つのフォルダーにまとめて配布します。

これにより、依存関係の問題を減らせます。

フレームワーク依存デプロイ(Framework-Dependent Deployment)

ランタイムは別途インストールされている前提で、アプリケーションのDLLだけを配布します。

deps.jsonファイルによる依存管理

依存DLLのパスやバージョン情報はdeps.jsonに記録され、ランタイムがこれを参照してDLLをロードします。

GACは廃止

.NET Core以降ではGACがなくなり、共有アセンブリの管理方法が変わりました。

ネイティブDLLの配置

ネイティブDLLはプラットフォームごとに異なるフォルダーに配置し、ランタイムが適切にロードします。

これらの違いを理解しておくと、DLLの配置場所や参照方法を適切に選べます。

特にクロスプラットフォーム対応やコンテナ環境での運用を考える場合は、.NET Core以降の仕組みを意識することが重要です。

サンプルコード：実行ファイルと同じフォルダーにDLLを配置して参照する例

以下は、同じフォルダーにあるDLLを参照してメソッドを呼び出す簡単な例です。

MyLibrary.dllにGreeterクラスがあり、SayHelloメソッドを呼び出します。

// MyLibrary.dll内のコード(別プロジェクトで作成)
namespace MyLibrary
{
    public class Greeter
    {
        public string SayHello(string name)
        {
            return $"こんにちは、{name}さん！";
        }
    }
}

// 実行プロジェクトのProgram.cs
using System;
using MyLibrary;
class Program
{
    static void Main()
    {
        var greeter = new Greeter();
        string message = greeter.SayHello("太郎");
        Console.WriteLine(message);
    }
}

この場合、MyLibrary.dllはProgram.exeと同じフォルダー(通常はbin\Debugやbin\Release)に配置します。

ビルド時にVisual Studioの参照設定でCopy LocalがTrueになっていれば、自動的にコピーされます。

こんにちは、太郎さん！

このように、DLLと実行ファイルを同じ場所に置くのが最もシンプルで確実な配置方法です。

このセクションでは、DLLとアセンブリの基本的な違い、CLRの探索順序、そしてフレームワークごとの違いを解説しました。

これらの知識を踏まえて、次のステップで具体的な配置方法や設定について学んでいきましょう。

実行ファイル同梱方式

binフォルダーへの配置

Visual StudioでC#プロジェクトをビルドすると、生成された実行ファイル(EXE)やDLLは通常、binフォルダー内のDebugまたはReleaseサブフォルダーに出力されます。

このbinフォルダーは開発中の標準的な出力先であり、DLLを配置する最も基本的な場所です。

DebugとReleaseの違い

bin\Debugとbin\Releaseはビルド構成によって分かれています。

Debugはデバッグ用に最適化されておらず、デバッグ情報が含まれています。

一方、Releaseは最適化されており、デバッグ情報が削除されているため、実行速度が速くなります。

DLLの配置に関しては、両者のフォルダー構造は同じですが、ビルド構成を切り替えるとDLLの配置先も変わるため、実行時に参照されるDLLの場所が異なります。

たとえば、Debugビルドで動作確認したDLLがReleaseビルドでは見つからずエラーになることがあるため、両方のフォルダーにDLLを配置するか、ビルド構成に合わせてDLLをコピーする必要があります。

CopyLocalプロパティの役割

Visual Studioの参照設定にあるCopyLocalプロパティは、参照しているDLLをビルド出力ディレクトリにコピーするかどうかを制御します。

CopyLocalがTrueの場合、参照DLLはbin\Debugやbin\Releaseに自動的にコピーされます。

これにより、実行ファイルと同じフォルダーにDLLが存在し、実行時に正しく読み込まれます。

逆にCopyLocalがFalseの場合、DLLはコピーされず、実行時に別の場所から読み込まれることを期待します。

たとえば、GACに登録されている共有DLLや、特定のパスに配置されたDLLを参照する場合に使います。

CopyLocalの設定は、プロジェクトの依存関係や配布方法に応じて適切に設定することが重要です。

アプリケーションルート直下に置くケース

実行ファイルと同じフォルダーにDLLを配置する方法は、最もシンプルでトラブルが少ない配置方法です。

特に配布時に単一のフォルダーにすべての必要なファイルをまとめる場合に有効です。

単一EXEと複数DLLの配布

多くのC#アプリケーションは、メインの実行ファイル(EXE)と複数のDLLで構成されています。

これらを同じフォルダーにまとめて配布すると、アプリケーションは特別な設定なしにDLLを読み込めます。

たとえば、以下のようなフォルダー構成です。

ファイル名	説明
MyApp.exe	メインの実行ファイル
MyLibrary.dll	自作のライブラリDLL
ThirdParty.dll	サードパーティ製DLL
Newtonsoft.Json.dll	NuGetで導入したJSONライブラリDLL

このように、すべてのDLLをMyApp.exeと同じフォルダーに置くことで、実行時にDLLが見つからない問題を防げます。

サンプルコード：CopyLocalがTrueのDLL参照例

以下は、Visual StudioでCopyLocalがTrueに設定されたDLLを参照し、ビルド出力フォルダーに自動コピーされる例です。

// MyLibrary.dll内のコード(別プロジェクト)
namespace MyLibrary
{
    public class Calculator
    {
        public int Add(int a, int b)
        {
            return a + b;
        }
    }
}

// 実行プロジェクトのProgram.cs
using System;
using MyLibrary;
class Program
{
    static void Main()
    {
        var calc = new Calculator();
        int result = calc.Add(3, 5);
        Console.WriteLine($"3 + 5 = {result}");
    }
}

Visual StudioでMyLibrary.dllを参照追加し、CopyLocalがTrueのままビルドすると、bin\Debugやbin\ReleaseにMyLibrary.dllがコピーされます。

これにより、MyApp.exeと同じフォルダーにDLLが存在し、実行時に問題なく読み込まれます。

3 + 5 = 8

このように、binフォルダーへのDLL配置は開発中の標準的な方法であり、CopyLocalプロパティの設定によって自動化できます。

また、配布時には実行ファイルと同じフォルダーに複数のDLLをまとめて置くことで、依存関係の解決が容易になります。

サブフォルダー配置とパス拡張

DLLを実行ファイルと同じフォルダーに置く以外に、サブフォルダーに配置して管理したいケースがあります。

たとえば、複数のDLLを機能別に分けたり、外部ライブラリをまとめたりする場合です。

この場合、CLRのアセンブリ探索パスを拡張する方法や、WindowsのDLL検索パスを動的に変更する方法が有効です。

App.configのprobing要素設定

App.configファイルのprobing要素を使うと、実行ファイルのサブフォルダーをアセンブリ探索パスに追加できます。

これにより、指定したサブフォルダーにあるDLLを自動的に読み込めるようになります。

privatePath属性の書き方

probing要素のprivatePath属性には、DLLを配置したいサブフォルダー名を指定します。

複数のフォルダーを指定する場合は、セミコロン;で区切ります。

以下は、dllというサブフォルダーを指定する例です。

<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <probing privatePath="dll" />
    </assemblyBinding>
  </runtime>
</configuration>

この設定を行うと、MyApp.exeの隣にあるdllフォルダー内のDLLも探索対象になります。

複数のサブフォルダーを指定する場合は、以下のようにセミコロンで区切ります。

<probing privatePath="dll;plugins;libs" />

この例では、dll、plugins、libsの3つのサブフォルダーが探索対象になります。

複数フォルダー指定時の注意点

privatePathに指定できるのは実行ファイルの直下のサブフォルダーのみです。サブフォルダーのさらに下の階層は指定できません。たとえば、dll\subfolderのような深い階層は指定できません
フォルダー名は相対パスで指定し、絶対パスは使えません
probing設定は.NET Frameworkで有効ですが、.NET Coreや.NET 5以降ではサポートされていません
privatePathに指定したフォルダーが存在しない場合、エラーにはなりませんが、そのフォルダーは探索されません
複数フォルダーを指定する際は、スペースを入れずにセミコロンで区切ることが推奨されます。スペースが入ると正しく認識されない場合があります

SetDllDirectory APIによる動的設定

WindowsのネイティブDLLを読み込む際、DLLの検索パスはOSの仕様に従います。

SetDllDirectory関数を使うと、実行時にDLLの検索パスを追加・変更できます。

これにより、サブフォルダーに配置したネイティブDLLを動的に読み込めるようになります。

Win32 APIの宣言

C#からSetDllDirectoryを呼び出すには、DllImport属性を使ってWin32 APIを宣言します。

using System;
using System.Runtime.InteropServices;
class NativeMethods
{
    [DllImport("kernel32.dll", CharSet = CharSet.Auto, SetLastError = true)]
    public static extern bool SetDllDirectory(string lpPathName);
}

この宣言により、SetDllDirectory関数をC#コードから呼び出せます。

実行時にパスを追加するタイミング

SetDllDirectoryは、アプリケーションの起動直後、ネイティブDLLをロードする前に呼び出す必要があります。

たとえば、Mainメソッドの最初や、ネイティブDLLを使うクラスの初期化時に設定します。

以下は、実行ファイルの隣にあるnativeフォルダーをDLL検索パスに追加する例です。

using System;
using System.IO;
using System.Reflection;
class Program
{
    [DllImport("kernel32.dll", CharSet = CharSet.Auto, SetLastError = true)]
    static extern bool SetDllDirectory(string lpPathName);
    static void Main()
    {
        string exePath = Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location);
        string nativeDllPath = Path.Combine(exePath, "native");
        bool result = SetDllDirectory(nativeDllPath);
        if (!result)
        {
            Console.WriteLine("DLL検索パスの追加に失敗しました。");
        }
        else
        {
            Console.WriteLine($"DLL検索パスに '{nativeDllPath}' を追加しました。");
        }
        // ここでネイティブDLLを使う処理を呼び出す
    }
}

DLL検索パスに 'C:\Path\To\MyApp\native' を追加しました。

このように、SetDllDirectoryを使うと、ネイティブDLLをサブフォルダーに配置しても問題なく読み込めます。

ただし、SetDllDirectoryはプロセス単位で設定されるため、複数の場所を追加したい場合は注意が必要です。

これらの方法を活用すると、DLLをサブフォルダーに整理しつつ、実行時に正しく読み込むことが可能です。

App.configのprobingは管理対象アセンブリ向け、SetDllDirectoryはネイティブDLL向けの手法として使い分けるとよいでしょう。

グローバルアセンブリキャッシュ (GAC) への登録

GAC利用のメリットとデメリット

グローバルアセンブリキャッシュ(GAC)は、Windows環境の.NET Frameworkで共有アセンブリを管理するための仕組みです。

GACに登録されたアセンブリは、複数のアプリケーションから共通して利用できるため、DLLの重複を避けたり、バージョン管理を一元化したりすることが可能です。

メリット

共有と再利用の促進

複数のアプリケーションが同じアセンブリを利用する場合、GACに登録することでディスク上の重複を減らせます。

バージョン管理の強化

GACはアセンブリのバージョン、カルチャ、パブリックキー・トークンを管理しているため、異なるバージョンのアセンブリを共存させられます。

セキュリティの向上

GACに登録するには強力な名前(Strong Name)で署名されたアセンブリが必要なため、信頼性が高まります。

インストールの一元管理

インストーラーや管理ツールを使ってGACに登録・削除できるため、運用管理がしやすいです。

デメリット

管理者権限が必要

GACへの登録や削除は管理者権限が必要であり、開発環境や一部の運用環境では制限されることがあります。

複雑な依存関係のトラブル

複数のバージョンが混在すると、バインドポリシーの設定ミスでアプリケーションが意図しないバージョンを読み込むことがあります。

.NET Core以降では非推奨

.NET Coreや.NET 5以降ではGACが廃止されており、共有アセンブリの管理方法が変わっています。

配布の柔軟性が低下

GACに依存すると、アプリケーション単体での配布が難しくなり、環境構築が複雑になる場合があります。

gacutilコマンドの使用手順

gacutilは、GACにアセンブリを登録・削除するためのコマンドラインツールです。

Visual Studioの開発者コマンドプロンプトやWindows SDKに含まれています。

GACへの登録

強力な名前で署名されたアセンブリ(DLL)を用意します。署名されていないアセンブリはGACに登録できません。
管理者権限でコマンドプロンプトを開きます。
以下のコマンドを実行してアセンブリをGACに登録します。

gacutil /i Path\To\YourAssembly.dll

gacutil /i C:\Libraries\MyLibrary.dll

登録が成功すると、メッセージが表示されます。

GACからの削除

登録したアセンブリを削除する場合は、以下のコマンドを使います。

gacutil /u YourAssemblyName

gacutil /u MyLibrary

バージョン管理戦略

GACはアセンブリのバージョンをキーにして管理しているため、異なるバージョンのDLLを同時に登録できます。

これにより、複数のアプリケーションがそれぞれ異なるバージョンを利用可能です。

ただし、バージョン管理を適切に行わないと、以下のような問題が発生します。

バージョンの競合

アプリケーションが特定のバージョンを要求しているのに、GACに別のバージョンしか存在しない場合、実行時エラーが発生します。

バインドポリシーの誤設定

App.configやmachine.configでバージョンのリダイレクト設定(Binding Redirect)を誤ると、意図しないバージョンが読み込まれます。

バージョン管理のポイントは以下の通りです。

ポイント	内容
強力な名前の付与	アセンブリに一意のパブリックキーを付与し、バージョン管理を可能にします。
バージョン番号の更新	変更があった場合はバージョン番号を適切に上げます。
バインドリダイレクト設定	アプリケーション構成ファイルでバージョンの互換性を調整します。
テスト環境での検証	バージョン変更後は必ず動作確認を行います。

アプリケーション構成ファイルによるバインドポリシー

アプリケーションのApp.configやweb.configファイルで、GACに登録されたアセンブリのバージョンを制御できます。

これをバインドポリシー(Binding Policy)と呼びます。

以下は、特定の古いバージョンから新しいバージョンへリダイレクトする例です。

<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="MyLibrary"
                          publicKeyToken="32ab4ba45e0a69a1"
                          culture="neutral" />
        <bindingRedirect oldVersion="1.0.0.0-1.2.0.0"
                         newVersion="1.2.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

assemblyIdentityで対象のアセンブリ名、パブリックキー、カルチャを指定します
bindingRedirectで、oldVersionに指定した範囲のバージョンをすべてnewVersionにリダイレクトします

この設定により、アプリケーションはGACに登録された新しいバージョンのDLLを読み込み、古いバージョンとの互換性問題を回避できます。

バインドポリシーは、複数のアプリケーションで同じGACアセンブリを使う場合に特に重要です。

適切に設定しないと、バージョンの不整合による例外や動作不良が発生します。

サンプルコード：GAC登録済みアセンブリの呼び出し例

以下は、GACに登録された強力な名前付きアセンブリMyLibraryのクラスを呼び出す例です。

通常の参照追加と同様に名前空間を使ってアクセスします。

using System;
using MyLibrary;
class Program
{
    static void Main()
    {
        var calc = new Calculator();
        int result = calc.Add(10, 20);
        Console.WriteLine($"10 + 20 = {result}");
    }
}

GACに正しく登録されていれば、実行時にDLLが見つからないエラーは発生しません。

10 + 20 = 30

GACは.NET Framework時代の共有アセンブリ管理の中心的な仕組みですが、管理者権限の必要性や運用の複雑さから、最近では利用が減少しています。

新しいプロジェクトではNuGetや自己完結型デプロイなどの方法が推奨されることが多いです。

外部パッケージマネージャーの活用

NuGetでの依存解決

NuGetは.NETの標準的なパッケージマネージャーであり、外部ライブラリや自作ライブラリの依存関係を簡単に管理できます。

NuGetパッケージを利用すると、DLLの配置やバージョン管理が自動化され、手動でDLLをコピーする手間が大幅に減ります。

.nuspecとcontentFiles

NuGetパッケージの中核となるのが.nuspecファイルです。

これはパッケージのメタデータやファイル構成、依存関係を定義するXMLファイルです。

.nuspecファイルの役割

パッケージ名、バージョン、説明、依存パッケージ、含まれるファイルの一覧などを記述します。

これにより、NuGetクライアントはパッケージの内容を理解し、適切にインストールやアップデートを行います。

contentFilesフォルダー

.nuspec内でcontentFiles要素を使うと、パッケージに含めたソースコードや設定ファイル、DLLなどをプロジェクトにコピーできます。

特にDLLをcontentFilesに含めると、参照として自動的に追加され、ビルド出力に反映されます。

以下は、.nuspecの一部例です。

<package>
  <metadata>
    <id>MyLibrary</id>
    <version>1.0.0</version>
    <authors>ExampleAuthor</authors>
    <description>自作ライブラリの説明</description>
  </metadata>
  <files>
    <file src="lib\netstandard2.0\MyLibrary.dll" target="lib\netstandard2.0\" />
    <file src="contentFiles\any\netstandard2.0\config.json" target="contentFiles\any\netstandard2.0\" />
  </files>
</package>

この例では、libフォルダーにDLLを配置し、contentFilesに設定ファイルを含めています。

NuGetパッケージをインストールすると、lib内のDLLは自動的に参照に追加され、contentFilesのファイルはプロジェクトにコピーされます。

PrivateAssetsフラグでの制御

NuGetの依存関係管理では、パッケージの伝播を制御するためにPrivateAssetsフラグを使います。

これは、パッケージの依存関係がプロジェクトの参照にどのように影響するかを指定するものです。

PrivateAssets="all"

依存パッケージをプロジェクトの公開APIに含めず、他のプロジェクトに伝播させたくない場合に使います。

たとえば、ビルドツールやテスト用パッケージに設定します。

PrivateAssetsの指定例(PackageReference形式)

<ItemGroup>
  <PackageReference Include="SomePackage" Version="1.2.3" PrivateAssets="all" />
</ItemGroup>

この設定により、SomePackageはこのプロジェクト内でのみ使用され、依存関係として他のプロジェクトに伝わりません。

ExcludeAssetsとの違い

ExcludeAssetsはパッケージの特定のアセット(コンパイル、ランタイムなど)を除外するのに対し、PrivateAssetsは依存関係の伝播を制御します。

PrivateAssetsを適切に設定することで、依存関係の肥大化や不要なパッケージの伝播を防ぎ、ビルドや配布の効率化につながります。

自社ライブラリの社内フィード配布

自社開発のライブラリを社内で共有する場合、NuGetの社内フィード(プライベートリポジトリ)を活用すると便利です。

これにより、外部に公開せずに安全かつ効率的にライブラリを配布できます。

社内NuGetフィードの種類
- Azure Artifacts

Microsoftのクラウドサービスで、Azure DevOpsの一部として提供されるパッケージ管理サービスです。

アクセス制御やバージョン管理が充実しています。

NuGet.Server

自社サーバーに簡単に構築できるNuGetパッケージのホスティングサービスです。

ProGetやNexus Repository

より高度なパッケージ管理機能を持つ商用・OSSのリポジトリマネージャーも利用可能です。

運用のポイント
- 認証とアクセス制御

社内フィードは機密性が高いため、ユーザー認証やアクセス権限の設定が重要です。

バージョン管理とタグ付け

バージョンを明確に管理し、安定版や開発版を区別するタグ付けを行います。

CI/CDとの連携

ビルドパイプラインで自動的にパッケージを生成し、社内フィードに公開する仕組みを作ると効率的です。

Visual Studioでの利用方法

NuGetパッケージマネージャーの「パッケージソース」に社内フィードのURLを追加します。
通常のNuGetパッケージと同様に、社内パッケージを検索・インストールできます。

メリット
- 外部公開せずに安全に共有できます
- バージョン管理や依存関係解決が自動化されます
- 開発者の作業効率が向上します

サンプルコード：PackageReferenceでの依存関係制御例

以下は、PrivateAssetsを使って依存パッケージの伝播を防ぐ例です。

<ItemGroup>
  <PackageReference Include="Newtonsoft.Json" Version="13.0.1" PrivateAssets="all" />
</ItemGroup>

この設定により、Newtonsoft.Jsonはこのプロジェクト内でのみ使用され、これを参照する他のプロジェクトには依存関係が伝わりません。

NuGetを活用することで、DLLの配置や依存関係の管理が大幅に簡素化されます。

特に社内ライブラリの配布には社内フィードを利用し、効率的かつ安全な運用を心がけましょう。

Self-Contained Deploymentの選択肢

.NET CoreのPublishSingleFile

.NET Coreおよび.NET 5以降では、アプリケーションとその依存DLL、ランタイムを一つの実行可能ファイルにまとめるPublishSingleFileオプションが利用できます。

これにより、配布が非常にシンプルになり、DLLの配置場所を気にせずに済みます。

dotnet publishコマンドでPublishSingleFileを有効にするには、プロジェクトファイル.csprojに以下のように記述します。

<PropertyGroup>
  <PublishSingleFile>true</PublishSingleFile>
</PropertyGroup>

またはコマンドラインで指定する場合は、

dotnet publish -r win-x64 -p:PublishSingleFile=true

のようにします。

この方法では、すべての依存ファイルが単一のEXEにパッケージされるため、DLLの配置場所を気にせずに済みます。

特に配布やインストールが簡単になるため、配布形態として人気があります。

Trimオプションとトラブルシューティング

PublishSingleFileと併用されることが多いのがTrimオプションです。

Trimは未使用のコードを削除してファイルサイズを小さくする機能です。

.csprojに以下のように設定します。

<PropertyGroup>
  <PublishTrimmed>true</PublishTrimmed>
</PropertyGroup>

ただし、Trimは静的解析に基づいて不要コードを削除するため、リフレクションや動的コード生成を多用するアプリケーションでは、必要なコードまで削除されてしまい、実行時にエラーが発生することがあります。

トラブルシューティングのポイント

リフレクションを使うコードの明示的な保持

TrimmerRootAssemblyやDynamicDependency属性を使い、トリム対象から除外するコードを指定します。

PublishTrimmedを一時的に無効化

問題の切り分けのため、一度PublishTrimmedをfalseにして動作確認します。

ログの確認

ビルド時に-p:TrimMode=linkや-p:TrimWarnings=trueを指定して警告を確認し、問題箇所を特定します。

サードパーティライブラリの対応状況

一部のライブラリはトリムに対応していない場合があるため、最新バージョンの利用や代替ライブラリの検討が必要です。

Runtime IdentifierとRID指定

Self-Contained Deploymentでは、ターゲットプラットフォームを明示的に指定する必要があります。

これを行うのがRuntime Identifier(RID)です。

RIDはOSやCPUアーキテクチャを表す文字列で、適切に指定しないと正しいランタイムやネイティブDLLが含まれません。

代表的なRIDの例は以下の通りです。

RID	説明
win-x64	Windows 64ビット
win-x86	Windows 32ビット
linux-x64	Linux 64ビット
osx-x64	macOS 64ビット
linux-arm	Linux ARM
linux-arm64	Linux ARM 64ビット

RIDは.csprojのRuntimeIdentifierプロパティで指定します。

<PropertyGroup>
  <RuntimeIdentifier>win-x64</RuntimeIdentifier>
</PropertyGroup>

複数のRIDを指定してクロスプラットフォーム向けにビルドする場合は、RuntimeIdentifiersプロパティを使います。

<PropertyGroup>
  <RuntimeIdentifiers>win-x64;linux-x64;osx-x64</RuntimeIdentifiers>
</PropertyGroup>

RIDを指定してdotnet publishを実行すると、そのプラットフォーム用のランタイムとネイティブDLLが含まれた自己完結型の実行ファイルが生成されます。

RIDを指定しない場合はフレームワーク依存型のビルドとなり、ターゲット環境に.NETランタイムがインストールされている必要があります
RIDは.NETのRIDカタログで詳細が確認できます
Self-Contained Deploymentはファイルサイズが大きくなるため、配布方法やストレージ容量に注意が必要です

サンプルコード：PublishSingleFileとRID指定の例

以下は、win-x64向けに単一ファイルで自己完結型アプリケーションをビルドする.csprojの例です。

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net6.0</TargetFramework>
    <RuntimeIdentifier>win-x64</RuntimeIdentifier>
    <PublishSingleFile>true</PublishSingleFile>
    <PublishTrimmed>false</PublishTrimmed>
  </PropertyGroup>
</Project>

コマンドラインからは以下のようにビルド・発行します。

dotnet publish -c Release

この結果、bin\Release\net6.0\win-x64\publishフォルダーに単一の実行ファイルが生成されます。

DLLは含まれず、実行ファイル単体で動作します。

(単一のMyApp.exeファイルが生成される)

Self-Contained DeploymentのPublishSingleFileとRID指定を活用すると、DLLの配置を気にせずに済み、配布や展開が非常に楽になります。

ただし、Trimオプションの利用には注意が必要で、動作確認を十分に行うことが重要です。

プラットフォーム依存DLLの扱い

x86 / x64切り替え

.NETアプリケーションでネイティブDLLを利用する場合、CPUアーキテクチャ(x86やx64)に応じて適切なDLLを用意し、正しく読み込む必要があります。

特に、同じアプリケーションで32ビット版と64ビット版の両方をサポートする場合は、DLLの配置や参照方法に工夫が求められます。

RIDフォルダー構造

.NET Coreや.NET 5以降のSelf-Contained DeploymentやNuGetパッケージでは、プラットフォームごとに異なるDLLを管理するためにRID(Runtime Identifier)ごとのフォルダー構造を使います。

これにより、ビルドや実行時に適切なDLLが選択されます。

一般的なフォルダー構成例は以下の通りです。

runtimes/
  win-x86/
    native/
      native32.dll
  win-x64/
    native/
      native64.dll

runtimesフォルダーの下に、プラットフォームごとのRIDフォルダー(例：win-x86、win-x64)を作成します
それぞれのRIDフォルダー内にnativeフォルダーを置き、ネイティブDLLを配置します

この構造はNuGetパッケージでよく使われ、パッケージをインストールしたプロジェクトは実行時に自動的に適切なDLLを読み込みます。

P/Invoke先のネイティブDLLの配置

C#からネイティブDLLを呼び出す際は、DllImport属性を使ってDLL名を指定しますが、実行時にそのDLLがどこにあるかが重要です。

DLLの検索パスとDllImportの連携を理解しておくと、配置ミスやロードエラーを防げます。

DllImportと検索パスの連携

DllImport属性の基本的な書き方は以下の通りです。

[DllImport("native.dll", CallingConvention = CallingConvention.Cdecl)]
public static extern int NativeFunction(int param);

ここで指定した"native.dll"は、WindowsのDLL検索パスに従って探されます。

検索順序は以下の通りです。

アプリケーションの実行ファイルがあるディレクトリ

最初に、実行ファイル(EXE)が存在するフォルダーを探します。

システムディレクトリ

System32などのWindowsシステムフォルダー。

Windowsディレクトリ

C:\Windowsなど。

カレントディレクトリ

プロセスのカレントディレクトリ。

環境変数PATHに設定されたディレクトリ

PATHに登録されたフォルダーを順に検索。

このため、ネイティブDLLは実行ファイルと同じフォルダーに置くのが最も確実です。

複数のアーキテクチャに対応する場合は、前述のRIDフォルダー構造を使い、実行時に適切なDLLが配置されるようにします。

サンプルコード：P/InvokeでネイティブDLLを呼び出す例

以下は、native32.dllまたはnative64.dllにある関数を呼び出す例です。

実行時に適切なDLLがロードされるよう、SetDllDirectoryを使ってパスを追加する方法も示します。

using System;
using System.Runtime.InteropServices;
using System.IO;
using System.Reflection;
class NativeMethods
{
    [DllImport("native.dll", CallingConvention = CallingConvention.Cdecl)]
    public static extern int NativeFunction(int value);
}
class Program
{
    [DllImport("kernel32.dll", CharSet = CharSet.Auto, SetLastError = true)]
    static extern bool SetDllDirectory(string lpPathName);
    static void Main()
    {
        string baseDir = Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location);
        string archFolder = Environment.Is64BitProcess ? "win-x64" : "win-x86";
        string nativePath = Path.Combine(baseDir, "runtimes", archFolder, "native");
        if (!SetDllDirectory(nativePath))
        {
            Console.WriteLine("DLL検索パスの追加に失敗しました。");
            return;
        }
        int result = NativeMethods.NativeFunction(42);
        Console.WriteLine($"ネイティブ関数の結果: {result}");
    }
}

ネイティブ関数の結果: 84

この例では、実行時にプロセスのビット数を判定し、対応するネイティブDLLのパスをSetDllDirectoryで追加しています。

これにより、DllImportで指定したnative.dllが正しくロードされます。

プラットフォーム依存DLLの管理は、アプリケーションの安定動作に直結します。

RIDフォルダー構造を活用し、DllImportの検索パスを適切に設定することで、x86/x64環境でのDLL切り替えをスムーズに行えます。

バージョン衝突の回避テクニック

.NETアプリケーションで複数のDLLやアセンブリを利用する際、異なるバージョンの同じアセンブリが混在してしまい、バージョン衝突が発生することがあります。

これにより、実行時にFileLoadExceptionやFileNotFoundExceptionが発生し、アプリケーションが正常に動作しなくなることがあります。

ここでは、代表的な回避方法としてBindingRedirectによる強制リダイレクトと、AssemblyResolveイベントを使ったカスタムロジックについて解説します。

BindingRedirectによる強制リダイレクト

BindingRedirectは、アプリケーションの構成ファイルApp.configやweb.configに記述することで、特定のアセンブリの古いバージョンから新しいバージョンへの読み込みを強制的に切り替える仕組みです。

これにより、複数の依存関係が異なるバージョンを要求しても、指定したバージョンに統一して読み込むことができます。

oldVersion / newVersion 設定例

以下は、MyLibraryというアセンブリのバージョン1.0.0.0から1.2.0.0までの範囲を、バージョン1.2.0.0にリダイレクトする例です。

<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="MyLibrary"
                          publicKeyToken="32ab4ba45e0a69a1"
                          culture="neutral" />
        <bindingRedirect oldVersion="1.0.0.0-1.2.0.0"
                         newVersion="1.2.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

assemblyIdentity要素で対象のアセンブリ名、パブリックキー・トークン、カルチャを指定します
bindingRedirect要素のoldVersion属性にはリダイレクト対象のバージョン範囲を指定し、newVersion属性には実際に読み込むバージョンを指定します

この設定を行うことで、アプリケーションは古いバージョンのDLLを要求しても、常に新しいバージョンを読み込みます。

Visual Studioのビルド時に自動生成されることもありますが、手動で調整することも可能です。

AssemblyResolveイベントでのカスタムロジック

BindingRedirectで解決できない場合や、動的にアセンブリの読み込み先を制御したい場合は、AppDomain.AssemblyResolveイベントを利用します。

このイベントは、CLRがアセンブリを見つけられなかったときに発生し、カスタムロジックでアセンブリを手動でロードできます。

以下は、AssemblyResolveイベントを使って特定のフォルダーからアセンブリを読み込む例です。

using System;
using System.IO;
using System.Reflection;
class Program
{
    static void Main()
    {
        AppDomain.CurrentDomain.AssemblyResolve += OnAssemblyResolve;
        // ここでMyLibraryの機能を使う処理を呼び出す
        var type = Type.GetType("MyLibrary.Greeter, MyLibrary");
        dynamic greeter = Activator.CreateInstance(type);
        string message = greeter.SayHello("花子");
        Console.WriteLine(message);
    }
    private static Assembly OnAssemblyResolve(object sender, ResolveEventArgs args)
    {
        string assemblyName = new AssemblyName(args.Name).Name;
        string baseDir = AppDomain.CurrentDomain.BaseDirectory;
        string assemblyPath = Path.Combine(baseDir, "libs", assemblyName + ".dll");
        if (File.Exists(assemblyPath))
        {
            return Assembly.LoadFrom(assemblyPath);
        }
        return null; // 見つからなければnullを返す
    }
}

こんにちは、花子さん！

この例では、libsフォルダーにあるDLLを動的に読み込むようにしています。

AssemblyResolveイベントは、通常の探索パスにないDLLを読み込む際に有効です。

ログ出力とデバッグ

AssemblyResolveイベントはトラブルシューティングにも役立ちます。

読み込み失敗時にログを出力することで、どのアセンブリが見つからなかったのか、どのパスを探索したのかを把握できます。

以下は、ログ出力を追加した例です。

private static Assembly OnAssemblyResolve(object sender, ResolveEventArgs args)
{
    string assemblyName = new AssemblyName(args.Name).Name;
    string baseDir = AppDomain.CurrentDomain.BaseDirectory;
    string assemblyPath = Path.Combine(baseDir, "libs", assemblyName + ".dll");
    Console.WriteLine($"AssemblyResolve: {assemblyName}");
    Console.WriteLine($"探索パス: {assemblyPath}");
    if (File.Exists(assemblyPath))
    {
        Console.WriteLine("アセンブリをロードしました。");
        return Assembly.LoadFrom(assemblyPath);
    }
    Console.WriteLine("アセンブリが見つかりませんでした。");
    return null;
}

このようにログを出すことで、実行時のDLL読み込み状況を詳細に追跡でき、問題の原因特定が容易になります。

バージョン衝突は複雑な依存関係の中でよく発生しますが、BindingRedirectとAssemblyResolveを適切に使い分けることで、安定した動作環境を構築できます。

特にAssemblyResolveは柔軟な対応が可能ですが、過度に使うとメンテナンスが難しくなるため、基本はBindingRedirectで解決することをおすすめします。

サードパーティDLL更新時の運用

セマンティックバージョニングの確認

サードパーティ製のDLLを利用する際、バージョン管理は非常に重要です。

特に、セマンティックバージョニング(Semantic Versioning、略してSemVer)に準拠しているかどうかを確認することで、更新による影響範囲を予測しやすくなります。

セマンティックバージョニングは、バージョン番号を「メジャー.マイナー.パッチ」の3つの数字で表現します。

バージョン部分	意味
メジャー	後方互換性のない大きな変更があった場合に増加
マイナー	後方互換性のある機能追加があった場合に増加
パッチ	バグ修正などの後方互換性のある小さな変更

たとえば、1.2.3から2.0.0に更新された場合は、互換性のない変更が含まれている可能性が高いため、注意が必要です。

逆に1.2.3から1.3.0や1.2.4への更新は比較的安全と判断できます。

運用上のポイント

サードパーティDLLのリリースノートや変更履歴を必ず確認し、メジャーバージョンの変更があった場合は影響範囲を詳細に調査します
依存関係のある他のライブラリや自社コードとの互換性を検証します
バージョン番号の更新ルールが守られていない場合は、慎重にテストを行うか、代替ライブラリの検討も視野に入れる

自動ビルドとCDによる配置自動化

サードパーティDLLの更新を手動で管理すると、ミスや遅延が発生しやすくなります。

そこで、CI/CD(継続的インテグレーション／継続的デリバリー)パイプラインを活用し、ビルドから配置までの自動化を推進することが効果的です。

自動化のメリットは以下の通りです。

更新のたびに手動作業が不要になり、ヒューマンエラーを減らせます
配布物の一貫性が保たれ、環境間の差異を減らせます
迅速なリリースサイクルを実現できます

CIパイプラインでのArtifact管理

CIパイプラインでは、ビルド成果物(Artifact)としてDLLやパッケージを生成し、管理・配布します。

Artifact管理は更新時のDLL運用において重要な役割を果たします。

具体的な運用例

ビルドジョブでDLLを生成

ソースコードの変更やサードパーティDLLの更新をトリガーにビルドを実行し、最新のDLLを生成します。

Artifactとして保存

ビルド成果物をCIサーバーのArtifactストレージに保存します。

これにより、過去のビルド成果物も追跡可能です。

バージョン管理とタグ付け

ビルド番号やGitのコミットハッシュを使ってArtifactにバージョンやタグを付け、識別しやすくします。

自動デプロイや配布

CDパイプラインでArtifactをテスト環境や本番環境に自動的に配布します。

NuGetフィードやファイルサーバー、クラウドストレージを利用することが多いです。

ロールバック対応

問題が発生した場合は、過去のArtifactに戻すことで迅速に対応可能です。

サンプル：Azure DevOpsでのArtifact管理例(YAML抜粋)

trigger:

- main

pool:
  vmImage: 'windows-latest'
steps:

- task: DotNetCoreCLI@2

  inputs:
    command: 'build'
    projects: '**/*.csproj'

- task: DotNetCoreCLI@2

  inputs:
    command: 'publish'
    projects: '**/*.csproj'
    arguments: '--configuration Release --output $(Build.ArtifactStagingDirectory)'

- publish: $(Build.ArtifactStagingDirectory)

  artifact: drop

この例では、mainブランチへのプッシュをトリガーにビルドとパブリッシュを行い、成果物をdropという名前でArtifactとして保存しています。

これをCDパイプラインで利用し、テスト環境や本番環境へ自動展開できます。

サードパーティDLLの更新管理は、セマンティックバージョニングの理解とCI/CDによる自動化が鍵となります。

これらを組み合わせることで、安定した運用と迅速なリリースを両立できます。

セキュリティ観点での留意点

コードサインと信頼性

DLLを安全に利用するためには、コードサイン(Code Signing)が重要な役割を果たします。

コードサインとは、開発者がデジタル証明書を使ってDLLや実行ファイルに電子署名を行うことで、配布物の改ざん防止や発行元の証明を可能にする技術です。

コードサインされたDLLは、以下のようなメリットがあります。

改ざん検知

署名が有効であれば、DLLが配布後に改ざんされていないことを保証できます。

改ざんされている場合は署名が無効となり、警告やブロックが発生します。

発行元の信頼性証明

デジタル証明書により、DLLの発行元が明確になります。

これにより、ユーザーやシステムは信頼できるソースからのDLLであることを確認できます。

セキュリティポリシーとの連携

Windowsのセキュリティ機能や企業のポリシーで、署名されていないDLLの読み込みを制限する設定が可能です。

コードサインはVisual Studioのビルド設定や、signtool.exeなどのツールを使って行います。

特に配布用のDLLや重要なライブラリは必ず署名を行い、信頼性を高めることが推奨されます。

DLLハイジャック対策

DLLハイジャックは、悪意のある第三者が正規のDLLと同名の悪意あるDLLをアプリケーションの検索パスに置き、アプリケーションがそれを読み込んでしまう攻撃手法です。

これにより、任意のコードが実行されるリスクがあります。

DLLハイジャックを防ぐためには、DLLの検索パスの管理とWindowsのセキュリティ設定を適切に行うことが重要です。

SafeDllSearchMode設定

WindowsにはSafeDllSearchModeというレジストリ設定があり、これを有効にすることでDLLの検索順序が安全なものに変更されます。

通常のDLL検索順序(SafeDllSearchMode無効時)

カレントディレクトリ
システムディレクトリ(例：C:\Windows\System32)
16ビットシステムディレクトリ
Windowsディレクトリ
PATH環境変数に指定されたディレクトリ

この場合、カレントディレクトリが最優先で検索されるため、攻撃者がカレントディレクトリに悪意あるDLLを置くと読み込まれてしまうリスクがあります。

SafeDllSearchMode有効時の検索順序

システムディレクトリ
16ビットシステムディレクトリ
Windowsディレクトリ
カレントディレクトリ
PATH環境変数に指定されたディレクトリ

カレントディレクトリの優先順位が下がるため、ハイジャックのリスクが軽減されます。

SafeDllSearchModeの有効化方法

SafeDllSearchModeはレジストリの以下のキーで設定します。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager

値の名前：SafeDllSearchMode

値の種類：REG_DWORD

値の設定：

1 → 有効(推奨)
0 → 無効

コマンドプロンプト(管理者権限)で以下のコマンドを実行して有効化できます。

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager" /v SafeDllSearchMode /t REG_DWORD /d 1 /f

設定変更後はシステムの再起動が必要です。

その他の対策

フルパス指定でDLLを読み込む

LoadLibraryやDllImportでDLLのフルパスを指定し、検索パスに依存しない方法を使います。

SetDllDirectoryやAddDllDirectoryの活用

DLLの検索パスを明示的に制御し、信頼できるディレクトリのみを指定します。

アプリケーションの実行権限の制限

不要な権限を与えず、悪意あるDLLの配置や実行を防ぐ。

DLLの安全な配置と読み込みは、アプリケーションのセキュリティを守る上で欠かせません。

コードサインで信頼性を確保し、SafeDllSearchModeを有効にしてDLLハイジャックのリスクを減らすことを強く推奨します。

クロスプラットフォームプロジェクトでの共有DLL

クロスプラットフォーム開発では、WindowsだけでなくLinuxやmacOSなど複数のOSやアーキテクチャを対象にするため、DLLやライブラリの共有方法に工夫が必要です。

ここでは、Multi-targetingや条件付き参照、Shared Projectsやリンク参照を活用した共有DLLの管理方法を解説します。

Multi-targetingと条件付き参照

Multi-targetingは、1つのプロジェクトで複数のターゲットフレームワーク(Target Framework)を指定し、それぞれに対応したビルドを行う仕組みです。

これにより、同じコードベースからWindows用のDLLやLinux用のDLLを生成できます。

Multi-targetingの設定例

.csprojファイルで複数のターゲットフレームワークを指定します。

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFrameworks>net6.0-windows;net6.0-linux;net6.0-macos</TargetFrameworks>
  </PropertyGroup>
</Project>

この設定により、dotnet buildやdotnet publishは3つのプラットフォーム向けにビルドを行います。

条件付き参照の活用

ターゲットフレームワークごとに異なるDLLを参照したい場合は、条件付きで参照を切り替えられます。

<ItemGroup Condition="'$(TargetFramework)' == 'net6.0-windows'">
  <Reference Include="WindowsSpecificLibrary.dll" />
</ItemGroup>
<ItemGroup Condition="'$(TargetFramework)' == 'net6.0-linux'">
  <Reference Include="LinuxSpecificLibrary.dll" />
</ItemGroup>

このように条件を指定することで、ビルド時に対象プラットフォームに応じたDLLだけが参照されます。

条件付きコンパイル

コード内でも#ifディレクティブを使い、プラットフォームごとに異なる処理を記述できます。

#if WINDOWS
    Console.WriteLine("Windows向けの処理");
#elif LINUX
    Console.WriteLine("Linux向けの処理");
#else
    Console.WriteLine("その他のプラットフォーム");
#endif

DefineConstantsプロパティでシンボルを定義し、ビルド時に切り替えます。

Shared Projectsとリンク参照

複数のプロジェクト間で共通のコードやDLLを共有する方法として、Shared Projectsとリンク参照があります。

Shared Projects

Shared Projectは、コードファイルを物理的に共有し、参照する各プロジェクトのコンテキストでビルドされる仕組みです。

DLLとしてビルドされるわけではなく、ソースコードが直接取り込まれます。

利点
- コードの重複を避けられます
- プラットフォーム固有のコードを条件付きコンパイルで切り替えやすい
- 依存関係がシンプルになります
使い方

Visual StudioでShared Projectを作成し、他のプロジェクトから参照を追加します。

リンク参照

リンク参照は、別プロジェクトのソースコードファイルをコピーせずに参照する方法です。

ファイルの物理的な場所は変えずに、複数のプロジェクトで同じファイルを共有できます。

設定方法

プロジェクトのcsprojに以下のように記述します。

<ItemGroup>
  <Compile Include="..\SharedCode\Utility.cs">
    <Link>Shared\Utility.cs</Link>
  </Compile>
</ItemGroup>

利点
- ファイルの一元管理ができます
- 変更が即座にすべての参照プロジェクトに反映されます
注意点
- プロジェクト間で依存関係が複雑になる場合があります
- 条件付きコンパイルでプラットフォームごとの切り替えが必要になることが多い

サンプルコード：Multi-targetingと条件付き参照の例

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFrameworks>net6.0-windows;net6.0-linux</TargetFrameworks>
  </PropertyGroup>
  <ItemGroup Condition="'$(TargetFramework)' == 'net6.0-windows'">
    <PackageReference Include="WindowsSpecificPackage" Version="1.0.0" />
  </ItemGroup>
  <ItemGroup Condition="'$(TargetFramework)' == 'net6.0-linux'">
    <PackageReference Include="LinuxSpecificPackage" Version="1.0.0" />
  </ItemGroup>
</Project>

using System;
class Program
{
    static void Main()
    {
#if WINDOWS
        Console.WriteLine("Windows向けの処理を実行");
#elif LINUX
        Console.WriteLine("Linux向けの処理を実行");
#else
        Console.WriteLine("その他のプラットフォーム");
#endif
    }
}

クロスプラットフォーム開発では、Multi-targetingや条件付き参照を活用してプラットフォームごとのDLL管理を行い、Shared Projectsやリンク参照で共通コードを効率的に共有することが重要です。

これにより、保守性と拡張性の高いプロジェクト構成が実現できます。

インストーラー利用による配置

アプリケーションの配布方法として、インストーラーを利用するケースが多くあります。

特にMSIやClickOnceはWindows環境で広く使われており、DLLの配置やパス設定を自動化できるため、ユーザーの手間を減らし、確実な動作環境を提供できます。

MSIとClickOnceの構成

MSIインストーラー

MSI(Microsoft Installer)はWindowsの標準的なインストーラー形式で、複雑なインストール処理やカスタマイズが可能です。

MSIを使うと、DLLの配置場所やレジストリ設定、ショートカット作成などを細かく制御できます。

DLL配置

MSIのインストールパッケージ内でDLLを指定したフォルダーに配置します。

通常はアプリケーションのインストールディレクトリ(例：C:\Program Files\MyApp)にDLLをまとめて配置します。

依存関係の管理

MSIは複数のファイルをまとめて管理できるため、DLLのバージョン管理や更新も一元化できます。

Custom Actionsでのパス設定

MSIでは「Custom Actions」を使って、インストール時に特定の処理を実行できます。

たとえば、DLLのパスを環境変数に追加したり、設定ファイルを書き換えたりすることが可能です。

ClickOnce

ClickOnceは、Windowsアプリケーションの簡易配布・更新を目的とした技術で、ユーザーがWebやネットワーク経由で簡単にアプリをインストール・更新できます。

DLLの自動配置

ClickOnceはアプリケーションの必要なDLLを自動的に配布フォルダーに配置し、依存関係を管理します。

サンドボックス環境

ClickOnceアプリはユーザーのプロファイルフォルダー内にインストールされるため、システム全体への影響が少なく安全です。

パス設定不要

DLLはアプリケーションの実行パスに配置されるため、特別なパス設定は不要です。

Custom Actionsでのパス設定

MSIのCustom Actionsは、インストールプロセス中に任意のスクリプトやプログラムを実行できる機能です。

DLLの配置後に環境変数の更新や設定ファイルの修正を行う場合に使います。

例：環境変数PATHにDLLフォルダーを追加するCustom Action

インストール先のDLLフォルダーを取得。
既存のPATH環境変数にフォルダーを追加。
システムまたはユーザー環境変数を更新。
必要に応じて再起動を促します。

この処理はPowerShellスクリプトやカスタムC#コードで実装し、MSIビルドツール(WiXやInstallShieldなど)で組み込みます。

Zip配布時のフォルダー構成

インストーラーを使わずにZipファイルで配布する場合は、フォルダー構成を工夫してDLLの配置と参照を明確にする必要があります。

基本的なフォルダー構成例

MyApp.zip
│
├─ MyApp.exe
├─ MyLibrary.dll
├─ ThirdParty.dll
├─ native/
│   ├─ native32.dll
│   └─ native64.dll
└─ config/
    └─ appsettings.json

実行ファイルと管理対象DLLは同じフォルダーに配置し、簡単に参照できるようにします
ネイティブDLLはnativeなどのサブフォルダーに分け、SetDllDirectoryやApp.configのprobing設定でパスを指定します
設定ファイルはconfigなど別フォルダーに分けて管理しやすくします

配布時の注意点

Zip解凍後にフォルダー構成が崩れないように注意します
ネイティブDLLのビット数(x86/x64)に応じて適切なDLLを配置し、実行時に正しく読み込まれるようにします
実行ファイルの起動スクリプトやバッチファイルで環境変数の設定やパス追加を行う場合があります

サンプル：MSIのCustom Actionで環境変数にパスを追加するPowerShellスクリプト例

param(
    [string]$InstallDir
)
$envName = "PATH"
$pathValue = [Environment]::GetEnvironmentVariable($envName, [EnvironmentVariableTarget]::Machine)
if (-not $pathValue.Contains($InstallDir)) {
    $newPath = "$pathValue;$InstallDir"
    [Environment]::SetEnvironmentVariable($envName, $newPath, [EnvironmentVariableTarget]::Machine)
    Write-Output "環境変数PATHに$InstallDirを追加しました。"
} else {
    Write-Output "環境変数PATHに$InstallDirは既に含まれています。"
}

このスクリプトをMSIのCustom Actionとして実行し、インストール先のDLLフォルダーをPATHに追加できます。

インストーラーを利用したDLL配置は、ユーザーの操作を簡素化し、環境依存の問題を減らす効果があります。

MSIの柔軟なカスタマイズやClickOnceの簡易配布、Zip配布時のフォルダー構成を適切に設計し、安定したアプリケーション運用を実現しましょう。

テスト環境でのDLL運用

テスト環境におけるDLLの管理は、開発効率やテストの信頼性に直結します。

ここでは、テストプロジェクトでのDLL共有方法としてリンク参照の活用と、テスト実行時のDLLロック問題を回避するためのShadow Copy設定について詳しく解説します。

テストプロジェクトへのリンク参照

テストプロジェクトで自作DLLや共通ライブラリのコードを共有する際、リンク参照を使うと便利です。

リンク参照とは、物理的にファイルをコピーせずに、別プロジェクトのソースコードファイルを参照する方法です。

これにより、コードの重複を避けつつ、最新のコードを常にテストに反映できます。

リンク参照の設定方法

Visual Studioでリンク参照を追加する手順は以下の通りです。

テストプロジェクトのソリューションエクスプローラーで「参照」ではなく、「追加」→「既存の項目」を選択。
共有したいソースコードファイルを選択。
「追加」ボタンの横にある▼をクリックし、「リンクとして追加」を選択。

これにより、ファイルはコピーされずに参照され、元のファイルの変更が即座にテストプロジェクトに反映されます。

メリットと注意点

メリット
- コードの一元管理が可能です
- ビルド時に最新のコードがコンパイルされるため、テストの信頼性が向上
- 複数プロジェクト間でのコード共有が容易
注意点
- プロジェクト間の依存関係が複雑になる場合があります
- 条件付きコンパイルや名前空間の管理に注意が必要でしょう
- 大規模プロジェクトではビルド時間が増加する可能性があります

Shadow Copy設定

テスト実行時にDLLがロックされてしまい、ビルドや再実行ができない問題はよくあります。

これは、テストランナーがDLLを直接読み込んでロックしてしまうためです。

これを回避するために、Shadow Copy(シャドウコピー)機能を利用します。

Shadow Copyとは

Shadow Copyは、実行時にDLLのコピーを作成し、そのコピーを読み込む仕組みです。

これにより、元のDLLファイルはロックされず、ビルドや更新が可能になります。

MSTestやNUnitでのShadow Copy設定例

MSTest

MSTestではデフォルトでShadow Copyが有効になっていますが、設定を確認・変更したい場合は.runsettingsファイルを使います。

<RunSettings>
  <RunConfiguration>
    <DisableAppDomain>False</DisableAppDomain>
  </RunConfiguration>
</RunSettings>

DisableAppDomainをFalseに設定すると、AppDomainが分離され、Shadow Copyが有効になります。

NUnit

NUnitでは、テスト実行時に--shadowcopyオプションを指定してShadow Copyを有効にできます。

nunit3-console.exe MyTests.dll --shadowcopy

また、NUnitのGUIランナーやVisual StudioのTest ExplorerでもShadow Copyの設定が可能です。

Shadow Copyの効果

DLLファイルのロックを回避し、ビルドや再実行がスムーズになります
複数のテスト実行が並行してもファイル競合が起きにくい
テスト環境の安定性が向上します

サンプルコード：リンク参照を使ったテストプロジェクトの例

// 共有ライブラリのコード(SharedCode/Calculator.cs)
namespace SharedCode
{
    public class Calculator
    {
        public int Add(int a, int b) => a + b;
    }
}

// テストプロジェクトのテストコード(Tests/CalculatorTests.cs)
using Microsoft.VisualStudio.TestTools.UnitTesting;
using SharedCode;
[TestClass]
public class CalculatorTests
{
    [TestMethod]
    public void Add_ReturnsCorrectSum()
    {
        var calc = new Calculator();
        int result = calc.Add(2, 3);
        Assert.AreEqual(5, result);
    }
}

この例では、Calculator.csをリンク参照でテストプロジェクトに追加し、最新のコードをテストしています。

テスト環境でのDLL運用は、リンク参照でコード共有を効率化し、Shadow Copyでファイルロック問題を回避することがポイントです。

これらを適切に設定することで、開発とテストの生産性を大きく向上させられます。

エラー例と解決フロー

DLLの配置や参照に関するトラブルは、開発や運用の現場でよく発生します。

ここでは代表的なエラーであるFileNotFoundExceptionとBadImageFormatExceptionについて、その原因と解決方法を詳しく解説します。

FileNotFoundException

FileNotFoundExceptionは、指定されたDLLやアセンブリが見つからない場合に発生します。

実行時に必要なDLLが配置されていなかったり、パスが誤っていることが主な原因です。

Fusionログビューアを使った解析

.NET Frameworkでは、アセンブリの読み込みに失敗した際の詳細な情報を取得するためにFusionログビューアfuslogvw.exeを利用できます。

これにより、どのパスを探索したか、なぜ読み込みに失敗したかを確認できます。

Fusionログビューアの使い方

Fusionログの有効化

管理者権限でコマンドプロンプトを開き、以下のコマンドを実行してFusionログを有効にします。

fuslogvw.exe

Fusionログビューアが起動したら、「Settings」ボタンを押し、「Log bind failures to disk」にチェックを入れます。

必要に応じて「Log all binds」も選択可能ですが、ログ量が増えるため注意してください。

アプリケーションを実行

DLLが見つからずにFileNotFoundExceptionが発生する状況を再現します。

ログの確認

Fusionログビューアに戻り、最新のログを選択して詳細を確認します。

ログには探索したパスや失敗理由が記録されています。

原因の特定と対策

DLLが存在しないパスを参照している場合は、正しい場所にDLLを配置します
バージョンやパブリックキーが異なる場合は、bindingRedirectの設定を見直します
GACに登録されているかどうかも確認します

例：Fusionログの一部

LOG: Attempting download of new URL file:///C:/MyApp/bin/Debug/MyLibrary.dll
LOG: Attempting download of new URL file:///C:/MyApp/bin/Debug/MyLibrary.exe
LOG: The operation failed.

このログから、MyLibrary.dllがbin\Debugに存在しないことがわかります。

BadImageFormatException

BadImageFormatExceptionは、読み込もうとしたDLLが現在のプロセスのアーキテクチャと合わない場合に発生します。

たとえば、64ビットプロセスで32ビットDLLを読み込もうとした場合などです。

AnyCPUビルドの落とし穴

.NETのAnyCPUビルドは、実行環境に応じて32ビットまたは64ビットで動作する柔軟な設定ですが、ネイティブDLLとの組み合わせで問題が起きやすいです。

問題の例

アプリケーションがAnyCPUでビルドされているが、64ビット環境で実行されます
32ビット専用のネイティブDLLをP/Invokeで呼び出そうとするとBadImageFormatExceptionが発生

解決策

ビルド構成を明示的に指定する

x86またはx64でビルドし、対応するネイティブDLLを用意します。

ネイティブDLLの配置を分ける

RIDフォルダー構造(例：runtimes/win-x86/native、runtimes/win-x64/native)を使い、実行時に適切なDLLを読み込みます。

プロセスのビット数を確認するコード例

using System;
class Program
{
    static void Main()
    {
        Console.WriteLine($"プロセスは64ビットか？ {Environment.Is64BitProcess}");
    }
}

Visual Studioのプロジェクト設定でプラットフォームターゲットを固定する

プロジェクトのプロパティ → 「ビルド」タブ → 「プラットフォームターゲット」をx86またはx64に設定。

エラー解決の流れまとめ

エラー名	主な原因	対応策
`FileNotFoundException`	DLLが指定パスに存在しない	Fusionログで探索パスを確認し、DLLを正しい場所に配置
	バージョンや署名の不一致	`bindingRedirect`設定を見直す
`BadImageFormatException`	プロセスとDLLのビット数不一致	プラットフォームターゲットを固定し、対応DLLを用意
	AnyCPUビルドでネイティブDLLが合わない	RIDフォルダー構造でDLLを分ける

これらのエラーは、DLLの配置やビルド設定のミスマッチが原因で起こることが多いため、ログ解析やビルド構成の見直しを丁寧に行うことが重要です。

Fusionログビューアやビルド設定の確認を習慣化し、安定した環境構築を心がけましょう。

依存関係の可視化ツール

複雑なC#プロジェクトでは、多数のDLLやパッケージが絡み合い、依存関係の把握が難しくなります。

依存関係の可視化ツールを活用することで、どのDLLがどこから参照されているか、バージョンの不整合がないかを効率的に確認できます。

ここでは、代表的なツールであるILSpy、dotnet-trace、そしてVisual StudioのDependency Validation機能について解説します。

ILSpy / dotnet-trace

ILSpy

ILSpyはオープンソースの.NETアセンブリデコンパイラで、DLLの中身を解析し、依存関係を視覚的に確認できます。

GUIツールとして使いやすく、以下のような特徴があります。

アセンブリの読み込みとデコンパイル

DLLやEXEファイルを読み込み、ILコードやC#コードにデコンパイルして表示します。

依存関係ツリーの表示

アセンブリが参照している他のアセンブリをツリー形式で表示し、どのDLLがどのDLLに依存しているかを把握できます。

バージョン情報の確認

参照アセンブリのバージョンやパブリックキー・トークンなどの詳細情報も確認可能です。

プラグイン対応

拡張機能を追加して機能を強化できます。

ILSpyは公式サイト(https://github.com/icsharpcode/ILSpy)から無料でダウンロード可能です。

dotnet-trace

dotnet-traceは、.NET Coreおよび.NET 5以降のランタイムで動作するトレースツールで、実行中のアプリケーションのパフォーマンスや依存関係の動的な情報を収集できます。

ランタイムトレース

実行中のプロセスにアタッチして、アセンブリのロードイベントやメソッド呼び出しを記録します。

依存関係の動的解析

実際に読み込まれたDLLやアセンブリの情報を取得し、どのタイミングでどのDLLが使われているかを把握できます。

コマンドラインツール

CLIで操作し、トレース結果をファイルに保存。

後で解析ツール(PerfViewなど)で詳細を確認可能です。

クロスプラットフォーム対応

Windows、Linux、macOSで利用できます。

dotnet-traceは.NET SDKに含まれているか、dotnet tool install --global dotnet-traceでインストール可能です。

Visual Studio Dependency Validation

Visual Studioには、依存関係の設計ルールを検証する「Dependency Validation」機能があります。

これにより、プロジェクト間の依存関係を視覚化し、設計上のルール違反を検出できます。

主な機能

依存関係グラフの生成

ソリューション内のプロジェクトやアセンブリの依存関係をグラフ形式で表示。

矢印で依存方向が示され、全体構造を把握しやすい。

依存関係ルールの定義

「この層は他の層に依存してはいけない」などのルールを設定し、違反があれば警告を表示。

循環依存の検出

依存関係の循環を自動検出し、設計の問題点を明確化。

コードマップとの連携

コードマップ機能と連携し、ソースコードレベルで依存関係を追跡可能です。

使い方

Visual Studioのメニューから「アーキテクチャ」→「依存関係の検証」を選択。
依存関係グラフが生成され、プロジェクト間の関係が表示されます。
ルールを作成し、依存関係の制約を設定。
ビルド時や手動で検証を実行し、違反を検出。

Visual Studio Enterpriseエディションで利用可能な機能ですが、設計品質の向上に非常に役立ちます。

ツール名	用途・特徴	利用シーン
ILSpy	アセンブリのデコンパイルと静的依存関係の可視化	DLLの中身確認、依存関係の静的解析
dotnet-trace	実行時のアセンブリロードやパフォーマンスのトレース	実行時依存関係の動的解析、パフォーマンス調査
Visual Studio Dependency Validation	プロジェクト間の依存関係設計ルールの検証と可視化	設計段階での依存関係管理、循環依存の検出

これらのツールを組み合わせて使うことで、DLLの依存関係を正確に把握し、問題の早期発見や設計の改善につなげられます。

特に大規模プロジェクトや複雑な依存関係を持つシステムでは、積極的に活用することをおすすめします。