Q&A
要は，「共通モジュールのdll」の変更の仕方次第では
その dll ファイルを差し替えるだけで（既存のexeはリビルドせずとも）済むハズなのだが，そのようにできる「変更の仕方」の範囲とは何か？
……みたいな話なんでしょうか．
その dll が外側に対して見せている部分に一切の変更が無いならば大丈夫…なんじゃないかな……とか思っていたのですが，どうやらそうじゃない感じだという話ですか？
前提
VisualStudio2017で共通モジュールのdllとそれを使用したexeを作成しました。
exeは複数あり、新規に作成もします。
その過程で、共通モジュールを更新したりするのですが、
前回までのビルドの共通モジュールでビルドしたexeに不具合が生じることがあります。
エラー内容はまちまちなのですが、
あるはずのカラム名がない、SQLのパラメータ名が不正などのエラーであることが多いです。
（おそらくそれは、共通モジュールがSQL関連のものであるため）
もちろん最新ビルドで追加したパラメータやカラム名ではありません。
最新ビルドで変更した内容は既に使用しているクラス、関数の変更等ではなく、
新規に関数の追加やEnum項目、変数の追加等です。
上記のエラーはそのままexeをリビルドすると改善されます。
共通モジュールを修正した場合、修正内容にかかわらず、
使用しているexeはすべてリビルドすべきなのでしょうか。
個人的には、既に使用しているexeに影響がある内容（例えば、関数の戻り値の型変更や引数の追加等・・・）でない限り、
最新のdllを見るものだと思っていました。
リビルドすれば改善することから、参照というのはパスだけを見ているのではないのか？と思っています。
ただ、アセンブリ情報でバージョン管理をしているわけではないので、
タイムスタンプ等を見ているのか？という感じなのですが・・・。
試したこと
参照モジュールのプロパティは、
エイリアス：global
ローカルにコピー、相互運用型の埋め込み、特定バージョン：すべてFalse
この辺りが怪しいのでは？と上司に言われ調べてはいます。
あまりピンとは来ていません。
補足情報（FW/ツールのバージョンなど）
VisualStudio2017
C# .Net Framework 4.6
SQLServer2019
また、とある売上管理ソフトの連携APIを使用しています。
回答次第ではこの辺りも調査が必要かと思っています。
そうですそうです。
言ってしまえばコンパイルエラーが起きるレベルの変更(既に使っている関数の名称を変えたり引数を変えたり）でなければ、exe側のリビルドは不要or設定次第で不要になるのではと期待を込めた質問でした。
舐めてました。
> 言ってしまえばコンパイルエラーが起きるレベルの変更(既に使っている関数の名称を変えたり引数を変えたり）でなければ、exe側のリビルドは不要or設定次第で不要になるのではと期待を込めた質問でした。
バイナリ互換性の話なんですよね？
[互換性 - .NET | Microsoft Learn](https://learn.microsoft.com/ja-jp/dotnet/core/compatibility/categories#binary-compatibility)
思ったよりも広範に制限や、できることがありますね（どっちの感想かは人によるか？^^;
[互換性に影響を与える .NET API の変更点 - .NET | Microsoft Learn](https://learn.microsoft.com/ja-jp/dotnet/core/compatibility/library-change-rules)
シリアル化・リフレクション等が絡んでくると、さらにややこしいことになります。
自分では使用していなくても、思わぬところで使われている可能性があります。
わたしは特に知見はありません^^;
公式ドキュメントのご教示ありがとうございます。
恐らくこのような情報が必要でした・・・
許容される範囲はあるんですね。
パッと見これが原因でバグった！となる箇所は見つけられなかったのですが、
仰られるように思わぬところで・・・かもしれません。
もう少し自分でも勉強してみます。ありがとうございます！
回答2件
0
こんにちは。
質問は既に解決となっていますが、気になる点があるため回答として残しておきます。
まず、基本的に exe は依存している dll が変更された場合には再ビルドした方が良いのは間違いないです。
その上で、今回問題の原因となっているのは、
「共通モジュール」と言っている巨大な依存関係が存在している点にあります。
モジュールとは例えると道具箱のようなものですが、一つの「共通モジュール」を作成するということは、一つの巨大な道具箱に工具と調理器具と清掃用具と筆記用具と計算機を全て入れているようなものです。
これらの、それぞれ領域の異なる道具は、それぞれが別の道具箱、すなわち別のモジュールになっているべきなのです。
一つの巨大な道具箱を使っている場合、料理人は調理器具しか使っていないにも関わらず、清掃用具が変更されたら工具箱を新しいものに取り替えなければいけません。
この料理人が工具箱を取り替える必要があるのは、「調理器具が変更された場合」に限られるはずです。
すなわち各 exe は、共通部品の中でも「自分が本当に必要としているもの」だけを持っていれば良かったのです。
そのために、一つの「共通モジュール」は領域ごとに分割された多数の「共通モジュール」の形になっている必要があったわけです。
依存している dll が変更されたら exe も再ビルドを行うルールであっても、
共通モジュールが適切に分割されていれば、その中の特定のモジュールを変更したとき、そのモジュールをそもそも利用していない exe は再ビルドされることもなくなり、共通モジュールの差し替えという作業を行う必要もなくなるわけです。
長年アンチパターンとして知られている一つの共通モジュールという考え方ですが、何故かどこにでも存在しています。
「共通化」という目的を達成するのに一番早い手段であるため発生しやすいのですが、一度作られてしまうと後に分解するのが困難になり、だんだん複雑性が増し、負債として大きくなっていきます。
というわけで、実際に「正しい」解決手段はこれなのですが、
これを今から実施するには多大な労力が発生する上、手に負えないレベルで複雑化していることもあるため、諦めるしかない場合もあります。
今後の成果物の納品時に毎回積み重なる手間と比較して、どちらを取るべきかで判断するのが良いと思います。
もし、今後全く新しいプロジェクトを立ち上げる状況があれば、「共通モジュール」の作成は思い止まった方が良いですね。
投稿2025/01/31 12:00
総合スコア4254
回答ありがとうございます。
「負債」というのは本当にそうで、社内の代々受け継がれてきた共有モジュールでもあります。
（中身自体はプロジェクトによってめちゃくちゃ変更しないといけません。）
では今まで発生しなかったのか？というと、
これは推測なのですが現在絶賛VB.net→C#への移行中でして・・・
VBでは発生しなかった何かがc#では起こっているのかもしれません。
今後c#の移行を進めるにあたり絶対に見直すべき箇所だなと思ったのですが、
それを設計できるほどの技量が私にあるかというと・・・不安です。
とにかく勉強します！ありがとうございました。
0
ベストアンサー
C#のプロジェクトはdllを単体では管理せず、いくつかのプロジェクトファイルとセットで取り扱います
プロジェクトの状態が変化すればdllと連携されるファイルの内容も更新されます
以前に生成された実行ファイルは以前のプロジェクトの状態を参照するので、最新のプロジェクトで正常に動作する保障はありません
解決策としては、共有モジュールをクラスライブラリとして別プロジェクトから参照するか、C#7.0以前のバージョンで書き直してdllを単体で生成するかになります
いずれも手間を要するのでリビルドの方が単純でしょう
投稿2025/01/30 04:18
編集2025/01/30 04:19
総合スコア93
設定などでどうにかなる問題ではないのですね。
新規exe追加納品時に他exeも全ビルドして納品・・・となると骨が折れますが
余計なトラブルよりましなので仕方ないです。
回答ありがとうございました！
あなたの回答
tips
プレビュー
