При отладке я получаю это при использовании Watch: Внутренняя ошибка в компиляторе C#

Question

Я очень счастливо работал над приложением в VS2017. Отладка просто отлично. Затем, внезапно...

Когда я отлаживаю и пытаюсь навести курсор на переменную, я не получаю обычное всплывающее окно с подробной информацией об объекте. И если я положу его в часы, я получу это значение:

Внутренняя ошибка в компиляторе C#

Я закрыл и заново открыл VS, затем я перезагрузился. Тем не менее получить ту же ошибку.

Там очень мало об этом там. Кто-нибудь когда-нибудь видел это раньше?

Answer 1

Нашел ответ здесь, который работал:

Пожалуйста, просмотрите меню Инструменты-> Параметры> Отладка> Включить Использовать режим управляемой совместимости, а затем отладьте файл дампа, как насчет результата?

Понятия не имею, почему это работает, а затем вдруг остановился. Но теперь он снова работает.

Answer 2

В моем случае это было связано с динамической загрузкой сборки.

Проблема появится только после того, как отладчик перешагнет вызов методаAssembly.LoadFrom(...)метод, который пытался загрузить сборку с тем же именем, что и у сборки в контексте загрузчика сборок.

Я исправил проблему, проверив, была ли сборка, которую собирались загрузить, уже в контексте загрузчика сборки. Если бы это было так, сборка была бы пропущена.

Грубый код моего решения:

      // Load the assembly to the reflection context to check for any conflicts in the assembly load context
Assembly assembly = Assembly.ReflectionOnlyLoadFrom(assemblyPath);
AssemblyName assemblyName = assembly .GetName();

List<AssemblyName> existingAssemblies = AppDomain.CurrentDomain
    .GetAssemblies()
    .Select(assembly => assembly.GetName())
    .Where(x => x.Name == assemblyName.Name && x.Version.ToString() != assemblyName.Version.ToString())
    .ToList();

if (existingAssemblies.Any())
{
    // Skip the assembly if there are already assemblies with the same name but a different version
    return;
}
else
{
    // Load the assembly into the assembly loader context
    assembly = Assembly.LoadFrom(assemblyPath);
}

Использованная литература:

Странное поведение при программной загрузке сборок и их зависимостей

https://github.com/dotnet/runtime/issues/10859

https://github.com/dotnet/roslyn/issues/19257

Answer 3

Я также сталкиваюсь с этой проблемой сразу после следующего кода:

      AssemblyBuilder assemblyBuilder = AssemblyBuilder.DefineDynamicAssembly(assembly, AssemblyBuilderAccess.RunAndCollect);

В конце концов я понял, что это происходит только при передаче исполняемой сборки (которая получена вызовом Assembly.GetExecutingAssembly()). Я предполагаю, что компилятор не знает, как отлаживать исполняемую сборку в таком случае (возможно, потому, что это вызывает конфликт между этими сборками).

Решение: не используйте исполняющую сборку

Answer 4

Я столкнулся с этой проблемой при использовании VS2022 и не хотел ее удалять. Я попытался перезапустить VS, но безрезультатно.

Я решил свою проблему, удалив все временные файлы в моем репо, используя следующую команду git (в корне репо):

      git clean -fdx

Эта команда сбрасывает репозиторий в неизмененное состояние, сохраняя измененные файлы (неустановленные изменения будут потеряны, вы были предупреждены!)

Вы также могли бы просто удалить папку .vs/ и все временные папки bin/ и obj/, но мне показалось, что проще использовать команду git (пользователям TFVC придется выполнять очистку вручную!).

Answer 5

Я столкнулся с этим с веб-проектом в VS2022, откатился к VS2019, включил управляемый режим совместимости, но ошибка все еще была. Оказалось, это был просто мой вонючий код.

      var assembly = AssemblyName.GetAssemblyName(Assembly.GetExecutingAssembly().Location);
var appDomain = System.Threading.Thread.GetDomain();
var assemblyBuilder = appDomain.DefineDynamicAssembly(assembly, AssemblyBuilderAccess.Run);

У меня было это в процедуре запуска. Как только отладчик попадает в эту третью строку кода, я начинаю получать сообщение об ошибке. Я могу проверять переменные вплоть до этой строки.

Answer 6

Для меня это было расширение, которое я недавно включил. Отключение и перезапуск помогли.

Answer 7

Я тоже столкнулся с этой проблемой.

Оказывается, у меня было два оператора using, которые определяли тип из определенного пространства имен.

      using Type = namespaces.Type;

namespace namespaces
{
   using Type = otherNamespace.Type;
   ...
}

Это, вероятно, редкое явление в мире за пределами моей компании, но если вы сталкиваетесь с этой ошибкой, об этом следует подумать.