11

Visual Studio 2015 で .NET 4.0 アプリケーションをデバッグしています。アプリケーションは正常にビルドおよび実行されますが、デバッガーで実行中に編集して続行しようとすると、どのような変更を加えたか、またはメイン プロジェクトのどこでそれらを行ったかに関係なく、 、次のようなダイアログが表示されます。

コンパイルできない編集が行われました。コンパイラ エラーが修正されるまで、実行を続行できません。

私が話している種類の変更の例として、さまざまな方法で次の行を追加しようとしました。

Console.WriteLine("foo");

Visual Studio の [エラー一覧] ペインを見ると、「モジュール ' ' を発行できませんでした」という説明が付いたエラー CS7038 が 1 つだけ表示されます<my app name>。ファイル名、行番号、または文字は指定されません。私のコードには赤い波線がありません。実行中のアプリケーションを停止し、変更を加えてビルドし、再度実行すると、すべてが正常にビルドおよび実行されます。そのため、ビルド時コンパイラとエディット コンティニュ コンパイラが許容できると見なすものの間には、多少の不一致があるようです。

エディット コンティニュ モードでコンパイルが失敗する理由に関する詳細情報を取得する方法を知っている人はいますか? VBCSCompiler プロセスへのアタッチとデバッグについて何かを読んだので、それを試してみましたが、スローされたときにすべての例外の種類が壊れるように設定されていても、アタッチされた VS が壊れることはありませんでした。

これは私のコードに関する質問ではなく、エディット コンティニュ コンパイラが間違っていると考えていることを見つけるための戦略に関するものであるため、コードを共有していません。プロジェクト全体。

編集:

コメントで述べたように、Visual Studio にデバッガーをアタッチし、コードの編集後に [続行] をクリックして例外がスローされたときにブレークすることができました。例外は、System.NotSupportedException「デバッグ中にアセンブリ参照のバージョンを変更することはできません」というメッセージを伴うものでした。問題のアセンブリの名前がリストされていました。これは、ほとんどが C# である私のアプリケーションで使用される小さな VB.Net プロジェクトでした。Microsoft に提出する MCVE を構築しようとしていますが、現在、1 つの VB と 1 つの C# プロジェクトだけの小規模なソリューションで問題を再現することはできません。

編集2:

他の誰かがこの奇妙な問題に遭遇した場合に備えて、回避策を見つけて質問に自己回答しましたが、何が起こっているのかを説明できる人のために「回答済み」チェックマークを予約しています (なぜコンパイラがバージョン番号を編集中に参照プロジェクトが変更されました)。

4

3 に答える 3

5

問題の回避策を見つけましたが、何が起こっているのか完全には理解していません。エディット コンティニュ コンパイラがアセンブリ バージョンが変更されていると言った VB.NET プロジェクトには、"AssemblyInfo.vb" というファイルがありました。そのファイルには次の行が含まれていました。

<Assembly: AssemblyVersion("3.0.*")>

アセンブリ バージョンは、[アプリケーション] タブの [アセンブリ情報] ボタンを使用して、プロジェクト プロパティでも設定できます。

AssemblyVersion が 2 つの場所に設定された VB.NET プロジェクトの Visual Studio のプロジェクト プロパティのスクリーンショット

AssemblyInfo.vb からこの行を削除するAssemblyVersionと、エディット コンティニュの問題が解消されました。最初は、アセンブリ情報ウィンドウのフィールドが AssemblyInfo.vb とは別のファイルに保存されており、両者の間に競合があったためだと思っていましたが、アセンブリ情報ウィンドウは AssemblyInfo を編集するための便利な方法であることがわかりました。 .vb: AssemblyInfo.vb の行を削除すると、[アセンブリ情報] ウィンドウでクリアされます。

さらに実験を重ねた結果、バージョン番号のアスタリスクが原因であることがわかりました。アセンブリのバージョンを完全に指定すると、エディット コンティニュの問題がなくなります。また、参照されるプロジェクトは VB.NET プロジェクトである必要があります。C# プロジェクトで同じセットアップを試してみたところ、エディット コンティニュは問題なく実行できました。

これは非常にまれなケースのようです。Microsoft にバグ レポートを提出しますが、それまでの間、コンパイラで実際に何が起こっているのかを知りたいと思っています。デバッグ中に再コンパイルする必要のないアセンブリ....何が起こっているのかについての良い説明がある場合は、回答として追加してください。

編集ここに私が提出したバグレポートがあります。

于 2016-12-29T15:55:11.750 に答える
1

これは、Visual Studio 2019 を使用した .net 4.8 アプリで発生しました。

vb プロジェクトと cs プロジェクトが混在しています。ここで、vbproj が、ワイルドキャスト演算子 '*' を使用してアセンブリのバージョンを指定する csproj を参照すると、問題が発生します。

上で @Wai-Ha-Hee がコメントしたように、ワイルドキャストは現在の時刻を使用します。VS がアプリケーションを再構築して、行った編集を適用すると、アセンブリのバージョンが変更されてエラーが発生すると思います。

assemblyInfo ファイル (エラーで存在するプロジェクトの) で変更:

[assembly: AssemblyVersion("1.0.*")]

に:

[assembly: AssemblyVersion("1.0.0.0")]

それは私のために解決しました。

重要なことは、ワイルドキャスト '*' を使用すると、アセンブリが非決定論的になります。つまり、ビルドごとに異なるアセンブリが生成されるということです。これは、同じ条件でソース コードをビルドすると異なるアセンブリが生成されるため、不適切な方法と見なされてきました。

Visual Studio 2019 の場合:

SDK 以外のスタイルのプロジェクト ファイルを含む新しい csproj/vbproj は、次のように生成されます。

<Deterministic>true</Deterministic>

また、Sdk スタイルのプロジェクト ファイルを使用した新しい csproj/vbproj ファイルでは、この行が省略されていますが、デフォルトとして決定論的であると想定されています。

アセンブリをバージョン管理するための他の方法を検討することをお勧めします。

決定論の詳細:
http://blog.paranoidcoding.com/2016/04/05/deterministic-builds-in-roslyn.html
https://reproducible-builds.org/

于 2021-01-20T13:28:13.270 に答える
0

One of my C# projects in a mixed solution was .NET Framework 2.0 (while others - both C# and VB.NET - were .NET Framework 4). After I changed it to .NET Framework 4 it began to work.

于 2022-02-22T14:13:53.457 に答える