Как перенести форму из одного проекта в другой visual studio

Обновлено: 07.07.2024

БлогNot. Visual C++: из формы в форму

Visual C++: из формы в форму

Несмотря на то, что моё мнение о микрософтовском Visual Studio по-прежнему остаётся невысоким, иногда приходится что-то делать и на нём. Если смириться с тем, что пишем мы при этом, собственно, не на C++, а на так называемом C++/CLI, работа с привычными визуальными компонентами будет не так уж сильно отличаться от тех же Борландовских сред. А вот взаимодействие форм и модулей способно, по сравнению с Builder'ом, создать проблемы. Рассмотрим 3 типовых ситуации работы с приложением, содержащим больше одной формы. Среда примера - бесплатная Visual C++ 2010 Express, предполагается, что главная форма имеет имя по умолчанию Form1 .

Пример конструирования и программного вызова формы

Этот код можно выполнить, например, по нажатию кнопки в главной форме Form1.

Для добавления обработчика нажатия программно сгенерированной кнопки button2 достаточно перед последней строкой кода написать:

- до того, как будет вызван метод form2->ShowDialog() или form2->Show();

При этом код обработчика размещён в текущем модуле Form1.h :

Вызвать другую форму из главной формы

В меню выберем Проект - Добавить новый элемент - Форма - имя Form2

перед первым namespace в Form1.h (то есть, в самое начало файла).

Включим указатель на экземпляр класса в секцию public класса Form1 :

Добавим код там, где нужно создать и вызвать вторую форму:

Для программного удаления второй формы подойдёт код

Следует учесть, что указатель хранит адрес только одной формы, той, что создана последней. Если мы последовательно создали таким кодом несколько форм, удалена будет только последняя из них. Как вариант попробуйте массив форм, описанный ниже.

Опишем нужные данные в классе формы Form1 (здесь имя и namespace проекта Tabulator , если нужно, замените на своё):

Потом инициализируем данные по событию Load главной формы:

Затем реализуем код для создания очередной формы

Если мы хотим создавать дочерние формы не отдельно, а внутри родительской формы, то в свойствах Form1 нужно указать, что она "предок" (установить свойство IsMdiParent = true ), а перед показом дочерней формы оператором F2[FormCount-1]->Show() пометить её как потомка Form1:

Вызвать из дочерней формы метод родительской формы

Нам едва ли обойтись без привлечения файлов .cpp, что неплохо - писать код в файлах .h правильного Си'шника вообще ломает :)

Распишем процесс по шагам.

1) Имеются 2 формы - Form1 и Form2 , на Form1 располагаются Button ( button1 , будет открывать вторую форму) и Label ( label1 , здесь будем менять текст). На Form2 - button1 , по нажатию на которую будет происходить смена текста в label1 .

2) Так как нам из первой формы нужно иметь доступ ко второй, а из второй к первой, то будет возникать проблема перекрестных ссылок (когда Form1.h ссылается на Form2.h , который, в свою очередь, опять ссылается на Form1.h ). Для того, чтобы этого избежать, код первой формы ( Form1 ), который будет иметь доступ ко второй форме ( Form2 ), мы вынесем из .h-файла в .cpp файл. Таким образом нужно создать файл Form1.cpp .

4) В файле Form2.h подключаем Form1.h (в начале):

и создаем конструктор, который будет принимать и сохранять ссылку на первую форму для дальнейшего использования: //ниже сразу ниже можно прописать ссылку: private: Form1^ parentForm;

5) По клику кнопки в Form2 будем вызывать метод Set родительской формы:

6) Осталось в первой форме сделать открытие второй формы. Для этого из Form1.h обработчик нажатия кнопки переносим в Form1.cpp , а в .h-файле оставляем только его объявление.

Код в файле Form1.cpp :

В Form1.h вставляем только строку:

На этом все. Можно скомпилировать и проверить проект, архив во вложении:

Наладить взаимодействие двух форм

На самом деле, просто развитие идеи. Здесь первая форма умеет передавать данные в текстовое поле второй и наоборот. Теперь они друг друга не "прячут", так что можно создать и много экземпляров второй формы.

Как лучше всего скопировать или вырезать/пропустить форму из одного проекта в другой проект в решении в Visual Studio?

скопируйте три файла, .cs , .designer , resx в папку целевого решения.
в целевом проекте выберите Add existing item и сначала добавьте файл конструктора.
измените атрибут пространства имен. The .cs файл также должен войти.
измените пространство имен в .
добавить resx файл с помощью Add existing item .

чтобы скопировать форму из одного проекта VS2013 в другой, самый простой (наименьшее количество щелчков мыши):

в вашем целевом проекте щелкните правой кнопкой мыши на родительской папке (вероятно, ваш проект) и в меню выберите "Добавить; существующий элемент".

затем выберите cs-файл формы в исходном проекте. Например, выберите форму.в CS (не в форме.Дизайнер.cs или форма.resx файл).

Открыть Форму.CS в проект и измените пространство имен (все экземпляры).

закрыть и снова открыть форму.CS и вы увидите все элементы управления и т. д.

понял это-знал, что это будет что-то глупое.

по-видимому, целевой проект должен иметь ссылки:

теперь это намного проще в 2012 году. Просто перейдите в Файл > Добавить > существующий проект > перетащите форму в проект, в который вы хотите ее добавить.

убедитесь, что вы копируете не только форму.cs, но и форма.дизайнер.cs и форма.файлы resx.

но мне нужно спросить, почему вы хотите сохранить копию одной и той же формы в нескольких проектах в одном и том же решении. Звучит так, как будто вы можете обобщить код в нем, поместить его в библиотеку классов и повторно использовать его в тех местах, где он применим.

использовать ReSharper (получите демонстрацию), щелкните правой кнопкой мыши класс В представлении кода, рефакторинг - >переместить и переместите его в другой проект.

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

Я попробовал следующий процесс в Visual Studio 2012 и это сработало.

добавьте проект, из которого вы хотите импортировать форму в свое решение, щелкнув правой кнопкой мыши решение > добавить > существующие меню проекта. Выберите проект и нажмите ОК.
Теперь щелкните правой кнопкой мыши на форме, которую вы хотите скопировать, выберите команду копировать.
щелкните правой кнопкой мыши проект, в который вы хотите скопировать, и выберите Вставить.
форма будет скопирована в ваш проект, теперь переименуйте пространство имен.
удалите проект, добавленный на шаге 1, из вашего решения.

для Visual Studio V. 12 это единственный метод, который работал для меня (это смесь вышеуказанных записей):

скопируйте через проводник файлов три файла, которые составляют форму.
в верхней панели обозревателя решений в Visual Studio включите "показать все файлы".
файл.файл cs отображается серым цветом. Нажмите правую кнопку и выберите: "Включить в проект". Обозреватель решений автоматически связывает три файла (.дизайнер и. resx файл под .цезий папка.) Папка.cs изменить значок с c++ на значок формы.

вы выбираете файл или используете конструктор для "копирования" всех элементов управления? Выбор YourForm.cs файл в обозревателе решений и копирование его с помощью копирования и вставки или перетаскивания в другой проект должны выполнить то, что вам нужно.

* * Это работает для меня:

1) скопируйте исходные файлы (.cs или vb,.проектировщик. ,resx файл) в папку

2) Показать скрытые файлы в целевом решение

3) Выберите эти файлы и включите их в проект.

Это добавит winform или любые другие частично разделенные файлы чисто.

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

(1-й) в Проводнике файлов Windows Выделите и скопируйте все 3 файла формы (.vb or .цезий. ,проектировщик. ,resx файл)

(2-ой) это может быть достигнуто 2 способами:

(2a-1) в Проводнике вставьте 3 файла в папку проекта с другими формами

(2a-2) в VS Обозреватель решений, включите "показать все файлы", щелкните правой кнопкой мыши на вставленной форме и "включить в проект". Он должен работать без изменений.

или, я думаю, что лучше:

(2b-1) в VS щелкните в обозревателе решений и вставьте w/Control-C. (По какой-то причине контекстное меню правой кнопки мыши в обозревателе решений может не отображать параметр вставки, но он работает с клавиатуры.) Этот метод добавляет форму в проект напрямую, без необходимости включать в проект как выше. С помощью этого метода вы можете добавить столько форм в то время, как вам нравится (все 3 файла для каждого) в один шаг.

Как лучше всего скопировать или вырезать / вставить форму из одного проекта в другой в рамках решения в Visual Studio?

21 ответ

Скопируйте три файла, .cs , .designer , resx в папку целевого решения.
В целевом проекте выберите Add existing item и сначала добавьте файл дизайнера.
Измените атрибут пространства имен. Также должен появиться файл .cs .
Измените пространство имен в файле .cs .
Добавьте файл resx , используя Add existing item .

Чтобы скопировать форму из одного проекта VS2013 в другой, самый простой (наименьшее количество щелчков мышью):

В вашем целевом проекте щелкните правой кнопкой мыши родительскую папку (вероятно, ваш проект) и в меню выберите «Добавить; существующий элемент».

Затем выберите файл cs формы в исходном проекте. Например, выберите Form.cs (а не Form.Designer.cs или Form.resx).

Откройте Form.cs в вашем целевом проекте и измените пространство имен (все экземпляры).

Закройте и снова откройте Form.cs, и вы увидите все элементы управления и т. Д.

Разобрался - знал, что это будет что-то глупое.

Очевидно, на целевой проект должны быть ссылки:

Включены в проект ПЕРВЫМ, прежде чем вы сделаете какое-либо копирование или вставку, иначе вы столкнетесь с проблемой, которую я описал.

Спасибо всем, кто пытался помочь BTW.

В 2012 году это стало намного проще. Просто перейдите в меню «Файл»> «Добавить»> «Существующий проект»> «Перетащите» форму в проект, в который вы хотите ее добавить.

Я попробовал следующий процесс в Visual Studio 2012, и он сработал.

Добавьте проект, из которого вы хотите импортировать форму, в свое решение, щелкнув правой кнопкой мыши решение> Добавить> Существующие меню проекта. Выберите проект и нажмите ОК.
Теперь щелкните правой кнопкой мыши форму, которую вы хотите скопировать, выберите копию.
Щелкните правой кнопкой мыши проект, который вы хотите скопировать, и выберите «Вставить».
Форма будет скопирована в ваш проект, теперь переименуйте пространства имен.
Удалите из решения проект, добавленный на шаге 1.

Убедитесь, что вы копируете не только Form.cs, но также файлы Form.designer.cs и Form.resx.

Но мне нужно спросить, зачем вам хранить копию одной и той же формы в нескольких проектах в одном решении. Похоже, вы хотите обобщить код в нем, поместить его в библиотеку классов и повторно использовать в тех местах, где это применимо.

Используйте ReSharper (получите демонстрацию), щелкните правой кнопкой мыши класс в представлении кода, выберите Refactor-> Move , и переместите его в другой проект.

Дополнительным преимуществом является то, что если вы измените пространство имен, перемещая его между проектами, оно автоматически обновит все ссылки.

Если вы хотите формовать на одной машине, вы можете это сделать.

В обозревателе решений Проект -> Добавить -> Добавить существующий элемент .

Выберите только файл .cs (Sample.cs) из исходного каталога и обновите проводник текущего решения, он будет работать.

Я наконец понял следующее:

Для Visual Studio V.12 это единственный метод, который у меня сработал (это смесь приведенных выше записей):

Скопируйте через проводник файлов три файла, из которых состоит форма.
На верхней панели обозревателя решений в Visual Studio включите «показывать все файлы».
Файл file.cs отображается серым цветом. Щелкните правой кнопкой мыши и выберите: «Включить в проект». Обозреватель решений автоматически связывает три файла (.designer и .resx в файле .cs). Файл file.cs изменит значок с c ++ на значок формы.

Я использую Visual Studio 2010, вот шаги, которые я выполнил:

Скопируйте все 3 файла (.cs, .resx, .Designer.cs) в папку целевого проекта.
В Visual Studio щелкните правой кнопкой мыши Проект ->Добавить ->Существующий элемент .
Выберите все 3 файла (.cs, .resx, .Designer.cs), нажмите Добавить .
Измените пространство имен на 2 файлах (.cs, .Designer.cs), если это другое пространство имен в целевом проекте.
Запустите проект.
Выполнено!

Вы выбираете файл или используете дизайнер, чтобы «скопировать» все элементы управления? Выбор файла YourForm.cs в обозревателе решений и его копирование с помощью копирования и вставки или перетаскивания в другой проект должны выполнить то, что вам нужно.

** Это работает для меня:

1) Скопируйте исходные файлы (.cs или vb, .designer, .resx) в целевую папку.

2) Показать скрытые файлы в целевом решении

3) Выберите эти файлы и включите их в проект.

Это чисто добавит winform или любые другие частично разделенные файлы.

Использование VS2013 только что проверило это, и оно кажется надежным и последовательным. Это похоже на некоторые комментарии выше, но добавляет еще один более быстрый метод.

(1-й) . В проводнике Windows выделите и скопируйте все 3 файла формы (.vb или .cs, .designer, .resx).

(2-й) Это можно сделать двумя способами:

(2a-1) В проводнике вставьте 3 файла в папку проекта вместе с другими формами.

(2a-2) В обозревателе решений VS включите «Показать все файлы», щелкните правой кнопкой мыши вставленную форму и «Включить в проект». Он должен работать без других изменений.

Или, мне кажется, лучше:

(2b-1) В VS щелкните в обозревателе решений и вставьте w / Control-C. (По какой-то причине контекстное меню, вызываемое щелчком правой кнопкой мыши в обозревателе решений, может не отображать параметр вставки, но он работает с клавиатуры.) Этот метод добавляет форму в проект напрямую, без необходимости «Включить в проект», как указано выше. С помощью этого метода вы можете добавить столько форм за раз, сколько захотите (все 3 файла для каждой) за один шаг.

Я пробовал следующие шаги, и все сработало нормально.

скопируйте все 3 файла и файлы значков (если есть) в целевой проект.
Теперь перейдите в обозреватель решений проекта и щелкните значок Показать все файлы в верхней части sol.explorer.
теперь вы можете видеть ваши недавно добавленные файлы, отображаемые в вашем проекте.

Если вы используете VS 2015, вам просто нужно добавить файл «.vb» и изменить пространство имен на новое имя проекта.

Пример: если вы хотите добавить «Form1», созданную с помощью VS2008, в новый проект, созданный с помощью VS2015.

Скопируйте все файлы ".vb", ".resx", ".disigner.vb" в новую папку проекта.
Затем измените пространство имен файла ".disigner.vb", используя новое имя проекта.

Эти два шага сработали для меня.

В Visual Studio 2015 щелкните проводник решений и щелкните правой кнопкой мыши Добавить-> Существующий элемент и выберите из другого проекта, какую форму вы хотите добавить, например Form.cs и автоматически будет добавлен Form.designer.cs, Form.resx

Если вам нужно использовать одну и ту же форму в разных проектах, решения следующие: Создайте «Проект библиотеки классов», в этот проект вы добавите формы, которыми вам нужно поделиться, а затем просто добавьте ссылку на dll в свой основной проект, вы может легко ссылаться на формы. Его работы идеально подходят для меня

Самый простой способ, который я нашел для этого, - это:

Создайте форму с таким же именем в своем новом проекте
Добавьте кнопку или другой элемент управления в новую форму (при этом создается файл .resx)
Сохраните и закройте ваш новый проект
Скопируйте файлы MyForm.cs, MyForm.designer.cs, MyForm.resx из старого проекта, чтобы перезаписать новый проект.
ПЕРЕД открытием нового проекта в VS отредактируйте пространства имен в MyForm.cs и MyForm.designer.cs с помощью текстового редактора, чтобы они соответствовали пространству имен вашего нового проекта.
На этом этапе вы можете открыть новый проект в VS, и все должно выглядеть правильно.

Мне никогда не удавалось скопировать файлы и «добавить существующий элемент», потому что иерархия, похоже, не восстанавливается. Может быть, сначала добавить .designer.cs, как предложил другой пользователь? В любом случае, если вы попробуете это сделать, вы можете вручную отредактировать файл .csproj нового проекта, чтобы включить в него записи иерархии из исходного проекта, которые выглядят примерно так:

Стоит отметить, что очень легко скопировать элементы управления между формами в двух разных проектах. Просто выберите и Ctrl + C в исходном проекте, затем выберите форму в новом проекте и Ctrl + V.

Ни один из этих «автоматических» вариантов не работал у меня в VS2019. Конструктор форм всегда будет пустым, а вставленные файлы некорректно объединяются в обозревателе решений. То, как я сделал это в VS2019, состояло из следующих 3 шагов:

Скопируйте файлы формы в каталог нового проекта с помощью проводника Windows. Например, эти 3 файла:

StartForm.cs
StartForm.Designer.cs
StartForm.resx

Если ваше пространство имен отличается, откройте оба файла .cs в блокноте и измените пространства имен на новое пространство имен. (Используйте ctrl + F, чтобы не пропустить ни одной ссылки) Мне не пришлось этого делать, потому что мое пространство имен было таким же в моем новом проекте.

Отредактируйте оба файла csproj в Блокноте и скопируйте ссылки на эти файлы из одного файла csproj в новый файл csproj. Например, вот что мне пришлось скопировать:

После этого, если у вас открыт новый проект в VS, он распознает изменение и спросит, хотите ли вы перезагрузить.

Зайдите в визуальную студию и настройте свой новый проект. В выбранном месте назначения будет создан новый файл.

Теперь перейдите к исходному файлу, данные которого вы хотите экспортировать в только что созданный проект. Скопируйте все файлы из исходного файла.

Перейдите в папку нового проекта и вставьте туда все файлы.

Теперь, когда эти файлы уже присутствуют там, будет показана возможность заменить новый файл проекта. просто нажмите на замену существующих файлов.

Как правило, каждая версия 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, чтобы проекты, создаваемые в одной версии 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 2019, Visual Studio 2017, Visual Studio 2015, Visual Studio 2013 и Visual Studio 2012. Однако поддержка некоторых типов проектов также со временем меняется. Новейшая версия Visual Studio может не поддерживать некоторые проекты или же потребовать обновить проект так, что он больше не будет обратно совместимым.

Некоторые типы проектов требуют конкретных рабочих нагрузок. При отсутствии установленной рабочей нагрузки Visual Studio сообщает о неизвестном или несовместимом типе проекта. В этом случае проверьте параметры установки в Visual Studio Installer и повторите попытку. Дополнительные сведения о поддержке проектов в Visual Studio 2022 см. в статье Целевая платформа и совместимость.

Типы проектов

В следующем списке описывается поддержка проектов Visual Studio 2022, созданных в более ранних версиях.

Теперь проекты моделирования называются в меню и шаблонах проектами проверки зависимостей.
UML-схемы больше не поддерживаются в Visual Studio 2017 и Visual Studio 2019. UML-файлы указываются в обозревателе решений, как и ранее, но открываются как XML-файлы. Для просмотра, создания или изменения UML-схем следует использовать Visual Studio 2015.
В Visual Studio 2019 проверка архитектурных зависимостей больше не выполняется при сборке проекта моделирования. Вместо этого проверка осуществляется при сборке каждого проекта кода. Это изменение не влияет на проект моделирования, но необходимо внести изменения в проверяемые проекты кода. Visual Studio 2019 автоматически вносит необходимые изменения в проекты кода.

Миграция проекта

Хотя мы пытаемся сохранить совместимость с предыдущими версиями, существуют изменения, из-за которых некоторые типы проектов могут больше не поддерживаться. В таких случаях в более новой версии 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 предпринимается попытка обработать их корректно, не повреждая их, чтобы проект по-прежнему мог открываться в предыдущих версиях;

Читайте также: