Неправильный указатель visual studio
Visual Studio (и, возможно, TFS) каким-то образом (я думаю, возможно, во время слияния с исходным кодом) запутался в пути проекта в моем решении.
Он думает, что это здесь (пример пути для простоты):
а на самом деле, файл проекта находится здесь:
Я не могу для жизни меня заставить его признать правильное местоположение. Я пробовал:
редактирование вручную .sln файл для обеспечения всех ссылок на ExampleProjectCorrect.csproj есть правильные пути.
выполнение поиска в файлах в каталоге решения как для правильных, так и для неправильных путей, чтобы попытаться отследить, где studio скрывает неправильный путь.
удаление каталогов кэша для VS и TFS
я разрываю свои волосы, потому что я не могу воссоздать решение, поскольку оно имеет около 100 проектов и связано с управлением версиями с несколькими другими разработчиками, работающими над ним.
может ли кто-нибудь указать мне в правильном направлении, где он хранит этот неправильный путь и/или как сбросить его, чтобы проклятая вещь загрузилась правильно?
- на Управление Рабочими Областями (либо через меню File/Source Control, либо в раскрывающемся списке workspace в Проводнике управления версиями)
- выберите редактировать для вашего рабочего пространства.
- вы должны увидеть, в разделе рабочие папки, сопоставление для источника управление каталогом в старый / неправильный каталог проекта.
- выберите его и нажмите удалить.
- закрыть VS и удалить файл suo.
просто удаление решений .suo файл работал на меня.
Я столкнулся с этой проблемой после выполнения миграции из Visual Source Safe 2005 в TFS 2012. Я не мог дождаться "мастера преобразования" в ближайшие пару недель, поэтому я просто запустил VSSConvert.исполняемый. Это заняло 6 или около того лет истории и переместило его в TFS.. хотя я не получил фактическую историю временной шкалы.. Я получил кучу записей в тот же день с комментариями, указывающими на фактические проверки истории.. не плохо.
Так что после того, как он бежал всю ночь (успешно, ура!), У меня возникли проблемы с загрузкой моих проектов так же, как этот вопрос заявил. По какой-то причине несколько проектов ссылались на неверный каталог. Я проверил .sln, the .файлы vsproj и получение последних, удаление повторного получения, добавление удаления и т. д.. Я попробовал все, что здесь отмечено. даже обновление моего рабочего пространства, которое я не уверен, что это даже сделало.
наконец-то. Я удалил *.СУО файлы и Виола. Это сработало.
Я потратил пару часов на вот этот.
немного другое решение.
TFS отображал несуществующий путь для конкретного решения. Раньше у меня был ноутбук с отдельным диском D:, но теперь у меня просто есть диск C:. TFS все еще думал, что мой проект был сохранен D:\Project\MikesProject
у меня нет .suo файл для удаления, D: path не упоминается в любом месте моего рабочего пространства (похоронен под File\Source Control\Advanced\Workspaces меню), TFS показал, что у меня есть последние файлы в моем (больше не существует) D: каталог и TFS в VS2013 не имели опции "удалить сопоставления" для этого проекта.
а то сделал работа заключалась в том, чтобы просто сделать "получить последнюю версию" в проекте.
после этого на мой диск C: была записана новая копия кода, и (интересно) теперь был показан локальный путь подчеркнутый.
ранее путь D: не был показан таким образом.
странно. Очень странный.
У нас были подобные проблемы с перемещениями и переименованиями. Удаление локальных каталогов, а затем получение снова решили его.
Попробуйте удалить или переименовать .файл suo (включая расширение). Этот файл находится в том же месте, где находится файл решения. Это сработало для меня.
просто догадываюсь, но, возможно, некоторые из ваших других проектов ссылаются на ваш проект из неправильного места? В этом случае вам нужно не просто удалить и повторно вставить проект в ваше решение, вам также придется удалить и воссоздать ссылки из ссылочных проектов (сохраненных в их .файлов csproj).
после попытки многих рекомендаций я удалил файл suo ( снова ). Последний раз сработало. Почему это не сработало раньше я не знаю. В общем, я считаю удаление файла suo одним из первых шагов, которые я делаю.
в моем случае я скопировал *.sln файл в папку проекта и изменил путь к проекту в *.sln файл. Только это решило проблему (против 2015 с пакетом обновления 1, проект winservise).
удалить *.СУО не помогает мне.
Если вы используете свое веб-приложение под локальным IIS вместо IISExpress, убедитесь, что вы нажали кнопку "создать виртуальный каталог", перейдя в свойства проекта. Как только это будет сделано, выполните "чистое решение" и "перестроить решение".
Я знаю, что это старая линия. Я только что прошел через ту же проблему. Недавно мы перенесли TFS, поэтому я создал новую рабочую область для сопоставления с новым сервером и сохранил старый. Каждый раз, когда я открываю решение, которое должно быть нацелено на мою новую рабочую область, VS всегда пытался загрузить проекты из моего старого каталога сопоставления, пока я не удалил свою старую рабочую область.
Если ваше приложение пытается использовать неработающую ссылку, создается ошибка исключения. Неспособность найти компонент, на который указывает ссылка, является явным признаком ошибки, однако есть несколько ситуаций, в которых ссылка считается нерабочей. Эти варианты показаны в приведенном ниже списке:
Неверный или неполный путь для ссылок проекта.
Файл, на который указывает ссылка, удален.
Файл, на который указывает ссылка, переименован.
Сбой подключения к сети или проверки подлинности.
Ссылка указывает на COM-компонент, который не установлен на данном компьютере.
Ниже приведены способы устранения этих проблем.
Ссылки на файлы в сборках задаются по абсолютным путям в файле проекта. Таким образом, в локальном окружении пользователей, работающих с несколькими разработчиками, может отсутствовать сборка, на которую указывает ссылка. Чтобы избежать этих ошибок, в таких случаях лучше добавлять ссылки между проектами. Дополнительные сведения см. в разделе Программирование с использованием сборок.
Неправильный путь для ссылок
Если проекты используются совместно на разных компьютерах, некоторые ссылки могут быть не найдены, если компонент находится на этих компьютерах в разных папках. Ссылки сохраняются под именем файла компонента (например, MyComponent). Когда в проект добавляется ссылка, расположение папки для файла компонента (например, C:\MyComponents) добавляется к свойству проекта ReferencePath.
Чтобы устранить эту проблему, можно удалить неработающую ссылку и заменить в диалоговом окне Добавление ссылки. Другое решение заключается в том, чтобы использовать элемент Путь для ссылок на страницах свойств проекта и изменить папки в списке, указав правильное расположение. Свойство Путь для ссылок сохраняется для каждого пользователя на каждом компьютере. Таким образом, изменение пути для ссылок не затрагивает других пользователей проекта.
Ссылки между проектами лишены подобных проблем. Поэтому по мере возможности следует использовать их вместо ссылок на файлы.
Исправление неработающей ссылки проекта с помощью исправления пути для ссылок
В обозревателе решений щелкните правой кнопкой мыши узел проекта и выберите пункт Свойства.
Открывается конструктор проектов.
Если вы используете Visual Basic, выберите страницу Ссылки и нажмите кнопку Пути для ссылок. В диалоговом окне Пути для ссылок введите путь к папке с элементом, на который нужно сослаться, в поле Папка, а затем нажмите кнопку Добавить папку.
Файл, на который указывает ссылка, удален.
Вполне возможно, что файл, на который указывает ссылка, был удален и больше не существует на диске.
Исправление неработающей ссылки проекта для файла, который больше не существует на диске
Если ссылка находится в другом расположении на компьютере, считайте ее оттуда.
Файл, на который указывает ссылка, переименован.
Файл, на который указывает ссылка, мог быть переименован.
Исправление неработающей ссылки, указывающую на переименованный файл
Удалите ссылку, а затем добавьте ссылку на переименованный файл.
Если ссылка находится в другом расположении на компьютере, нужно считать ее оттуда.
Сбой подключения к сети или проверки подлинности
Недоступность файлов может быть вызвана несколькими возможными причинами, например ошибкой сетевого соединения или ошибкой проверки подлинности. В каждом отдельном случае могут использоваться уникальные средства восстановления. Например, вам может потребоваться обратиться к локальному администратору для получения доступа к необходимым ресурсам. Однако удаление ссылки и изменение использующего ее кода работает всегда.
На компьютере не установлен COM-компонент.
Эта ошибка возникает, когда компоновщику не удается открыть файл для чтения или записи. Ниже перечислены две наиболее распространенные причины этой проблемы.
Программа уже запущена или загружена в отладчике, и
пути к библиотеке неверны или не заключены в двойные кавычки.
Существует множество других возможных причин этой ошибки. Чтобы сократить их, сначала проверьте Тип файла. Затем используйте следующие разделы для выявления и исправления конкретной проблемы.
Не удается открыть приложение или его PDB-файл
Приложение выполняется или загружается в отладчике
Если filename — имя исполняемого файла или связанный с ним PDB-файл, см. раздел Если приложение уже запущено. Затем проверьте, загружен ли он в отладчик. Чтобы устранить эту проблему, перед повторным созданием программы закройте программу и выгрузите ее из отладчика. Если приложение открыто в другой программе, например в редакторе ресурсов, закройте его. Если программа не отвечает, может потребоваться завершить процесс с помощью диспетчера задач. Также может потребоваться закрыть и перезапустить Visual Studio.
Приложение заблокировано антивирусным сканированием
Антивирусные программы часто временно блокируют доступ к вновь созданным файлам, особенно .exe и .dll исполняемые файлы. Чтобы устранить эту проблему, попробуйте исключить каталоги сборки проекта из антивирусного сканера.
Не удается открыть файл библиотеки Майкрософт
Windows библиотеки, например kernel32. lib
Если файл, который не удается открыть, является одним из стандартных файлов библиотеки, предоставляемых корпорацией Майкрософт, например kernel32. lib, может возникнуть ошибка конфигурации проекта или ошибка установки. убедитесь, что Windows SDK установлен. если для проекта требуются другие библиотеки майкрософт, такие как MFC, убедитесь, что компоненты MFC также установлены установщиком Visual Studio. Вы можете снова запустить установщик, чтобы добавить дополнительные компоненты в любое время. Дополнительные сведения см. в Изменение Visual Studio. Используйте вкладку отдельные компоненты в установщике, чтобы выбрать конкретные библиотеки и пакеты SDK.
Библиотеки vcruntime с отслеживанием версий
Библиотеки для розничной торговли, отладки или конкретной платформы
Эта ошибка может возникнуть при первой сборке для новой целевой платформы или конфигурации, например в розничной торговле или ARM64. в интегрированной среде разработки проверьте, установлены ли набор инструментов платформы и Windows SDK версии , указанной на странице свойств общие . также убедитесь, что необходимые библиотеки доступны в каталогах библиотек , указанных на странице свойств каталоги VC++. Проверьте свойства каждой конфигурации, например Debug, Retail, x86 или ARM64. Если одна сборка работает, но другая нет, Сравните параметры обоих параметров. Установите все отсутствующие необходимые инструменты и библиотеки.
Библиотека vccorlib. lib
Библиотеки в проектах из сетевых или других источников
При построении проекта, скопированного с другого компьютера, расположения установки библиотеки могут отличаться. Для сборок из командной строки убедитесь, что для сборки правильно заданы пути к переменной среды LIB и библиотеке. в Visual Studio можно просмотреть и изменить текущие пути к библиотекам, заданные на страницах свойств проекта. на странице VC++ каталоги выберите элемент управления "раскрывающийся список" для свойства каталоги библиотек , а затем нажмите кнопку изменить. В разделе вычисленное значение диалогового окна каталоги библиотек перечислены текущие пути поиска файлов библиотек. Обновите эти пути, чтобы они указывали на локальные библиотеки.
обновленные библиотеки Windows SDK
Не удается открыть сторонний файл библиотеки
Существует несколько распространенных причин этой проблемы.
Путь к файлу библиотеки может быть неверным или не заключен в двойные кавычки. Или, возможно, вы не указали его для компоновщика.
Возможно, вы установили 32-разрядную версию библиотеки, но при этом собираетесь на 64 бит или наоборот.
Библиотека может зависеть от других библиотек, которые не установлены.
Может потребоваться предоставить каталог библиотеки, переопределяющий каталог стандартной библиотеки. В командной строке используйте параметр /libpath . В интегрированной среде разработки используйте свойство Дополнительные каталоги библиотек на странице свойств " Общие" компоновщика > свойств > конфигурации для проекта.
Убедитесь, что установлены все версии библиотеки, необходимые для создаваемых конфигураций. воспользуйтесь программой управления пакетами vcpkg , чтобы автоматизировать установку и настройку для многих распространенных библиотек. По возможности лучше создавать собственные копии сторонних библиотек. Затем вы убедитесь, что все локальные зависимости библиотек созданы для тех же конфигураций, что и ваш проект.
Не удается открыть файл, созданный проектом
Эта ошибка может возникать, если файл filename еще не существует, когда компоновщик пытается получить к нему доступ. Это может произойти, когда один проект зависит от другого в решении, но проекты создаются в неправильном порядке. Чтобы устранить эту проблему, убедитесь, что ссылки проекта заданы в проекте, который использует этот файл. После этого отсутствующий файл будет создан до того, как он потребуется. дополнительные сведения см. в статьях добавление ссылок в проекты Visual Studio C++ и управление ссылками в проекте.
Не удается открыть файл "К:\програм.ОБЖ"
Чтобы устранить эту проблему для сборок из командной строки, проверьте параметры параметра /libpath . Также проверьте пути, указанные в переменной среды LIB, и пути, указанные в командной строке. Обязательно используйте двойные кавычки для всех путей, содержащих пробелы.
Чтобы устранить эту проблему в интегрированной среде разработки, при необходимости добавьте двойные кавычки для следующих свойств проекта:
свойство каталоги библиотеки на странице свойств конфигурации > VC++ каталоги
Свойство " Дополнительные каталоги библиотек " на странице свойств " Общие" компоновщика > свойств > конфигурации
Свойство Дополнительные зависимости на странице свойств входных данных компоновщика > свойств > конфигурации .
Другие распространенные проблемы
Проблемы с путями или именами файлов
Параллельная синхронизация сборок
если вы используете параллельный вариант сборки, Visual Studio мог заблокировать файл в другом потоке. Чтобы устранить эту проблему, убедитесь, что один и тот же объект кода или библиотека не встроены в несколько проектов. Используйте зависимости сборки или ссылки проекта, чтобы выбрать в проекте созданные двоичные файлы.
Дополнительные зависимости, указанные в интегрированной среде разработки
При указании отдельных библиотек в свойстве Дополнительные зависимости используйте пробелы для разделения имен библиотек. Не используйте запятые или точки с запятой. При использовании пункта меню Правка для открытия диалогового окна Дополнительные зависимости используйте символы новой строки для разделения имен, а не запятых, точек с запятой или пробелов. Также используйте символы новой строки при указании путей к библиотекам в папках библиотек и дополнительных каталогах библиотек .
Слишком длинные пути
Эта ошибка может появиться, когда путь к файлу расширяется до 260 символов. При необходимости измените структуру каталогов или Сократите имена папок и файлов, чтобы сократить пути.
Слишком большие файлы
Эта ошибка может возникать из-за слишком большого размера файла. Библиотеки или объектные файлы, размер которых превышает гигабайт, может вызвать проблемы для 32-разрядного компоновщика. Возможным исправлением этой проблемы является использование 64-разрядного набора инструментов. Дополнительные сведения о том, как использовать 64-разрядный набор средств в командной строке, см. в разделе как включить 64-разрядный Visual C++ набор инструментов в командной строке. сведения о том, как использовать 64-разрядный набор инструментов в интегрированной среде разработки, см. в разделе использование MSBuild с 64-разрядным компилятором и инструментами. также см. статью Stack Overflow post: как сделать Visual Studio использовать собственную цепочки инструментов amd64.
Неправильные разрешения для файла
Эта ошибка может возникать, если у вас недостаточно разрешений для доступа к файлу filename. Это может произойти, если для доступа к файлам библиотеки в защищенных системных каталогах используется обычная учетная запись пользователя. Или, если вы используете файлы, скопированные с других пользователей, у которых все еще есть исходный набор разрешений. Чтобы устранить эту проблему, переместите файл в каталог проекта с возможностью записи. Если перемещенный файл имеет недоступные разрешения, выполните команду takeown.exe в окне командной строки администратора, чтобы стать владельцем файла.
Недостаточно места на диске
Эта ошибка может возникать, если на диске недостаточно места. Компоновщик использует временные файлы в нескольких ситуациях. Даже если на диске достаточно места, большие ссылки могут выпустить или фрагментировать свободное место на диске. Рассмотрите возможность использования параметра /OPT (оптимизация) . выполнение транзитного исключения COMDAT считывает все объектные файлы несколько раз.
Проблемы в переменной среды TMP
Если имя файла LNKnnn, то это имя файла, созданного компоновщиком для временного файла. Каталог, указанный в переменной среды TMP, может не существовать. Кроме того, для переменной среды TMP может быть задано несколько каталогов. Для переменной среды TMP должен быть указан только один путь к каталогу.
Справка, моей проблемы нет в списке!
Я перестроил свое решение и получил следующую ошибку компиляции:
Ошибка 9 «Не удалось загрузить файл или сборку ComponentArt.Web.UI, Version = 2009.1.1819.35, Culture = нейтральный, PublicKeyToken = 9bc9f846553156bb» или одну из его зависимостей. Неверный указатель (исключение из HRESULT: 0x80004003 (E_POINTER)) 'D: .. \ MyProj.Account \ LC
DLL находится в папке Infra и в конечном итоге перемещается в папку bin выходного проекта (веб-сайт).
Есть какие-нибудь продуктивные идеи? что еще я должен проверить? Похоже, что все остальные проекты в этом sln компилируются.
Если я не получу эту ошибку в ближайшее время. кстати, что такое LC (в столбце "проект")?
5 ответы
Я бы проверил ваш файл licenses.licx и убедился, что указанная в нем версия точно совпадает с DLL, на которую вы ссылаетесь.
Мы часто удаляем все после версии в этом файле из-за схожих проблем.
Под LC обычно понимается компилятор лицензий lc.exe.
Это была еще одна неработающая ссылка, которая вызвала эту ошибку.
Это сработало для меня. Я сделал windiff, чтобы сравнить старый и новый файлы csproj, и, конечно же, ссылка на проект отсутствовала. - живи любя
Самый простой способ выяснить, какой DLL отсутствует, - это удалить текст в licenses.licx и перестроить проект / решение - Азаде Ходжанди
что ты имеешь в виду? - Spyder
ответ дан 23 мая '17, 11:05
Убедитесь, что на пути к вашему проекту нет пробелов .
Я использую Windows 10 с Visual Studio Community 2019, и я клонировал многопроектное решение, как это было из репозитория GIT. У меня была эта ошибка вместе со всеми другими зависимостями в решении с метаданные для xyz.dll не найдены ошибка. Его путь, унаследованный от GIT, имел пробелы вроде C: / repos /НАЗВАНИЕ МОЕГО ПРОЕКТА/ .
Я удалил его, снова клонировал и убедился, что в его пути нет пробелов вроде C: / repos /МОЙ_ПРОЕКТ_ИМЯ/ .
Это устранило мою проблему.
В моем случае проблема была в профиле публикации, я использовал Release - Any CPU конфигурация публикации для публикации проекта в локальной папке. Таким образом, он не загружал telerik.web.ui сборка, но при отладке все работало отлично. Итак, я изменил конфигурацию публикации на Debug - Any CPU и ошибка исчезла.
PS: Помните, это займет Debug конфигурации из вашего web.config файл, который будет web.debug.config и если у вас нет файла, потребуется web.config конфигурации файлов по умолчанию. Поэтому убедитесь, что вы указываете правильную конфигурацию, когда публикуете файлы в реальной среде.
Я попробовал очистить/перестроить решение, закрыть Visual Studio и даже перезагрузить компьютер. Я также позаботился о том, чтобы выполнить шаги, описанные в прогонах Debugging, даже с ошибками компилятора в Visual Studio. Я могу изменить файлы .cs, и я вижу изменения в решении.
Есть ли у кого-нибудь представление о том, почему он это делает?
Если у вас есть ReSharper, попробуйте очистить кеш ReSharper:
В меню ReSharper> Параметры> Среда> Общие> Очистить кэш
и отключение и повторное включение ReSharper:
В меню Инструменты> Параметры> ReSharper> Общие> Приостановить/Восстановить
Очистка кэша Resharper не помогла в моем случае, попробовала приостановить/восстановить, а также Repair Resharper, используя последнюю загрузку с сайта JetBrains – ни одна из них не помогла. Это после того, как я попытался закрыть/снова открыть VS, перезагрузить машину, повторить, построить/перестроить и их комбинацию.
Интересно, что приостановление работы Resharper, казалось, решило проблему после перезапуска VSO 2nd, но она вернулась после того, как я включил Resharper < – Я пытался сделать эту последовательность 2-3 раза обеспечить шаблон.
Во всяком случае, у меня все еще были проблемы, когда я нашел эту статью:
Итак, я удалил скрытый файл .SUO на том же уровне папок с решением, и он волшебным образом решил все красные.
Примечание. Для Visual Studio 2015 файл .SUO находится в скрытой папке .vs/[solution_name]/v14.
tldr; Выгрузите и перезагрузите проблемный проект.
Когда это происходит со мной, я (раньше) пытался закрыть VS и снова открыть его. Это, вероятно, работало примерно половину времени. Если это не помогло, я бы закрыл решение, удалил файл .suo (или всю папку .vs) и заново открыл решение. До сих пор это всегда работало для меня (более 10 раз за последние 6 месяцев), но это немного утомительно, потому что некоторые вещи сбрасываются, такие как режим сборки, запуск проекта и т.д.
Поскольку обычно это был только один проект, в котором возникла проблема, я просто попытался выгрузить этот проект и перезагрузить его, и это сработало. Мой размер выборки составляет всего 1, но он намного быстрее, чем два других варианта, поэтому, возможно, стоит попробовать. Я подозреваю, что это работает, потому что он пишет в файл .suo и, возможно, исправляет поврежденную часть, которая и вызывала проблему.
Примечание. По-видимому, это работает для VS 2019, 2017 и 2015.
Я очистил раствор, закрыл VS, снова открыл его, построил решение, и красные неразрешенные линии были очищены, а сборка выполнена успешно.
Я обнаружил, что это часто случается при использовании Git в Visual Studio 2017, переключая ветки, где есть зависимые изменения кода. Даже если проект будет успешно построен, в списке ошибок останутся ошибки.
Эти ошибки часто являются проблемами пространства имен и отсутствующими ссылками, даже если ссылка на библиотеку существует.
- Закрыть Visual Studio
- Удалите файл .vs\SlnName\v15.suo (скрытый)
- Перезапустите Visual Studio
Я пробовал все 6 вариантов, ничего не работало для меня. Ниже решения была решена моя проблема.
Закрыть VS. Удалите скрытую папку “.vs” рядом с файлом решения. Перезагрузите VS и загрузите решение.
У меня возникла такая проблема, когда Intellisense, похоже, не признавал существование одного проекта (много “не может найти этот тип”, “это пространство имен не существует” и т.д. ошибок).
Удаление и повторное добавление ссылки на проект во всех проектах-ссылках устранит проблему, но основная причина может быть устранена путем редактирования .proj файла проблемного проекта.
В верхней части “отсутствующего” проекта “.csproj файл – это элемент:
а во всех ссылочных проектах файлы .csproj были ссылками на проект:
Ссылка GUID не соответствует GUID проекта. Замена выше на устраняет проблему без необходимости проходить через каждый проект ссылки.
Удалите скрытый путь к файлу = вашего решения\.vs\Имя вашего решения\v15\.suo
для VS-2017 удаленная папка.vs работала для меня.
Я заметил, что иногда при переключении веток git Visual Studio (2017) не распознает типы из некоторых файлов, которые были добавлены во второй ветке. удаление папки .vs решает ее, но она также удаляет все настройки вашего рабочего пространства. Мне кажется, этот трюк хорошо работает:
- Обозреватель решений → Найти файл с нераспознанным классом в нем.
- Нажмите Показать все файлы в верхней части обозревателя решений.
- Щелкните правой кнопкой мыши файл → Исключить из проекта.
- Снова щелкните файл правой кнопкой мыши → Включить в проект.
Это заставляет Intellisense анализировать файл, который он пропустил при переключении веток.
Вариант 1. Очистка, сборка и обновление (@Mike Fuchs)
Как упоминалось в @Mike Fuchs, попробуйте выполнить следующие действия:
В меню “Построение”> “Чистый раствор”
И
В меню “Построить”> “Построить решение”
выберите нужный проект и нажмите кнопку обновления:
Вариант 2. Очистить, закрыть, перезапустить и собрать (опция@Pixel)
Как упоминалось в @Pixel, попробуйте выполнить следующую последовательность действий:
- Очистить раствор
- Закройте Visual Studio
- Откройте Visual Studio
- Построить решение
Вариант 3. Очистить кеш ReSharper (@GammaOmega)
Если у вас есть ReSharper, попробуйте очистить кеш ReSharper:
In menu, ReSharper > Options > Environment > General > Clear Caches
и отключение и повторное включение ReSharper:
In menu, Tools > Options > ReSharper > General > Suspend/Restore
Вариант 4. Удалите файл .suo(@Neolisk)
.Как упоминалось в @Neolisk, удаление файла .suo может решить вашу проблему. Для Visual Studio 2015 файл находится в:
А для Visual Studio 2017:
Обратите внимание, что каталог .vs скрыт.
Вариант 5. Выгрузка и перезагрузка проекта (@TTT)
Как уже упоминалось @TTT, попробуйте выгрузить проект, который вызывает проблемы:
In Solution Explorer, right-click on project, Unload Project.
И перезагрузите его
In Solution Explorer, right-click on project, Reload Project.
Вариант 6. Удалите и добавьте ссылку на Microsoft.CSharp(@Guilherme)
Как упоминалось в @Guilherme, попробуйте удалить и добавить ссылку на “Microsoft.CSharp” из проектов, в которых возникли проблемы.
In Solution Explorer, expand the project, expand “References”, right-click on “Microsoft.CSharp” и Remove.
Затем щелкните правой кнопкой мыши References> Add Reference, выберите “Microsoft.CSharp” из списка и нажмите “OK”.
Иногда мне приходится выполнять обычную очистку, просматривая все проекты и вручную удаляя папки “bin” и “obj”. Чтобы увидеть их в Visual Studio, вам нужно включить скрытые файлы и папки для каждого проекта. После этого переустановите решение.
Следующее решение сработало для меня
2 – Удалить папку.vs
4 – Сборка решения
Возможно, вы пытаетесь использовать reset свой кеш intellisense. У меня была аналогичная проблема в visual studio 2012 при работе в большом проекте со многими определениями частичного класса.
Уменьшение частичных решений частично разрешило проблему, также очистив кеш intellisense – на некоторое время.
Мой коллега столкнулся с этой проблемой сегодня. Мы испробовали многие рекомендации здесь, но ни одна из них не сработала, кроме решения, описанного ниже.
Проблема:
Проект строит штраф, но Intellisense не распознает определенные типы и помечает определенное с using заявления как недействительные.
Решение:
Измените “Платформу решений” (в VS 2017 это раскрывающийся список рядом с раскрывающимся списком “Конфигурация решения”, который имеет значения, такие как x86, x64, AnyCPU, Mixed Platforms и т.д.), На AnyCPU.
Платформа для вашего проекта может отличаться, но кажется, что некоторые ссылки могут быть недействительными для всех платформ.
В моем конкретном случае это была ссылка на службу, другая разработчик слилась с основной ветвью. Это было прекрасно, но подсветка синтаксиса не смогла разрешить созданный класс сервиса, а источник был выделен красным цветом. Очистка, перестройка, перезапуск ничего не сделали.
Все, что мне нужно было сделать, – это обновить служебную ссылку, и VS удалось собрать фрагменты за кулисами. Никаких изменений в исходном коде или сгенерированных файлах.
Я только что столкнулся с этой проблемой после того, как вернул фиксатор git, который добавил файлы обратно в мой проект.
Очистка и восстановление проекта не сработали, даже если я закрыл VS между каждым шагом.
Что в конечном итоге сработало, переименовал файл в другое и снова изменил его.: Facepalm:
0 – Щелкните правой кнопкой мыши на решении и очистите решение
2 – Удалить файл проекта.suo
4 – Сборка решения
После проверки всех перечисленных вариантов я обнаружил еще одну причину, почему это может произойти. Если кто-то отправил вам исходный код в виде zip или загрузил zip, Windows, возможно, заблокировала все файлы. 2 способа решить эту проблему:
Способ 1:
Щелкните правой кнопкой мыши на исходном файле Zip → Проверить “Разблокировать” → Нажмите “Применить”
Способ 2:
Если это не опция, а не открытие свойств для каждого файла в папке решения, просто откройте оболочку питания и разблокируйте рекурсивно, используя следующее:
- сначала закройте решение.
- затем удалите файл кэша решения (в папке C:\Users\Documents\Visual Studio\Backup Files/файле кэша проекта)
- затем.suo удалить файл
- то решение открывается и строится.
Я надеюсь решить вашу проблему
Была эта проблема на работе (работает VS2017). Перепробовал все ответы здесь. Нет радости
Проект строился бы просто отлично, но жаловался, что не удалось найти пространства имен/типов. Красные повороты повсюду. Много ошибок в окне списка ошибок.
Мое решение содержало 3 проекта.
Обнаружено, что 3 из ссылок на библиотеку NuGet для одного из проектов были вне очереди. Консолидированы ссылочные версии библиотеки и бинго.
Надеюсь, это кому-нибудь поможет.
Выгрузить и перезагрузить проект исправил эту проблему.
Удаление папки .vs решило мою проблему.
Но это также сбросить текущие настройки моего решения в VS. Мол, мои выгруженные проекты в решении были перезагружены, и все прикрепленные и открытые документы также были закрыты, когда я перезапустил VS.
Иногда, если вы просто очищаете решение, ошибки исчезают, но они могут в конечном итоге вернуться назад или в следующую сборку.
В этом случае возникла проблема с тем, что Visual Studio не распознал один тип, который показал красную отблеску, даже если решение было успешно построено. Я заметил, что в обозревателе решений у него не было стрелки расширения слева, где показаны классы и свойства при расширении.
Исправлено: Исключить файл из проекта и сохранить/построить, из-за которого возникла ожидаемая ошибка, а затем Включить файл в проект и сохранить и построить.
После выполнения этих шагов Visual Studio снова начала распознавать мой тип. Если посмотреть на diff в git, то проблема возникла из-за несоответствий строк в строке моего файла .csproj.
в моем случае vs никогда не сохранял импортированные пространства имен в свойствах проекта> ссылки
когда я попытался добавить/проверить их снова, я не мог и vs забросил ошибку, и когда был спасен проект vs разбился. Когда я снова открывал все стандартные импортированные пространства имен (system.data и т.д.), Все снова были отмечены галочкой, и тогда он распознавал все без ошибок
TL; DR: выполнить чистую переустановку Visual Studio
Итак, я предполагаю, что может быть что-то не так с самой Visual Studio (возможно, что-то в каталоге кеша или вообще что-то на вашем ПК, которое напрямую не связано с конкретным решением), которое может быть решено чистым и полным re -установка Visual Studio. Я знаю, это глупое “решение”, но в моем случае только новая установка Visual Studio (2019) имела эффект.
Как уже упоминалось, в моем случае затронуты только классы STL. IntelliSense не отображает своих членов, что нечетно. Я думал, это может быть связано с прекомпилированными заголовками. Где-то я читал, что STL и проект должны быть на одном диске и помещать их на то же самое, чтобы решить проблему. Но ни один из этих маршрутов не привел к успеху.
Я обнаружил, что это может произойти, если указанный проект нацелен на более высокую версию фреймворка, чем проект, который пытается его использовать. Вы можете сказать, если это проблема, перейдя в окно вывода и ища что-то похожее на это:
Решение состоит в том, чтобы изменить целевую структуру того или иного проекта.
Попробуйте навести курсор мыши на подчеркнутые элементы. Обычно это говорит вам, в чем проблема. Чтобы просмотреть список всех ошибок/предупреждений, перейдите в View = > Список ошибок. Таблица должна открываться в нижней части IDE со всеми перечисленными ошибками/предупреждениями.
Читайте также: