Как перенести проект visual studio на другой компьютер

Обновлено: 04.07.2024

У меня есть среда разработки Visual Studio 2012 на моем PC.

Я хочу перенести его на новый ноутбук для путешествий.

Старые файлы проекта находятся в разделе E:.

Я не хочу создавать раздел E: на ноутбуке, потому что считаю, что недавно действительно испортил windows 8.1 на ноутбуке (я уже делал это однажды), и мне пришлось переустановить Windows на новый диск, поставляемый Dell (не спрашивайте; тьфу!)

Вопрос: есть ли у Visual studio способ перенести проект и изменить букву диска путей в решении?

2 ответа

Простой вопрос, для которого я не мог найти ни установки, ни ответа: Я переместил папку Документы в Windows на другой диск. Как изменить путь к папке Мои фрагменты кода в Visual Studio 2012 с заданного по умолчанию на новое местоположение? Значение по умолчанию находится в папке Мои документы.

вот проблема, с которой я сейчас столкнулся. Я создал приложение, которое использует локальную базу данных (это было создано с помощью Add - > New Item - > Local Database . После этого я добавил таблицы в эту базу данных .sdf. Затем я подключился к этой базе данных с помощью Add -> New Item ->.

Если вы что-то не испортили, все пути проекта VS хранятся как относительные. Просто скопируйте папку, и она будет работать.

В дальнейших исследованиях я нашел обходной путь.

Файл .sln доступен для редактирования текста. Если вы отредактируете путь к проекту верхнего уровня, проект будет загружен.

Что касается первоначального вопроса : "предлагает ли Microsoft автоматический способ переноса проектов", я еще не нашел ответа на этот вопрос.

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

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

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

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

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

GUID проекта обновляется VS автоматически, если в том же решении существует другой проект с таким же GUID. Я пытаюсь это сделать, но он не переименовывает пространства имен приложений. Не то, что я искал. GUID проекта НЕ ОБНОВЛЯЕТСЯ АВТОМАТИЧЕСКИ VS in Community 2017 Версия 15.8.4. На самом деле, как это могло быть, если ваш AssemblyInfo.cs находится в управлении исходным кодом?

В вашем проекте выберите: Project - Export Template

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

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

Затем он архивирует ваш проект в каталог «Мои экспортированные шаблоны». У вас также есть возможность сделать ваш шаблон доступным при создании нового проекта.

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

ПРИМЕЧАНИЕ.
Если в вашем проекте есть пустая папка, она НЕ будет добавлена в шаблон, поэтому я просто добавил пустой класс, соответствующий каждой папке, и образец изображения для папки изображений.

В VS2017 шаблон экспорта находился в пункте меню верхнего уровня Project. Это невероятно полезно, как я не знал об этом раньше? Благодарность! Это должен быть выбранный ответ. Очень просто! Этот процесс также должен был скопировать его в вашу папку Templates \ ProjectTemplates, просто убедитесь. Мне пришлось перезапустить Visual Studio, чтобы увидеть это в диалоговом окне создания проекта. Когда пришло время импортировать шаблон для создания нового проекта, я не мог понять, как это сделать. Оказалось, что мне пришлось использовать панель поиска в диалоговом окне «Новый проект», чтобы найти шаблон.

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

На CodePlex также есть этот проект:

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

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

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

Сказав все это, позвольте мне дать вам метод пошагового копирования проекта:

В обозревателе решений перейдите к проекту, который хотите скопировать, и щелкните правой кнопкой мыши .
Теперь выберите « Открыть папку в проводнике » (если у вас есть решение, сопоставленное с локальным путем на вашем диске).
Выберите проекты, которые вы хотите реплицировать как целые папки (вместе со всеми зависимостями, файл bin .vspscc, файл .csproj)
Вставьте их в желаемое место (это может быть та же папка решения или даже другая папка решения. Если она находится в той же папке решения, вам потребуется переименовать ее, а также .csproj и другие внутренние файлы на новое имя. ).
Не возвращайтесь в Visual Studio, щелкните правой кнопкой мыши «Решение»> «Добавить»> «Существующий проект» .
Найдите и выберите файл проекта (файл .csproj) в том месте, где вы его разместили, и выберите « открыть ».
Теперь этот файл появится в обозревателе решений, чтобы вы могли работать.

Обновление: лучший ответ по состоянию на 2019 год - это тот, который ниже @Shane. Создание шаблонов VS - идеальный способ клонировать проекты без проблем со ссылками.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Расшарить между компьютерами какой-либо документ — просто. Предоставить удаленный доступ к рабочему столу — нет проблем. Но почему-то до сих пор нельзя просто «поделиться» запущенным приложением — взять и быстро перенести его окно из одной системы в другую. С появлением проекта WinSwitch это стало возможным.

Что такое WinSwitch?

Если ты часто имеешь дело с виртуальными машинами, то наверняка знаешь о такой замечательной возможности как перенос окон из гостевой операционной системы, запущенной в виртуальном окружении, в хостовую ОС (основную систему на компьютере). То есть если на виртуальной машине крутится винда, а сама виртуальная машина работает на Ubuntu, то любые запущенные приложения можно «перенести» из Windows в Ubuntu. Что самое прикольное, — они будут работать так, как если бы были запущены самым обычным способом. У меня давно возникла идея реализовать что-то подобное, но не в плоскости виртуальной машины, а с точки зрения протоколов для доступа к удаленному рабочему столу. RDP или VNC без проблем позволяют получить картинку с компьютера, который может находиться за тысячи километров, и вполне комфортно с ним взаимодействовать. Но зачем нужна картинка полного рабочего стола, когда работать приходится с одним или двумя конкретными приложениями? Ведь можно же отображать только их окна? Удивительно, но реализации такой простой идеи долго не было. Пока не появился WinSwitch!

Запуск приложения на локальном WinSwtich сервере через контекстное меню

Как это выглядит? Запустив какое-либо приложение через специальный сервер, ты сможешь напрямую перенести его на любое устройство, где будет установлен соответствующий клиент. Тут нужно понимать — не файлы приложения, а именно окно программы, с которым можно работать. Теперь, если нужно продолжить работу над текущим документом в Microsoft Word или, скажем, над проектом в Visual Studio на другом компьютере, можно просто «перетащить» туда окно. А поскольку проект кроссплатформенный, то это еще и отличный способ работать с приложением в том случае, когда для нужной системы нет подходящей версии. Или вот еще пример: у меня дома рядом стоят компьютер на Windows и ноутбук на Ubuntu, — теперь я без проблем могу перекидывать приложения с одной системы на другую (ну и с одного экрана на другой). Хоть даже Visual Studio. В результате можно расшарить не документ, а приложение.

Успешное соединение с удаленным сервером ant-vb

Установка

Теперь, когда понятно, о чем идет речь, попробуем WinSwitch в действии. Для примера организуем связь между двумя машинами, выбрав в качестве плацдарма две разных ОС — Ubuntu Natty Narwhal (11.04) и Windows XP.

Запуск приложения на локальном WinSwitch сервере

Linux. Я, как уже было отмечено выше, буду использовать Ubuntu, но, само собой, подойдет и любой другой дистрибутив тукса. В убунте приложение можно установить через менеджер пакетов, предварительно прописав цифровую подпись репозитория с нужными нам пакетами:

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

Настройка

WinSwitch состоит из двух частей: сервера и клиента (так называемого апплета). Клиент необходим в системе, чтобы в нее можно было «перетащить» приложения — его можно запустить сразу после установки через меню. Также при старте апплета автоматически запускается локальный сервер, чтобы иметь возможность расшарить приложения с локальной машины. При запуске клиент пытается определить все доступные сервера в сети при помощи mDNS.

Подключение у удаленному рабочему столу Ubuntu через VNC

Конфигурирование как клиента, так и сервера осуществляется через конфигурационные файлы. При первом запуске программа создает необходимые папки и генерирует конфиги, что может занять некоторое время. Как только программа запустилась, идем искать конфиги сервера. В *nix они будут в папке

/.winswitch/server/server.conf, а в Windows — *\Application Data\Window-Switch\server\server.conf. Рассмотрим наиболее важные для нас параметры. Каждый сервер имеет свой идентификатор, имя и тип, — все это автоматически генерируется при запуске и выглядит примерно так:

Тут можно все оставлять без изменений. Далее в конфиге идут публичный и приватный ключи, используемые для шифрования трафика. Нас же, прежде всего, будет интересовать параметр listen_on, определяющий, на каком интерфейсе и порту сервер будет ожидать подключений. Его, в принципе, тоже можно оставить в состоянии «по умолчанию», но я для порядка все же поставил listen_on="*:32123" (это означает, что сервер будет ожидать подключения на 32123 порту на всех сетевых интерфейсах). Далее идет еще один интересный параметр allow_root_logins, который в целях безопасности рекомендуется установить в значение False. Он определяет, можно ли будет подключиться к данному серверу под администратором/рутом. Параметр allow_root_authentication дает возможность соединиться с сервером под любым пользователем, не зная его пароля. Его я тоже отключил из соображений безопасности. Следующая интересная секция — mDNS settings — позволяет включать/отключать сервис mDNS, используемый для того, чтобы клиенты при запуске могли самостоятельно находить в сети доступные сервера. Если установить параметр mDNS_publish в значение False, то автоматический поиск серверов будет отключен и их придется добавлять вручную. Чтобы клиенты обнаруживали не только сервера, но и имя пользователя, под которым можно зайти, есть опция mDNS_publish_username. Еще одна полезная возможность — запуск сервера в режиме отладки — может сильно помочь, когда надо прояснить, почему что-то не работает. Остальные опции в случае необходимости ты можешь изучить сам, так как они достаточно хорошо прокомментированы в самом файле.

Сапер, "отправленный" из другой операционной системы

Тест-драйв

Ручной запуск Avahi-демона

Надо сказать, что WinSwitch уже содержит список предопределенных приложений, рассортированных по категориям, которые можно расшарить. Но можно запустить и свое приложение, если выбрать «Start Application -> Custom Command». Для удобства эта фича также интегрируется в контекстное меню, так что будет достаточно выбрать нужную программу, щелкнуть по ней правой клавишей и выбрать «Open in Window Switch». Кроме приложений, можно получить доступ к самому рабочему столу («Main Unix Display -> VNC Copy»). Помимо непосредственно окна можно форвардить также и звук (для этого используется библиотека GStreamer).

Ручное добавление сервера для подключения

Отладка

Я не зря сделал выше ремарку «в идеальном случае», — с первого раза у меня система не запустилась. Нажав на значок апплета в трее, я понял, что он видит только локальный сервер. Можно, конечно, добавить сервер вручную, но тогда весь смысл автоматизации теряется. Поэтому вернусь к этому моменту и расскажу, в чем было дело.

В результате вываливаемся с ошибкой:

/.winswitch/client/applet.log. Там тоже обнаруживаются записи, свидетельствующие о наличии проблем с mDNS. Записей о других критических ошибках — не обнаружено. Так как проблему с mDNS мы уже решили, запустив демон ahavi, то теперь вроде бы все должно быть нормально. Выключаем сервер, который мы запустили вручную, и идем в меню, чтобы запустить апплет. Бинго! С этого момента все заработало.

На данной вкладке можно настроить используемые протоколы

Что такое mDNS?

Использовать или нет?

WinSwich – это вполне работоспособная реализация отличной идеи, которую я успешно использую уже несколько недель. Уверен, что очень скоро появятся коммерческие проекты, эксплуатирующие подобный подход, но уже с более человеческим интерфейсом, простой настройкой и — в идеальном варианте — прозрачным переносом окон из одной системы в другую (на случай, если два компьютера стоят рядом). Последнее несложно реализовать, если скомбинировать проект WinSwitch и Direct Input, позволяющий расшарить между стоящими рядом компьютерами клавиатуру и мышку.

Полный доступ к удаленному рабочему столу Windows-машины из-под Ubuntu

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

Как перенести проект visual studio на другой компьютер

2 ответа

Похожие вопросы:

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

Как Visual Studio определяет необходимость переноса проекта

Следующие шаги

См. также

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

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

Следующие шаги

См. также

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

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

Что такое WinSwitch?

Установка

Настройка

Тест-драйв

Отладка

Что такое mDNS?

Использовать или нет?