Проект устарел visual studio 2017
Я пытаюсь заставить Visual С++ работать, но я получаю эту ошибку при создании каждого проекта: "Этот проект устарел" "Хочешь его построить?" Он не может создавать каждый раз.
Я получаю эту ошибку: проект не обновляется, потому что "вставить имя файла здесь". отсутствует.строить состояние.. Обратите внимание, что в реальной визуальной студии ничего не регистрируется. Я не смог найти что-либо в этом в google. Возможно, я неправильно включил ведение журнала, но я чувствую, что это ошибка.
ОТВЕТЫ
Ответ 1
Что такое файлы tlog?
"tlog" файлы создаются процессом "Tracker.exe", который выполняется во время сборки, и записывает некоторую информацию о сборке.
Эта информация используется и обновляется при следующем запуске сборки, чтобы обнаруживать "устаревшие" файлы и, таким образом, позволяет сборке строить только биты, которые необходимо перестроить (а не строить все снова).
Что вызывает проблему "устаревшего"?
Проблема может быть вызвана неправильной или устаревшей информацией в файлах *.tlog .
Существует 3 основных способа:
1) Вы создали проект на своем жестком диске, а затем переместили каталог в другое место. файлы "tlog" записывали пути старого местоположения, но поскольку вы перемещали файлы, их больше нет, таким образом, вы получаете "устаревшие".
2) В вашем "Проекте" есть ссылки на файлы (обычно заголовочные файлы), которых нет в указанном месте. Это может произойти, если вы удалили файл из исходной системы управления, но забыли удалить его из своего проекта или потому, что ссылаетесь на файлы заголовков библиотеки, которые могут быть "установлены" /присутствовать в другом месте. Часто разработчики предполагают, что файлы находятся в одном и том же "месте" на каждой машине. не всегда в этом случае!
3) Вы сделали "рефакторинг" своего проекта и переместили файлы в разные подкаталоги или даже переименовали их, поэтому пути/имена файлов, записанных в "tlog" , не соответствуют тому, что существует на вашем диск, т.е. устаревший.
Выполнение "Clean + Build" или "Rebuild" не всегда фиксирует это. поскольку эти операции не удаляют файлы "tlog" . Итак:
удалите все файлы "tlog" , которые вы можете найти в своих каталогах решений/проектов и перестройте.
убедитесь, что ваш проект не ссылается на несуществующие файлы
Как я могу определить, какие файлы не существуют?
В devenv.exe.config вы помещаете:
Подробнее
Предположим, вы создали решение и набор проектов в определенном каталоге, например. S:\MYPROJECTS, и вы компилируете и запускаете/отлаживаете его и т.д.
Затем вы решите переместить весь этот каталог в другое место на своем диске или перегруппировать свои проекты, например. изменить их имена каталогов и т.д.
Теперь, когда вы выполняете "Начать отладку /F 5", Visual Studio выполняет зависящую проверку и думает, что у вас есть "устаревшие файлы".
Проблема вызвана файлами ".tlog", с которыми консультируются во время проверок зависимостей. при перемещении решений/проектов (вместе с промежуточными файлами сборки) они вызывают путаницу с компоновщиком Visual Studio.
Ответ 2
Вы должны позволить Visual Studio рассказать вам, почему нужно перестроить. Visual Studio 2015 имеет поддержку для этого:
- Инструменты (меню)
- Параметры
- Проект и решение
- Сборка и запуск
Измените многострочный вывод сборки проекта MSBuild на Подробный или Диагностика.
. и удаление этого заголовка из проекта устраняет проблему.
Ответ 3
Ответ 4
У меня тоже была эта проблема. В моем случае причиной были ссылки на файлы (обычно заголовочные файлы), которые не существуют в указанном местоположении.
Ответ 5
Я столкнулся с этой проблемой и, используя диагностический трюк, о котором сообщал colinsmith, смог проследить проблему до того, что мой .vcxproj ссылался на файл, который фактически нигде не существовал (он был удален давным-давно, но никогда не удалялся из файла проекта).
Visual Studio помогает обновить устаревший код C++ с помощью параметров компилятора, предупреждений анализа кода и функций редактора, таких как быстрые исправления, краткие сведения и расширенная полоса прокрутки. Термин "устаревший код" относится к любой из следующих категорий:
Код, который ранее был разрешен компилятором Microsoft C++ (MSVC), но никогда не соответствовал стандарту C++.
Код, разрешенный в более ранней версии стандарта C++, но нерекомендуемый или удаленный в более поздней версии.
Чтобы перейти на более новый языковой стандарт, установите для параметра "Стандартный язык C++ " требуемый стандарт и исправьте все возникающие ошибки компиляции. Как правило, мы рекомендуем задать для стандарта /std:c++17 языка значение или /std:c++20 . Ошибки, возникающие при обновлении до более новой версии стандарта, не связаны с ошибками, возникающими при использовании /permissive- параметра.
Код, который соответствует всем версиям стандарта, но больше не считается рекомендуемым в современном C++.
Чтобы определить код, в котором рекомендуется вносить изменения, выполните анализ кода.
Открытие и преобразование устаревшего проекта
Если устаревший проект основан на более старой версии Visual Studio, его можно открыть в Visual Studio 2017 или Visual Studio 2019. Visual Studio автоматически преобразует его в текущую схему проекта с поддержкой всех последних функций компилятора и интегрированной среды разработки.
Поиск в базе кода
Обновление базы кода часто включает поиск по нескольким файлам. Чтобы найти что-либо в базе кода, нажмите клавиши CTRL+T , чтобы открыть поле поиска "Перейти ко всем ".
Чтобы сузить область поиска, введите один из 1-буквных фильтров, а затем пробел, а затем то, что вы ищете.
Список ошибок
После установки требуемого стандарта языка C++ и других параметров компилятора (Project>PropertiesGeneral>) нажмите клавиши CTRL+SHIFT+B, чтобы скомпилировать проект. Вы можете увидеть некоторые ошибки и предупреждения в виде красных волнистых волн в различных местах в коде. Ошибки также отображаются в списке ошибок. Дополнительные сведения о конкретной ошибке щелкните код ошибки, чтобы перейти на страницу справки в документации. Коды ошибок, начинающиеся с "C", являются ошибками компилятора. Коды, начинающиеся с "MSB", являются MSBuild ошибками, которые указывают на проблему с конфигурацией проекта.
Индикатор работоспособности документа
Индикатор работоспособности документа в нижней части редактора показывает количество ошибок и предупреждений в текущем документе и позволяет переходить непосредственно от одного предупреждения или ошибки к следующему.
Во многих случаях дополнительные сведения о конкретной ошибке можно найти в документации по Visual Studio улучшениям журнала изменений и соответствия.
Использование анализа кода для модернизации кода
При обновлении рекомендуется выполнить анализ кода в проекте, чтобы код соответствовал как минимум правилам, рекомендованным корпорацией Майкрософт. Эти правила представляют собой сочетание правил, определенных корпорацией Майкрософт, и подмножество основных рекомендаций C++. Благодаря соответствию этим требованиям вы значительно уменьшите или исключите распространенные источники ошибок, а также сделает код более удобочитаемым и, следовательно, упрощает обслуживание. Code Analysis использование собственных рекомендуемых правил Майкрософт по умолчанию включено. Дополнительные правила можно включить в разделе Project>Properties>Code Analysis. Код, который нарушает одно из правил, помечается как предупреждение и подчеркивается зеленым волнистой линией в редакторе кода. Наведите указатель мыши на волнистую линию, чтобы увидеть подсказку QuickInfo , описывающую проблему.
Щелкните значок фильтра в столбце "Код" , чтобы выбрать, какие предупреждения отображаются.
Ошибки и предупреждения анализа кода также отображаются в списке ошибок , как ошибки компилятора.
Вы можете изменить активные правила и создать настраиваемые наборы правил. Дополнительные сведения об использовании Code Analysis см. в обзоре анализа кода для C/C++.
Использование быстрых действий для модернизации кода
Редактор кода предоставляет быстрые действия для некоторых распространенных рекомендаций. Когда появится значок лампочки, щелкните его, чтобы просмотреть доступные быстрые действия.
Преобразование макросов в функции constexpr
На следующем рисунке показано использование вызываемого AVERAGE макроса, который имеет семантику раскраски по умолчанию. На изображении также показана подсказка QuickInfo, которая отображается при наведении указателя мыши на него:
Так как использование макросов в современном C++ не рекомендуется, Visual Studio упрощает преобразование макросов в constexpr функции:
Щелкните правой кнопкой мыши AVERAGE и выберите "Перейти к определению".
Щелкните значок отвертки и выберите "Преобразовать макрос в constexpr"
Макрос преобразуется, как показано ниже:
AVERAGE Вызов теперь раскрасен как вызов функции, а подсказка "Быстрая информация" показывает выводимый тип функции:
Инициализация переменных
Неинициализированные переменные могут содержать случайные значения, которые приводят к серьезным ошибкам. Анализ кода помечает эти экземпляры, а редактор предоставляет быстрое действие:
Преобразование в необработанный строковый литерал
Необработанные строковые литералы менее подвержены ошибкам и удобнее вводить, чем строки со встроенными escape-символами. Щелкните строку правой кнопкой мыши и выберите "Быстрые действия" , чтобы преобразовать ее в необработанный строковый литерал.
Для этой процедуры можно ввести собственную программу на языке C++ или использовать один из примеров программ. Пример программы, используемый в этой процедуре, создает текстовый файл textfile.txt и сохраняет его в каталог проекта.
Предварительные требования
- Для работы необходимо владеть основами языка C++.
- в Visual Studio 2017 и более поздних версий поддержка C++/cli является дополнительным компонентом. чтобы установить его, откройте Visual Studio Installer из Windows меню. Убедитесь, что установлен флажок Разработка классических приложений на C++ , и в разделе Дополнительные компоненты также следует проверить поддержку C++/CLI.
Создание проекта
Приведенные ниже инструкции немного отличаются в зависимости от используемой версии Visual Studio. Чтобы ознакомиться с документацией по предпочтительной версии Visual Studio, используйте селектор Версия. Он находится в верхней части оглавления на этой странице.
Создание проекта C++/CLI в Visual Studio
в Обозреватель решенийщелкните правой кнопкой мыши вверху, чтобы открыть диалоговое окно создание нового Project .
в верхней части диалогового окна введите clr в поле поиска, а затем выберите clr Empty Project из списка результатов.
создание проекта C++/cli в Visual Studio 2017
Создайте новый проект. В меню Файл выберите пункт Создать, а затем команду Проект.
В списке типов проектов Visual C++ щелкните CLR, а затем — Пустой проект CLR.
Введите имя проекта. По умолчанию содержащее проект решение имеет то же имя, что и новый проект, но можно ввести другое имя. При необходимости можно ввести другое расположение для проекта.
создание проекта C++/cli в Visual Studio 2015
Создайте новый проект. В меню Файл выберите пункт Создать, а затем команду Проект.
В списке типов проектов Visual C++ щелкните CLR, а затем — Пустой проект CLR.
Введите имя проекта. По умолчанию содержащее проект решение имеет то же имя, что и новый проект, но можно ввести другое имя. При необходимости можно ввести другое расположение для проекта.
Добавить исходный файл
Если обозреватель решений не отображается, в меню Вид выберите пунукт Обозреватель решений.
Добавьте новый исходный файл в проект:
щелкните правой кнопкой мыши папку исходные файлы в Обозреватель решений, наведите указатель на пункт добавитьи выберите пункт новый элемент.
Щелкните элемент Файл C++ (.cpp), введите имя файла и нажмите кнопу Добавить.
cpp -файл появится в папке " исходные файлы " в Обозреватель решений и откроется окно с вкладками, где вы вводите необходимый код в этом файле.
Щелкните только что созданную вкладку в Visual Studio и введите допустимую программу Visual C++ или скопируйте и вставьте один из примеров.
Например, можно использовать пример Практическое руководство. Запись данных в текстовый файл (C++/CLI) (в узле File Handling and I/O (Работа с файлами и операции ввода-вывода) руководства по программированию).
StreamWriter^ sw = gcnew StreamWriter(fileName);
Дополнительные сведения о синтаксисе C++/CLI см. в разделе расширения компонентов для платформ среды выполнения.
В меню Сборка выберите Построить решение.
Если внести изменения и запустить программу, не выполняя сборку, диалоговое окно может сообщить, что проект устарел. Установите флажок в этом диалоговом окне, прежде чем нажимать кнопку ОК, если вы хотите, чтобы Visual Studio всегда использовала актуальные версии файлов вместо того, чтобы выводить запрос при каждой сборке приложения.
В меню Отладка выберите команду Запуск без отладки.
Если использовался пример программы, при выполнении программы отображается командное окно, указывающее, что текстовый файл был создан.
Теперь текстовый файл textfile.txt находится в каталоге проекта. Этот файл можно открыть с помощью Блокнота.
При выборе пустого шаблона проекта CLR автоматически задается параметр компилятора /clr . Чтобы проверить это, щелкните правой кнопкой мыши проект в обозревателе решений и выберите Свойства, а затем установите флажок Поддержка общеязыковой среды выполнения (CLR) в узле Общие окна Свойства конфигурации.
Как правило, каждая версия Visual Studio поддерживает большую часть типов проектов, файлов и других ресурсов предыдущих выпусков. С ними можно работать, как обычно, при условии, что вы не зависите от новых функций. В Visual Studio по возможности сохраняется обратная совместимость с предыдущими версиями, такими как Visual Studio 2015, Visual Studio 2013 и Visual Studio 2012. (См. заметки о выпуске, чтобы узнать, какие функции к какой версии относятся.)
Поддержка некоторых типов проектов также со временем меняется. Новейшая версия Visual Studio может больше не поддерживать некоторые проекты или же потребовать обновить проект так, что он больше не будет обратно совместимым. Текущее состояние проблем с миграцией см. на сайте сообщества разработчиков Visual Studio.
В этой статье содержатся только сведения о типах проектов, которые Visual Studio 2017 может переносить. В статье не указаны типы проектов, которые больше не поддерживаются в Visual Studio 2017 и поэтому не могут быть перенесены. Кроме того, в ней не указаны поддерживаемые типы проектов, не имеющие проблем с миграцией. Этот список находится на странице целевой платформы и совместимости.
Если вы ищете сведения о последнем выпуске, см. версию этой страницы для Visual Studio 2022.
Для определенных типов проектов требуется установить соответствующие рабочие нагрузки с помощью установщика Visual Studio. При отсутствии установленной рабочей нагрузки Visual Studio сообщает о неизвестном или несовместимом типе проекта. В этом случае проверьте параметры установки и повторите попытку. Просмотрите статью о целевой платформе и совместимости для получения сведений о поддержке проектов в Visual Studio 2017.
Типы проектов
В следующем списке описывается поддержка проектов Visual Studio 2017, созданных в более ранних версиях.
- Теперь проекты моделирования называются в меню и шаблонах проектами проверки зависимостей.
- UML-схемы больше не поддерживаются в Visual Studio 2017. UML-файлы указываются в обозревателе решений, как и ранее, но открываются как XML-файлы. Для просмотра, создания или изменения UML-схем следует использовать Visual Studio 2015.
- В Visual Studio 2017 проверка архитектурных зависимостей больше не выполняется при сборке проекта моделирования. Вместо этого проверка осуществляется при сборке каждого проекта кода. Это изменение не влияет на проект моделирования, но необходимо внести изменения в проверяемые проекты кода. Visual Studio 2017 автоматически вносит необходимые изменения в проекты кода (дополнительные сведения).
Как Visual Studio определяет необходимость переноса проекта
В каждой новой версии Visual Studio по возможности сохраняется совместимость с предыдущими версиями, чтобы проект можно было открывать, изменять и выполнять его сборку в разных версиях. Однако со временем неизбежны изменения, из-за которых некоторые типы проектов могут больше не поддерживаться. (Список типов проектов, поддерживаемых в Visual Studio 2017, см. в статье Целевые платформы и совместимость.) В таких случаях проект не будет загружаться в более новой версии Visual Studio и путь миграции предлагаться не будет. С проектом следует работать в предыдущей версии Visual Studio, которая поддерживает его.
В других случаях проект может открываться в более новой версии Visual Studio, но он должен быть обновлен или перенесен, из-за чего он может стать несовместимым с предыдущими версиями. Необходимость в миграции определяется в Visual Studio на основе ряда критериев:
совместимость с целевыми версиями платформ вплоть до Visual Studio 2013 RTM;
совместимость ресурсов времени разработки с предыдущими версиями Visual Studio (в частности, с различными каналами Visual Studio 2017, Visual Studio 2015 RTM и с обновлением 3, Visual Studio 2013 RTM и с обновлением 5, Visual Studio 2012 с обновлением 4, Visual Studio 2010 с пакетом обновления 1 (SP1)); в случае использования нерекомендуемых ресурсов времени разработки в Visual Studio 2017 предпринимается попытка обработать их корректно, не повреждая их, чтобы проект по-прежнему мог открываться в предыдущих версиях;
нарушение совместимости с предыдущими версиями вплоть до Visual Studio 2013 RTM и с обновлением 5 из-за новых ресурсов времени разработки.
Технический владелец проекта оценивает эти критерии и создает запрос, если имеется необходимость в поддержке, обеспечении совместимости и миграции. Между версиями Visual Studio по возможности обеспечивается прозрачная совместимость. Это означает, что проекты, создаваемые и изменяемые в одной версии Visual Studio, будут работать в других версиях.
Однако если такая совместимость невозможна, как в случае с некоторыми типами проектов, описанными в этой статье, в Visual Studio открывается мастер обновления для внесения необходимых односторонних изменений.
Одним из этих односторонних изменений может быть изменение свойства ToolsVersion в файле проекта. Оно указывает, какая именно версия MSBuild может преобразовывать исходный код проекта в выполняемые и развертываемые артефакты. То есть несовместимость проекта с предыдущими версиями Visual Studio зависит не от версии Visual Studio, а от версии MSBuild, определяемой свойством ToolsVersion . Если ваша версия Visual Studio включает в себя цепочку инструментов MSBuild, соответствующую значению свойства ToolsVersion в проекте, то она может вызывать эту цепочку инструментов для сборки проекта.
С целью обеспечения максимальной совместимости с проектами, созданными в более ранних версиях, Visual Studio 2017 включает в себя необходимые цепочки инструментов MSBuild для поддержки значений ToolsVersion 15, 14, 12 и 4. Сборка проектов, в которых используется любое из этих значений ToolsVersion , должна выполняться успешно. (При этом необходимо учитывать, поддерживает ли вообще Visual Studio 2017 данный тип проекта, как описано в статье Целевые платформы и совместимость.)
Следующие шаги
Дополнительные сведения см. в следующих статьях:
См. также
Каждая новая версия Visual Studio поддерживает большую часть типов проектов, файлов и других ресурсов. С ними можно работать как обычно, при условии, что вы не зависите от новых функций.
Если вы ищете сведения о следующем выпуске, см. версию этой страницы для Visual Studio 2022.
Мы стараемся сохранить обратную совместимость с предыдущими версиями, такими как Visual Studio 2017, Visual Studio 2015, Visual Studio 2013 и Visual Studio 2012. Однако поддержка некоторых типов проектов также со временем меняется. Новейшая версия Visual Studio может не поддерживать некоторые проекты или же потребовать обновить проект так, что он больше не будет обратно совместимым.
Текущее состояние проблем с миграцией см. в сообществе разработчиков Visual Studio. Просмотрите заметки о выпуске, чтобы узнать, какие функции к какой версии Visual Studio относятся.
Некоторые типы проектов требуют конкретных рабочих нагрузок. При отсутствии установленной рабочей нагрузки Visual Studio сообщает о неизвестном или несовместимом типе проекта. В этом случае проверьте параметры установки в Visual Studio Installer и повторите попытку. Дополнительные сведения о поддержке проектов в Visual Studio 2019 см. в статье Целевая платформа и совместимость для Visual Studio 2019.
Типы проектов
В следующем списке описывается поддержка проектов Visual Studio 2019, созданных в более ранних версиях.
Visual Studio 2017: Формат XPROJ поддерживается исключительно для переноса в формат CSPROJ. При открытии XPROJ-файла вам будет предложено перенести файл в формат CSPROJ в стиле SDK. (Будет создана резервная копия XPROJ-файла.) Проекты формата CSPROJ в стиле SDK не поддерживаются в Visual Studio 2015 и более ранних версиях.
- Теперь проекты моделирования называются в меню и шаблонах проектами проверки зависимостей.
- UML-схемы больше не поддерживаются в Visual Studio 2017 и Visual Studio 2019. UML-файлы указываются в обозревателе решений, как и ранее, но открываются как XML-файлы. Для просмотра, создания или изменения UML-схем следует использовать Visual Studio 2015.
- В Visual Studio 2019 проверка архитектурных зависимостей больше не выполняется при сборке проекта моделирования. Вместо этого проверка осуществляется при сборке каждого проекта кода. Это изменение не влияет на проект моделирования, но необходимо внести изменения в проверяемые проекты кода. Visual Studio 2019 автоматически вносит необходимые изменения в проекты кода.
Из установщика Visual Studio 2019 были исключены версии пакетов SDK Windows 10, предшествующие обновлению Windows 10 Fall Creators Update (сборка 16299). Вы можете вручную скачать старые версии таких пакетов SDK или использовать их более новые версии.
Миграция проекта
Хотя мы пытаемся сохранить совместимость с предыдущими версиями, существуют изменения, из-за которых некоторые типы проектов могут больше не поддерживаться. (Список типов проектов, поддерживаемых в Visual Studio 2019, см. в статье Целевые платформы и совместимость.) В таких случаях в более новой версии Visual Studio не будет загружаться проект или предлагаться путь миграции. С этим проектом необходимо будет работать в предыдущей версии Visual Studio.
Иногда проект может открываться в более новой версии Visual Studio, но он должен быть обновлен или перенесен, из-за чего может стать несовместимым с предыдущими версиями. Необходимость в миграции определяется в Visual Studio на основе ряда критериев:
совместимость с целевыми версиями платформ вплоть до Visual Studio 2013 RTM;
совместимость ресурсов времени разработки с предыдущими версиями Visual Studio (в частности, с различными каналами Visual Studio 2019, Visual Studio 2017; Visual Studio 2015 RTM и с обновлением 3, Visual Studio 2013 RTM и с обновлением 5, Visual Studio 2012 с обновлением 4, Visual Studio 2010 с пакетом обновления 1 (SP1)); в случае использования нерекомендуемых ресурсов времени разработки в Visual Studio 2019 предпринимается попытка обработать их корректно, не повреждая их, чтобы проект по-прежнему мог открываться в предыдущих версиях;
нарушение совместимости с предыдущими версиями вплоть до Visual Studio 2013 RTM и с обновлением 5 из-за новых ресурсов времени разработки.
Группа разработчиков проекта оценивает эти критерии и создает запрос, если есть необходимость в поддержке, обеспечении совместимости и миграции. Мы пытаемся обеспечивать совместимость между версиями Visual Studio, чтобы проекты, создаваемые в одной версии Visual Studio, могли работать и в других версиях.
Иногда такая совместимость невозможна. Тогда в Visual Studio открывается мастер обновления для внесения необходимых односторонних изменений. Одним из этих односторонних изменений может быть изменение свойства ToolsVersion в файле проекта. Оно указывает, какая именно версия MSBuild может преобразовывать исходный код проекта в требуемые выполняемые и развертываемые артефакты.
Несовместимость проекта с предыдущими версиями Visual Studio зависит не от версии Visual Studio, а от версии MSBuild, определяемой свойством ToolsVersion . Если ваша версия Visual Studio включает в себя цепочку инструментов MSBuild, соответствующую значению свойства ToolsVersion в проекте, то она может вызывать эту цепочку инструментов для сборки проекта.
С целью обеспечения совместимости с проектами, созданными в предыдущих версиях, Visual Studio 2019 включает в себя необходимые цепочки инструментов MSBuild для поддержки значений ToolsVersion 15, 14, 12 и 4. Сборка проектов, в которых используется любое из этих значений ToolsVersion , должна выполняться успешно. (При этом необходимо учитывать, поддерживает ли Visual Studio 2019 данный тип проекта, как описано в статье Целевая платформа и совместимость для Visual Studio 2019.)
Следующие шаги
Дополнительные сведения см. в следующих статьях:
См. также
Каждая новая версия Visual Studio поддерживает большую часть типов проектов, файлов и других ресурсов. С ними можно работать как обычно, при условии, что вы не зависите от новых функций.
Мы стараемся сохранить обратную совместимость с предыдущими версиями, такими как Visual Studio 2019, Visual Studio 2017, Visual Studio 2015, Visual Studio 2013 и Visual Studio 2012. Однако поддержка некоторых типов проектов также со временем меняется. Новейшая версия Visual Studio может не поддерживать некоторые проекты или же потребовать обновить проект так, что он больше не будет обратно совместимым.
Текущее состояние проблем с миграцией см. в сообществе разработчиков Visual Studio. Просмотрите заметки о выпуске, чтобы узнать, какие функции к какой версии Visual Studio относятся.
Некоторые типы проектов требуют конкретных рабочих нагрузок. При отсутствии установленной рабочей нагрузки Visual Studio сообщает о неизвестном или несовместимом типе проекта. В этом случае проверьте параметры установки в Visual Studio Installer и повторите попытку. Дополнительные сведения о поддержке проектов в Visual Studio 2022 см. в статье Целевая платформа и совместимость.
Типы проектов
В следующем списке описывается поддержка проектов Visual Studio 2022, созданных в более ранних версиях.
Visual Studio 2017: Формат XPROJ поддерживается исключительно для переноса в формат CSPROJ. При открытии XPROJ-файла вам будет предложено перенести файл в формат CSPROJ в стиле SDK. (Будет создана резервная копия XPROJ-файла.) Проекты формата CSPROJ в стиле SDK не поддерживаются в Visual Studio 2015 и более ранних версиях.
- Теперь проекты моделирования называются в меню и шаблонах проектами проверки зависимостей.
- UML-схемы больше не поддерживаются в Visual Studio 2017 и Visual Studio 2019. UML-файлы указываются в обозревателе решений, как и ранее, но открываются как XML-файлы. Для просмотра, создания или изменения UML-схем следует использовать Visual Studio 2015.
- В Visual Studio 2019 проверка архитектурных зависимостей больше не выполняется при сборке проекта моделирования. Вместо этого проверка осуществляется при сборке каждого проекта кода. Это изменение не влияет на проект моделирования, но необходимо внести изменения в проверяемые проекты кода. Visual Studio 2019 автоматически вносит необходимые изменения в проекты кода.
Из установщика Visual Studio 2019 были исключены версии пакетов SDK Windows 10, предшествующие обновлению Windows 10 Fall Creators Update (сборка 16299). Вы можете вручную скачать старые версии таких пакетов SDK или использовать их более новые версии.
Миграция проекта
Хотя мы пытаемся сохранить совместимость с предыдущими версиями, существуют изменения, из-за которых некоторые типы проектов могут больше не поддерживаться. В таких случаях в более новой версии Visual Studio не будет загружаться проект или предлагаться путь миграции. С этим проектом необходимо будет работать в предыдущей версии Visual Studio.
Иногда проект может открываться в более новой версии Visual Studio, но он должен быть обновлен или перенесен, из-за чего может стать несовместимым с предыдущими версиями. Необходимость в миграции определяется в Visual Studio на основе ряда критериев:
совместимость с целевыми версиями платформ вплоть до Visual Studio 2013 RTM;
совместимость ресурсов времени разработки с предыдущими версиями Visual Studio (в частности, с различными каналами Visual Studio 2022, Visual Studio 2019; Visual Studio 2017, Visual Studio 2015 RTM и с обновлением 3, Visual Studio 2013 RTM и с обновлением 5, Visual Studio 2012 с обновлением 4 и Visual Studio 2010 с пакетом обновления 1); в случае использования нерекомендуемых ресурсов времени разработки в Visual Studio 2022 предпринимается попытка обработать их корректно, не повреждая их, чтобы проект по-прежнему мог открываться в предыдущих версиях;
нарушение совместимости с предыдущими версиями вплоть до Visual Studio 2013 RTM и с обновлением 5 из-за новых ресурсов времени разработки.
Группа разработчиков проекта оценивает эти критерии и создает запрос, если есть необходимость в поддержке, обеспечении совместимости и миграции. Мы пытаемся обеспечивать совместимость между версиями Visual Studio, чтобы проекты, создаваемые в одной версии Visual Studio, могли работать и в других версиях.
Иногда такая совместимость невозможна. Тогда в Visual Studio открывается мастер обновления для внесения необходимых односторонних изменений. Одним из этих односторонних изменений может быть изменение свойства ToolsVersion в файле проекта. Оно указывает, какая именно версия MSBuild может преобразовывать исходный код проекта в требуемые выполняемые и развертываемые артефакты.
Несовместимость проекта с предыдущими версиями Visual Studio зависит не от версии Visual Studio, а от версии MSBuild, определяемой свойством ToolsVersion . Если ваша версия Visual Studio включает в себя цепочку инструментов MSBuild, соответствующую значению свойства ToolsVersion в проекте, то она может вызывать эту цепочку инструментов для сборки проекта.
С целью обеспечения совместимости с проектами, созданными в предыдущих версиях, Visual Studio 2019 включает в себя необходимые цепочки инструментов MSBuild для поддержки значений ToolsVersion 15, 14, 12 и 4. Сборка проектов, в которых используется любое из этих значений ToolsVersion , должна выполняться успешно. (При этом необходимо учитывать, поддерживает ли Visual Studio 2019 данный тип проекта, как описано в статье Целевая платформа и совместимость для Visual Studio 2019.)
Я пытался заставить Visual C ++ работать, но при сборке каждого проекта я получаю эту ошибку: «Этот проект устарел» «Вы хотите его построить?» Не получается каждый раз строить.
Я искал 3 часа, не могу найти ничего, что могло бы помочь с этим. Если вы нашли что-то, что может помочь, пожалуйста, направьте меня к нему.
Если вы откроете визуальную студию и попытаетесь скомпилировать проект / решение вручную, появляются ли там ошибки? (Это проблема с ведением журнала или вашим кодом?)
Кроме того, имейте в виду, что проект устарел, вероятно, потому, что он никогда не был успешно построен, и что причина, по которой он не создается, не имеет ничего общего с lastbuildstate или вашим журналом. Устаревший проект - это не ошибка, а просто интересный момент. Вы можете отключить этот диолог в параметрах Visual Studio, но он не заставит ваш проект волшебным образом скомпилировать и не решит проблемы с журналированием.
Это также может быть вызвано наличием в вашем решении файлов, которых больше нет на диске, поэтому проверка отметки даты и времени не выполняется и всегда считает, что она устарела.
Что такое файлы "tlog"?
Файлы «tlog» создаются процессом «Tracker.exe», который запускается во время сборки и записывает некоторую информацию о сборке.
Эта информация используется и обновляется в следующий раз, когда вы запускаете сборку, чтобы помочь обнаружить «устаревшие» файлы и, таким образом, позволить системе сборки создавать только те биты, которые необходимо перестроить (вместо того, чтобы строить все заново).
Что вызывает проблему "устаревшего"?
Проблема может быть вызвана неверной или устаревшей информацией в *.tlog файлах.
Это может произойти тремя основными способами:
1) Вы создали проект на своем жестком диске, а затем переместили каталог в другое место . файлы "tlog" записали пути к старому местоположению, но из-за того, что вы переместили файлы, их больше нет, поэтому вы получить "устаревший".
2) Ваш «Проект» имеет ссылки на файлы (обычно файлы заголовков), которые не существуют в указанном месте. Это может произойти, если вы удалили файл из своей системы управления версиями, но забыли удалить его из своего проекта, или из-за того, что вы ссылаетесь на файлы заголовков библиотеки, которые могут быть «установлены» / присутствовать в другом месте. Часто разработчики предполагают, что файлы расположены в одном и том же «месте» на любой машине… не всегда так!
3) Вы выполнили некоторый «рефакторинг» своего проекта и переместили файлы в разные подкаталоги или даже переименовали их - поэтому пути / имена файлов, записанных в «tlog», не соответствуют тому, что существует на вашем диске, т.е. .
Выполнение «Clean + Build» или «Rebuild» не всегда исправляет это . поскольку эти операции не удаляют файлы «tlog». Так:
удалите все файлы «tlog», которые вы можете найти в каталогах вашего решения / проекта, и перестройте.
убедитесь, что ваш проект не относится к несуществующим файлам
Как определить, какие файлы не существуют?
В devenv.exe.config вас поставил:
Подробнее
Допустим, вы создали Решение и набор проектов в определенном каталоге, например, S: \ MYPROJECTS, и вы его компилируете, запускаете / отлаживаете и т. Д.
Затем вы решаете переместить весь этот каталог в другое место на вашем диске или повторно факторизуете свои проекты, например, изменяете их имена каталогов и т. Д.
Теперь, когда вы выполняете «Начать отладку / F5», Visual Studio выполняет зависимую проверку и считает, что у вас есть «устаревшие файлы».
Проблема вызвана файлами ".tlog", с которыми консультируются во время проверок зависимостей . когда вы перемещаете решения / проекты (вместе с промежуточными файлами сборки), они вызывают путаницу в компоновщике Visual Studio.
Читайте также: