Visual studio как скопировать проект

Обновлено: 06.07.2024

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

21 ответ

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

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

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

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

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

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

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

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

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

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

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

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

  1. Добавьте проект, из которого вы хотите импортировать форму, в свое решение, щелкнув правой кнопкой мыши решение> Добавить> Существующие меню проекта. Выберите проект и нажмите ОК.
  2. Теперь щелкните правой кнопкой мыши форму, которую вы хотите скопировать, выберите копию.
  3. Щелкните правой кнопкой мыши проект, который вы хотите скопировать, и выберите «Вставить».
  4. Форма будет скопирована в ваш проект, теперь переименуйте пространства имен.
  5. Удалите из решения проект, добавленный на шаге 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, вот шаги, которые я выполнил:

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

Вы выбираете файл или используете дизайнер, чтобы «скопировать» все элементы управления? Выбор файла 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 файла для каждой) за один шаг.

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. Скопируйте файлы формы в каталог нового проекта с помощью проводника 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 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.)

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

есть ли инструмент в VS, чтобы сделать это? Я использую VS 2008

Если вам нужна копия, самый быстрый способ сделать это-сохранить проект. Затем сделайте копию всего этого в файловой системе. Вернитесь в Visual Studio и откройте копию. Оттуда я бы, скорее всего, рекомендовал переименовать проект/решение, чтобы у вас не было двух одинаковых имен, но это самый быстрый способ сделать копию.

  • имя шаблона
  • Описание Шаблона
  • значок
  • предварительный просмотр изображения
  1. перейти к проекту, который вы хотите скопировать в Обозреватель решений и щелкните правой кнопкой мыши.
  2. Теперь выберите 'открыть папку в Проводнике' (если у вас есть решение, сопоставленное с локальным путем на вашем диске).
  3. выберите проекты, которые вы хотите реплицировать как целые папки (вместе со всеми зависимостями,bin .файл vspscc, .csproj file)
  4. вставьте их в нужное место (это может быть та же папка решения или даже другая папка решения. Если он находится в той же папке решения, тогда вам потребуется переименовать его, а также.csproj и другие внутренние файлы с новым именем).
  5. нет вернуться в Visual Studio,щелкните правой кнопкой мыши на решение > добавить > существующий проект.
  6. обзор и выберите файл проекта (.csproj file) теперь из того места, где вы его разместили, и выберите'открыть'
  7. этот файл теперь отображается в обозревателе решений для вас работа.

лучший способ на самом деле создать новый проект с нуля, а затем перейти в папку с файлами проекта, которые вы хотите скопировать (project, form1, все, кроме папок). Переименуйте файлы (за исключением файлов form1) например: я скопировал файлы Ch4Ex1 в свой проект Ch4Ex2, но сначала переименовал файлы в Ch4Ex2. Скопируйте и вставьте эти файлы в Обозреватель решений для нового проекта в Visual Studio. Тогда просто перепишите файлы, и вы должны быть хорошо идти!

старый нить, но я надеюсь, что это поможет всем, кто ищет этот ответ!

У меня есть проект, где исходные файлы находятся в папке под папкой проекта. Когда я скопировал папку проекта без исходной папки и открыл скопированный проект, исходные файлы не отсутствуют, а находятся в старом месте. Я закрыл проект, скопировал также исходную папку и снова открыл проект. Теперь проект волшебным образом ссылается на скопированные исходные файлы (как новый путь появился на "Сохранить как", так и изменение файла было сохранено в скопированном файле версия.)

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

Я пробовал это с VS Express 2012.

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

что я сделал (в VS 2008), чтобы открыть следующие файлы в мой каталог:

когда я это сделал, всплывающее окно спросило меня, будет ли файл sln новым решением, и когда я нажал "да", все работало отлично.

после попытки выше решений и создания копии для проектов MVC

для проектов MVC обновите номера портов .csproj файл, вы можете воспользоваться помощью iis applicationhost.конфигурация для проверки номеров портов. Те же номера портов вызовут проблему загрузки сборки в IIS.

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

есть ли инструмент в VS для этого? Я использую VS 2008

Если вам нужна копия, самый быстрый способ сделать это-сохранить проект. Затем сделайте копию всего этого в файловой системе. Вернитесь в Visual Studio и откройте копию. Оттуда я бы, скорее всего, рекомендовал переименовать проект/решение, чтобы у вас не было двух одинаковых имен, но это самый быстрый способ сделать копию.

просто создайте шаблон;

из вашего проекта выбрали File-Export Template

мастер позволит вам определить

  • имя шаблона
  • Описание Шаблона
  • значок
  • предварительный просмотр изображения

затем он застегивает ваш проект в каталог "мои экспортированные Шаблоны". У вас также есть возможность сделать шаблон доступным при создании нового проекта.

когда вы используете ваш шаблон для создания нового проекта пространство имен будет правильным для "your_new_project_name" во всем файле, все ссылки правильны, все perfecto:)

Примечание:
Если у вас есть пустая папка в вашем проекте, она не будет добавлена в шаблон, поэтому я просто добавил пустой класс, соответствующий каждой папке, и образец изображения для папки изображений.

Я думаю, если это то, что вы часто делаете, есть небольшая (несвободная) утилита, которая обещает сделать это за вас: я не использовал ее, поэтому не уверен, насколько она хороша:

существует также этот проект на CodePlex:

Я, вероятно, дам проекту codeplex попробовать, и если он не работает, я вручную переименую все и отредактирую sln файл.

Я выполняю эти шаги, и я использую инструмент разработки под названием для ReSharper ,который является удивительным, кстати:

весьма НЕ РЕКОМЕНДУЕТСЯ копировать проекты вообще, потому что некоторые файлы конфигурации сформированы внутри, как .csproj файл, .vspscc все etc. может (и, скорее всего, будет) указывать на ссылки, которые принадлежат местоположению предыдущих решений и другим путям/местоположениям в системе или TFS. Если вы не являетесь экспертом в чтении этих файлов и исправлении ссылок, не пытайтесь копировать проекты.

можно создать скелетный проект того же типа, который вы собираетесь скопировать, это создает правильное .csproj файл, .vspscc все файлы. Теперь вы можете копировать файлы классов, скрипты и другой контент из предыдущего проекта, так как они не будут влиять. Это обеспечит плавную сборку и контроль версий (если вы решите быть заинтересованы в этом)

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

  1. перейти к проекту, который вы хотите скопировать в Обозреватель решений и щелкните правой кнопкой мыши.
  2. Теперь выберите 'открыть папку в Проводнике' (предполагая, что у вас есть решение, сопоставленное с локальным путем на вашем диске).
  3. выберите проекты, которые вы хотите реплицировать как целые папки(вместе со всеми зависимостями, bin .файл vspscc, .файл csproj)
  4. вставьте их в нужное место (это может быть та же папка решения или даже другая папка решения. Если он находится в той же папке решения, тогда вам потребуется переименовать его, также .csproj и другие внутренние файлы на новое имя).
  5. нет возврата в Visual Studio,щелкните правой кнопкой мыши решение > добавить > существующий проект.
  6. просмотр и выбор файла проекта (.csproj file) теперь из места, в котором вы его разместили, и выберите"открыть'
  7. этот файл теперь отображается в обозревателе решений для вас работа.

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

лучший способ - создать новый проект с нуля, а затем перейти в папку с файлами проекта, которые вы хотите скопировать (project, form1, все, кроме папок). Переименуйте файлы (за исключением файлов form1), например: я скопировал файлы Ch4Ex1 в свой проект Ch4Ex2, но сначала переименовал файлы в Ch4Ex2. Скопируйте и вставьте эти файлы в Обозреватель решений для нового проекта в Visual Studio. Тогда просто перепишите файлы, и вы должны быть хорошо идти!

старый нить, но я надеюсь, что это поможет любому, кто ищет этот ответ!

У меня есть проект, где исходные файлы находятся в папке под папкой проекта. Когда я скопировал папку проекта без исходной папки и открыл скопированный проект, исходные файлы не отсутствуют, а находятся в старом расположении. Я закрыл проект, скопировал также исходную папку и снова открыл проект. Теперь проект волшебным образом ссылается на скопированные исходные файлы (как новый путь появился на "Сохранить как", так и изменение файла было сохранено в скопированном версия.)

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

Я пробовал это с VS Express 2012.

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

что я сделал (в VS 2008), чтобы открыть следующие файлы в мой каталог:

когда я это сделал, всплывающее окно спросило меня, будет ли файл sln новым решением, и когда я нажал "да", все сработало отлично.

после попытки выше решений и создания копии для проектов MVC

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