Enterprise Library 6.5 採用の ASP.NET MVC（C#）で MySQL ドライバを 8.0 系へ更新しようとすると、単純な DLL 置き換えでは Enterprise Library 周辺でコンパイルエラーや実行時エラーが出がちです。原因の整理から、暫定回避策、そして長期的に安全な移行手順までを具体的にまとめます。
今回の状況を「技術要素」に分解して整理する
まず、問題を最短距離で解くために、登場人物をはっきりさせます。今回の構成はざっくり次の組み合わせです。
| 要素 | 現状 | やりたいこと | 詰まりやすいポイント |
|---|---|---|---|
| アプリ | ASP.NET MVC（C#） | 大きくは変えたくない | データアクセス層がライブラリに強く依存していると影響範囲が広がる |
| フレームワーク | .NET Framework 4.5 | .NET Framework 4.8 へ | 古い NuGet 依存関係、bindingRedirect、TLS、古いビルド設定が露呈しやすい |
| データアクセス | Enterprise Library 6.5（Data Access） | 可能なら触りたくない | メンテ停止のレガシーで、新しいドライバ前提の設計には追従しにくい |
| DB | MySQL（例：5.7系） | 将来的に 8.0 系へ（ドライバも 8.0 系へ） | ドライバ更新だけのつもりでも、認証方式・TLS・SQLモード差異が表面化する |
要点は「Enterprise Library を残したまま、MySQL ドライバだけ最新へ」が“構造的に”難しくなりやすいことです。これは、あなたのコードが悪いという話ではなく、依存している前提が古いことが原因になりやすいです。
なぜ「MySQL の DLL を差し替えるだけ」では破綻しやすいのか
「DB オブジェクト（テーブル・ストアド）を変えず、ライブラリだけ更新したい」という要望は現場ではよくあります。ただ、Enterprise Library 6.5 と MySQL 8.0 系ドライバの間には、次のような“見えない地雷”が潜みがちです。
アセンブリのバージョン差と依存関係の連鎖
- MySQL ドライバ（MySql.Data / MySqlConnector など）は、バージョンが上がるほど内部依存（追加 NuGet、.NET Framework の最低要件、暗号/TLS 周り）が変わりやすい
- 古いプロジェクトほど
packages.configや古い参照方法が残っていて、差し替えた瞬間に参照解決が壊れやすい - コンパイルは通っても、実行時に
FileLoadException（アセンブリ読み込み失敗）やTypeLoadException（型の読み込み失敗）に転ぶことも多い
Enterprise Library 側の「設定駆動」とプロバイダ登録
Enterprise Library の Data Access は、設定（web.config/app.config）から Database を生成することが多いです。このとき、
- 接続文字列の
providerName DbProviderFactoriesの登録- Enterprise Library 独自の設定（dataConfiguration / databaseSettings 等）
が正しく揃っていないと、差し替えは成功しません。「DLL だけ差し替えた」は、裏側の登録情報が古いままになっているケースが非常に多いです。
MySQL 8.0 系で表面化しやすい接続・認証の差
ドライバ更新は “ADO.NET の部品交換” に見えますが、MySQL 8.0 系の環境では以下の影響が出やすくなります。
- 認証方式（例：ユーザーの認証プラグイン差）
- TLS/暗号スイートの要件
- 接続文字列の推奨設定（SSL/TLS、タイムゾーン、文字コードなど）
結果として「Enterprise Library は触らないつもりだったのに、接続の作り方や設定を結局いじることになる」状況になりがちです。
最初に決めるべきは「短期ゴール」と「長期ゴール」
この手の移行は、ゴールを一つにしようとすると失敗しやすいです。おすすめは、目的を二段階に分けることです。
| ゴール | 目的 | 達成条件 | おすすめの考え方 |
|---|---|---|---|
| 短期 | とにかく止めない（最短で動かす） | 現行機能が同等に稼働する | Enterprise Library を残す“暫定策”も許容する |
| 長期 | 将来の更新に耐える（メンテしやすくする） | Enterprise Library 依存が排除され、ドライバ更新が恐くない | 段階的にデータアクセス層を置き換えて脱却する |
質問文の「できれば Enterprise Library 側は触りたくない」は短期ゴールとしては自然です。一方で、長期ゴール（安全に運用し続ける）を考えると、Enterprise Library を“触らない”より“閉じ込めて捨てられる状態にする”方が現実的です。
短期で乗り切る暫定対応
「今すぐにでも MySQL 8.0 系へ寄せたい」「工数が限られている」場合の“止血案”です。ただし、暫定策は暫定策として期限を切るのがポイントです。
ODBC 経由でつなぐ（Enterprise Library を残す最終手段）
Enterprise Library 側は ODBC を通して DB に接続できるため、MySQL 8 対応の ODBC ドライバを使って接続する案があります。
- サーバーへ ODBC ドライバを導入
- 接続文字列を ODBC 用に変更
- Enterprise Library のプロバイダを ODBC 前提で設定
| 観点 | メリット | デメリット | 向いている状況 |
|---|---|---|---|
| 実装工数 | コード改修が最小で済む可能性 | ODBC 設定・運用が増える | 短期の火消し、リリースを止められない |
| 性能 | ケースによっては十分 | ネイティブ ADO.NET より不利になりやすい | 性能要求がそこまで高くない |
| 保守性 | 移行の踏み台としては有効 | 長期的に技術負債になりやすい | 期限を切って“次の段階”へ行ける |
ODBC 案は「とにかく動かす」目的なら有効ですが、パフォーマンスと運用の面で長期利用はおすすめしません。
（可能なら）Enterprise Library は GenericDatabase に寄せて依存を薄くする
もし現状が「MySQL 専用の拡張（独自 Database クラス）」や「特定の MySQL ドライバ型にべったり」になっているなら、まずは Enterprise Library の利用形態を “汎用の GenericDatabase” 寄りに寄せます。
- コード側は
Database/DbCommand/IDataReaderなどの抽象に寄せる MySqlParameterなど特定型を直接触る箇所を減らす- 設定（providerName 等）でプロバイダを差し替えやすくする
この段階でコンパイルエラーの多く（型が見つからない・参照が壊れる）が減ることがあります。つまり、ドライバ更新より先に “密結合をほどく” と成功率が上がります。
bindingRedirect とプロバイダ登録を「差し替え前提」で見直す
DLL 差し替えで詰まる典型は、参照のズレです。次の項目は “必ず見る” くらいでちょうどいいです。
| チェック項目 | 見る場所 | 症状 | 対処の方向性 |
|---|---|---|---|
| アセンブリ参照の二重化 | 参照設定 / NuGet | 同じ名前の DLL が複数バージョン混在 | 参照を一本化、不要な参照削除 |
| bindingRedirect | web.config の runtime | 実行時に FileLoadException | 依存アセンブリの redirect を揃える |
| DbProviderFactories | web.config の system.data | プロバイダが見つからない | invariant/type の登録を更新 |
| providerName | connectionStrings | 生成される接続が想定と違う | 利用するドライバに合わせる |
参考として、web.config の形は次のようになります（値は環境に合わせて確認してください）。
<connectionStrings>
<add name="AppDb"
connectionString="Server=...;Database=...;User Id=...;Password=...;"
providerName="MySql.Data.MySqlClient" />
</connectionStrings>
<system.data>
<DbProviderFactories>
<remove invariant="MySql.Data.MySqlClient" />
<add name="MySQL Data Provider"
invariant="MySql.Data.MySqlClient"
description="MySQL Data Provider"
type="MySql.Data.MySqlClient.MySqlClientFactory, MySql.Data, Version=8.0.41.0, Culture=neutral, PublicKeyToken=c5687fc88969c44d" />
</DbProviderFactories>
</system.data>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="MySql.Data" culture="neutral" publicKeyToken="c5687fc88969c44d" />
<bindingRedirect oldVersion="0.0.0.0-8.0.41.0" newVersion="8.0.41.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
このあたりはプロジェクトごとに差が大きいので、「設定を固定化してからコードを直す」より、「コードの依存を薄くしてから設定を揃える」方がスムーズに進むことが多いです。
推奨ルート：Enterprise Library 依存を段階的に外して MySQL 8.0 系へ進む
長期的に最も安全で、結果的にトラブル対応の総工数が減りやすいのがこのルートです。ポイントは“一気に書き換えない”こと。データアクセスはアプリの心臓部なので、段階的に置き換えるほうが成功率が高いです。
移行全体のロードマップ（おすすめの順番）
| フェーズ | やること | 成果物 | 失敗しないコツ |
|---|---|---|---|
| 準備 | DBアクセス箇所の棚卸し、テスト方針の決定 | 一覧、優先順位、影響範囲 | SQLの種類（参照/更新/トランザクション）で分類する |
| 土台 | .NET Framework を 4.8 へ（可能なら先に） | ビルド・デプロイが通る状態 | ライブラリ更新前に CI/発行手順を固める |
| 封じ込め | Repository/DAO のインターフェース化 | データアクセスの境界 | コントローラ/サービスのシグネチャを守る |
| 並走 | 新ドライバ＋ADO.NET/Dapper で新実装を追加 | 新旧2系統の実装 | 切替は機能単位、もしくはテーブル単位 |
| 切替 | 呼び出し先を新実装へ順次変更 | Enterprise Library 依存が縮小 | ログ/計測で差分を見える化する |
| 撤去 | Enterprise Library 設定と参照を削除 | 依存ゼロ | web.config の不要設定も同時に掃除 |
.NET Framework 4.8 へのアップグレードは、データアクセスの書き換えよりも影響範囲をコントロールしやすいことが多いので、可能なら先に済ませると後工程が楽になります（もちろん、環境や制約で順番を逆にしても構いません）。
データアクセスを「境界」で包む（ここが勝負所）
Enterprise Library を外すときに失敗する典型は、「コントローラやサービスが Enterprise Library の型を直に触っている」状態です。そうなっている場合、まずは境界を作ります。
例えば、ユーザー取得の処理が散らばっているなら、インターフェースを用意します。
public interface IUserRepository
{
User GetById(int id);
IReadOnlyList<User> Search(string keyword, int limit);
void Update(User user);
}既存実装（Enterprise Library 版）は、そのまま「旧実装」として残します。
public sealed class UserRepositoryEntLib : IUserRepository
{
private readonly Microsoft.Practices.EnterpriseLibrary.Data.Database _db;
public UserRepositoryEntLib(Microsoft.Practices.EnterpriseLibrary.Data.Database db)
{
_db = db;
}
public User GetById(int id)
{
using (var cmd = _db.GetSqlStringCommand("SELECT ... WHERE Id = @Id"))
{
_db.AddInParameter(cmd, "@Id", System.Data.DbType.Int32, id);
using (var reader = _db.ExecuteReader(cmd))
{
// mapping...
}
}
}
// Search / Update ...
}ここでの狙いは「上位層（Controller/Service）は IUserRepository しか知らない」状態にすることです。以降は、このインターフェースの裏側を差し替えるだけで移行できます。
新実装を追加する（ADO.NET 直書き or Dapper）
次に、新しい MySQL ドライバ（8.0 系相当）に合わせた実装を“追加”します。おすすめは、まずは ADO.NET 直書きか Dapper です。Entity Framework をいきなり導入すると設計変更が増えやすいので、レガシー脱却の第一歩としては軽量な方が進めやすいです。
ADO.NET での最小実装例
public sealed class UserRepositoryAdo : IUserRepository
{
private readonly string _connectionString;
public UserRepositoryAdo(string connectionString)
{
_connectionString = connectionString;
}
public User GetById(int id)
{
using (var conn = new MySql.Data.MySqlClient.MySqlConnection(_connectionString))
using (var cmd = conn.CreateCommand())
{
cmd.CommandText = "SELECT Id, Name, Email FROM Users WHERE Id = @Id";
cmd.Parameters.AddWithValue("@Id", id);
conn.Open();
using (var reader = cmd.ExecuteReader())
{
if (!reader.Read()) return null;
return new User
{
Id = reader.GetInt32(reader.GetOrdinal("Id")),
Name = reader.GetString(reader.GetOrdinal("Name")),
Email = reader.GetString(reader.GetOrdinal("Email"))
};
}
}
}
// Search / Update ...
}Dapper を使って移行のスピードを上げる例
public sealed class UserRepositoryDapper : IUserRepository
{
private readonly string _connectionString;
public UserRepositoryDapper(string connectionString)
{
_connectionString = connectionString;
}
public User GetById(int id)
{
using (var conn = new MySql.Data.MySqlClient.MySqlConnection(_connectionString))
{
const string sql = @"SELECT Id, Name, Email FROM Users WHERE Id = @Id";
return conn.QuerySingleOrDefault<User>(sql, new { Id = id });
}
}
// Search / Update ...
}SQL をそのまま活かせるため、「DB オブジェクトは変えない」「既存 SQL を大きくいじらない」要件と相性が良いです。
切替は“機能単位”で小さく進める
一番事故が少ないのは「新旧のリポジトリを両方作り、機能単位で切り替える」やり方です。切替方法は複数ありますが、現場で扱いやすいのは次の2つです。
- DI コンテナの設定で差し替える（開発/検証/本番で段階的に切替）
- 設定フラグで切替（問題が出たら即戻せる）
例：appSettings で切替するイメージ（疑似コード）
bool useNewRepo = ConfigurationManager.AppSettings["UseNewMySqlDriver"] == "true";
IUserRepository repo = useNewRepo
? (IUserRepository)new UserRepositoryDapper(connStr)
: (IUserRepository)new UserRepositoryEntLib(entLibDb);この“戻せる”仕組みがあると、移行中に見つかった差分（結果セットの微妙な違い、NULL の扱い、トランザクション境界）を安全に潰せます。
web.config の Enterprise Library 設定を徐々に減らす
データアクセスが新実装に置き換わっていくにつれ、web.config に残る Enterprise Library の設定は“使われない設定”になっていきます。ここは段階的に掃除しましょう。
<dataConfiguration>の defaultDatabase がまだ必要か- Enterprise Library の configurationSource 設定が残っていないか
- 古い接続文字列（旧 providerName）が残っていないか
- 不要な bindingRedirect が増殖していないか
最後にプロジェクト参照から Enterprise Library の DLL を外し、ビルドが通ることを確認します。
MySql.Data と MySqlConnector の選び方（「新しい MySQL ライブラリ」の現実解）
MySQL の .NET 向けドライバには代表的に次の選択肢があります。どちらを選ぶにせよ、重要なのは「Enterprise Library から独立した層に置く」ことです。
| 観点 | MySql.Data（Oracle 公式系） | MySqlConnector（コミュニティ系） | 選定の目安 |
|---|---|---|---|
| 位置づけ | 公式の Connector/NET 系 | 高互換・高機能を目指す実装 | 社内規定や調達要件があるなら公式寄りが選ばれやすい |
| 移行コスト | 既存が MySql.Data なら比較的低い | 名前空間・アセンブリ名が異なる | 今すでに MySql.Data ならまずは同系統で前に進めるのも手 |
| 保守性 | バージョン更新で依存が増えることがある | API 互換性と実運用の取り回しを重視しやすい | いずれにせよ「データアクセス層に閉じ込める」ことが最重要 |
結論としては、「どちらが正解」ではなく、上位層からドライバを見えなくする設計にしておけば、将来の差し替えも現実的になります。
MySQL サーバーも 8.0 に上げる場合の注意点（DB オブジェクトを極力変えないために）
「DB オブジェクトは変えない」方針でも、サーバーを 8.0 系へ上げると挙動差が出ることがあります。事前に“差分が出やすい点”だけ押さえると、移行がかなり楽になります。
| 差分が出やすい領域 | 症状例 | DB オブジェクトを変えずにできる対策 |
|---|---|---|
| 認証方式 | 接続時に認証エラーになる | ユーザーの認証プラグインや権限、接続文字列の設定を見直す |
| SQL モード | 今まで通っていたクエリがエラーになる | サーバー側の SQL モードを確認し、影響が大きい場合は段階的に調整 |
| 文字コード/照合順序 | 比較・並び順が変わる、検索の結果が変わる | 接続時の設定やアプリ側の想定を揃え、影響をテストで確認する |
| 日時・タイムゾーン | 日時の解釈がズレる | アプリの取り扱い（UTC固定など）を明確化し、接続文字列/設定を合わせる |
ここでのコツは、「本番データに近いデータ量・データ分布」で統合テストを回し、差分を先に見つけることです。SQL を変えたくないなら、なおさらテストで守る必要があります。
よくあるコンパイルエラー／実行時エラーと、切り分けの順番
「Enterprise Library 周りでコンパイルエラー」と一口に言っても、原因は大きく分けて2系統あります。先に切り分けをしておくと、遠回りを防げます。
切り分けの基本方針
- コンパイルエラー：参照や型が解決できていない（プロジェクト参照・NuGet・using・依存DLL）
- 実行時エラー：アセンブリの読み込み、プロバイダ登録、接続、TLS、認証、SQLの差
| 種類 | 例 | ありがちな原因 | 先にやること |
|---|---|---|---|
| コンパイル | 型/名前空間が見つからない | 古い MySQL 型に依存したコードが残っている、参照が二重化している | MySQL 固有型の使用箇所を検索し、抽象化（DbCommand など）へ寄せる |
| 実行時 | FileLoadException | bindingRedirect 不整合、依存 DLL 不足 | 実行フォルダの DLL を棚卸しし、redirect を整理 |
| 実行時 | プロバイダが見つからない | DbProviderFactories 未登録、providerName 不一致 | web.config の system.data/connectionStrings を見直す |
| 実行時 | 接続できない | 認証/TLS/サーバー設定差 | 同じ接続文字列で最小の疎通コードを作り、アプリ外で検証する |
移行時は「アプリ全体で試す」より、「最小の疎通コード（コンソール等）でドライバだけ検証」→「Repository 単位で組み込み」→「全体で切替」の順にすると、原因が潰しやすいです。
実務で効くチェックリスト（移行作業の抜け漏れ防止）
- Enterprise Library を呼んでいるクラスを “一覧化” したか（検索ワード：
Database/DbCommand/ExecuteReaderなど） - MySQL 固有型（
MySqlConnection/MySqlParameter/MySqlDbTypeなど）を上位層で触っていないか - 接続を作る場所を 1 箇所（Factory/Provider）に集約したか
- トランザクション境界が Enterprise Library 任せになっていないか（移行後も同じ粒度で張れるか）
- 例外ログに「SQL とパラメータ」が残るようにしているか（個人情報や機微情報はマスク）
- 本番相当データで統合テストを回せる環境を用意したか
- 切替方法（DI/フラグ/段階リリース）とロールバック手順を決めたか
まとめ：最短で安全に進めるなら「触らない」より「閉じ込めて置き換える」
Enterprise Library 6.5 を使った C# / ASP.NET MVC で MySQL 8.0 系ドライバへ更新する際、DLL の差し替えだけで完結させるのは難易度が高く、成功しても将来また同じ壁に当たりやすいのが実情です。
短期的にどうしても Enterprise Library を残したいなら、ODBC などの暫定策もあります。ただ、長期的にメンテしやすく、今後のセキュリティ更新やドライバ更新を“怖くない作業”にするには、データアクセス層をインターフェースで区切り、MySQL ドライバ（MySql.Data / MySqlConnector）＋ ADO.NET/Dapper へ段階的に置き換えていくのが現実的です。
最終的に Enterprise Library を外せる状態まで持っていければ、.NET Framework 4.8 への更新や MySQL 8.0 系への追従も、作業が「調査と祈り」ではなく「手順とテスト」で回るようになります。
コメント