Ошибка CS7038 (не удалось отправить модуль) только при редактировании и продолжении
Я отлаживаю приложение.NET 4.0 в Visual Studio 2015. Мое приложение собирается и работает нормально, но когда я пытаюсь редактировать и продолжать работу в режиме отладчика, независимо от того, какие изменения я делаю или где я делаю их в своем основном проекте Я получаю диалог, который говорит:
Были внесены изменения, которые не могут быть скомпилированы. Выполнение не может продолжаться, пока ошибки компилятора не будут исправлены.
В качестве примера такого рода изменений, о которых я говорю, я попытался добавить эту строку различными способами:
Console.WriteLine("foo");
Когда я смотрю в панели списка ошибок Visual Studio, я вижу только одну ошибку, CS7038, с описанием "Failed to emit module"<my app name>'."Не задано имя файла, номер строки или символ. В моем коде нет ворсистых красных подчеркиваний. Если я остановлю работающее приложение, соберу с изменениями и запустлю снова, все будет собираться и работать нормально. чтобы было некоторое расхождение между тем, что компилятор времени сборки и компилятор edit-and-continue считают приемлемым.
Кто-нибудь знает способ получить больше информации о том, почему компиляция не удается в режиме редактирования и продолжения? Я прочитал кое-что о подключении и отладке процесса VBCSCompiler, поэтому я попробовал это, но даже при всех типах исключений, настроенных на разрыв при выбросе, подключенный VS никогда не ломался.
Я не делюсь никаким кодом, потому что это не вопрос моего кода, а скорее стратегии определения того, что компилятор Edit и Continue считает неправильным, и, насколько я знаю, источник ошибки компилятора может быть где-нибудь в моем весь проект.
Редактировать:
Как уже упоминалось в комментариях, я смог подключить отладчик к Visual Studio и прервать работу при возникновении исключения после нажатия кнопки "Продолжить" после редактирования кода. Исключением был System.NotSupportedException со следующим сообщением: "Изменение версии сборки не допускается во время отладки". В нем было указано название рассматриваемой сборки, которая представляла собой небольшой проект VB.Net, используемый моим приложением, который в основном находится на C#. Я пытаюсь создать MCVE для отправки в Microsoft, но в настоящее время я не могу воспроизвести проблему в меньшем решении с одним VB и одним C# проектом.
Изменить 2:
Я нашел обходной путь и сам ответил на вопрос в случае, если кто-то еще сталкивался с этой странной проблемой, но я оставляю за собой галочку "Отвечено" для тех, кто может объяснить, что происходит (почему компилятор считает номер версии указанный проект изменился во время редактирования).
4 ответа
Я нашел обходной путь для этой проблемы, но я не до конца понимаю, что происходит. В проекте VB.NET, версия сборки которого, по словам компилятора "Редактировать и продолжить", изменялась, существовал файл "AssemblyInfo.vb". Этот файл содержал следующую строку:
<Assembly: AssemblyVersion("3.0.*")>
Версия сборки также может быть установлена в свойствах проекта с помощью кнопки "Информация о сборке" на вкладке "Приложение":
Когда я удалил AssemblyVersion строка из AssemblyInfo.vb, моя проблема "Редактировать и продолжить" исчезла. Сначала я думал, что это потому, что поля в окне информации о сборке были сохранены в файле, отличном от AssemblyInfo.vb, и между ними был какой-то конфликт, но теперь я вижу, что окно информации о сборке - это просто удобный способ редактирования AssemblyInfo..vb: если я удаляю строку в AssemblyInfo.vb, она очищается в окне информации о сборке.
После еще нескольких экспериментов выясняется, что звездочка в номере версии является виновником. Если я полностью укажу версию сборки, проблема "Редактировать и продолжить" исчезнет. И указанный проект должен быть проектом VB.NET. Я попробовал ту же самую установку с проектом C#, и я мог Редактировать и Продолжить очень хорошо.
Похоже, это очень сложный случай, и я отправлю отчет об ошибке в Microsoft, но пока я хотел бы узнать, что на самом деле происходит с компилятором - почему он получает две разные версии сборки сборка, которую действительно не нужно перекомпилировать во время отладки.... Если у вас есть хорошее объяснение того, что происходит, добавьте его в качестве ответа.
Изменить: вот отчет об ошибке, который я подал.
Это произошло со мной в приложении .net 4.8 с Visual Studio 2019.
У меня есть смешанные проекты vb и cs, здесь проблема возникает, когда vbproj ссылается на csproj, который использует оператор подстановки «*» для указания версии сборки.
Как прокомментировал выше @Wai-Ha-Hee, wildcast использует текущее время, я верю, что когда VS перестраивает приложение, чтобы применить внесенные вами изменения, версия сборки изменяется, вызывая ошибку.
В файле AssemblyInfo (проект присутствует с ошибкой) Изменить:
[assembly: AssemblyVersion("1.0.*")]
К:
[assembly: AssemblyVersion("1.0.0.0")]
Это решило для меня.
Важно отметить, что использование wildcast '*' делает сборку недетерминированной, это означает, что каждая сборка создает другую сборку. Это считалось плохой практикой, поскольку при сборке исходного кода в одних и тех же условиях создаются разные сборки.
В Visual Studio 2019:
Новый csproj/vbproj с файлом проектов в стиле, отличном от SDK, создается с помощью:
<Deterministic>true</Deterministic>
И новый csproj/vbproj с файлом проектов в стиле Sdk опускает эту строку, но также предполагает детерминированность по умолчанию.
Я рекомендую рассмотреть другие способы версии сборки.
Подробнее о детерминированном:
http://blog.paranoidcoding.com/2016/04/05/deterministic-builds-in-roslyn.html
https://reproducible-builds.org/
Случилось со мной на VS2019 в проекте csharp .NETFW 4.8 (и в решении не было другого проекта). Ни один из предыдущих ответов на этой странице мне не помог. Для меня исправление — удалить эту строку в файле .csproj:
<Compile Include="Properties\AssemblyInfo.cs" />
Одним из моих проектов C# в смешанном решении был .NET Framework 2.0 (в то время как другие — и C#, и VB.NET — были .NET Framework 4). После того, как я изменил его на .NET Framework 4, он начал работать.