Visual Studio 2019 +20





Совсем недавно, на Microsoft Connect(); 2018, мы объявили о выпуске Visual Studio 2019 Preview 1. Это первая Preview-версия следующей Visual Studio. В ней мы сосредоточились на нескольких ключевых областях, таких как ускорение запуска и работы с проектами, хранящимися в репозиториях git, улучшение IntelliSense с помощью искусственного интеллекта (AI) (Visual Studio IntelliCode), упрощение совместной работы с коллегами путем интеграции Live Share и многое другое. Подробнее под катом!



Сосредоточьтесь на работе


Сразу же вы заметите, что Visual Studio 2019 открывается в новом стартовом окне. Оно спроектировано для более удобной работы с современными репозиториями Git, будь то локальные репозитории или онлайн-репозитории Git на GitHub, Azure Repos или где-либо еще.



Конечно, вы все равно можете открыть существующий проект или создать новый. (Новинка также скоро появится в Visual Studio 2019 для Mac.)


VS19 для Windows и для Mac

Также сегодня мы делимся новыми возможностями поиска в Visual Studio 2019, которые заменят существующее поле «Quick Launch». Теперь вы можете искать настройки, команды и параметры установки. Новый поиск также более интеллектуален. Он поддерживает поиск выражений, которые содержат ошибки.



Visual Studio 2019 поможет кодить быстрее. В этом preview мы сфокусировались на удобстве достижения согласованности и «ремонтопригодности» кода. Мы добавили новые возможности рефакторинга, такие как изменение циклов for в запросах LINQ и преобразование кортежей в именованные структуры, чтобы упростить поддержание вашего кода в хорошем состоянии. С новым индикатором работоспособности документа и функцией очистки кода теперь вы можете легко определять и исправлять ошибки одним нажатием кнопки.



Обычная отладка также стала проще. Вы сразу увидите, что производительность улучшена, и это делает процесс отладки более плавным. Мы также добавили возможности поиска в Autos, Locals и Watch, помогая вам отслеживать объекты и значения. В следующих статьях мы подробнее расскажем об обновлениях в областях дебаггера, в том числе о функции «Time Travel Debugging», о новинках в Snapshot Debugger для Azure Kubernetes Service (AKS) и Virtual Machine Scale Sets (VMSS), а также о лучшей производительности при отладке больших проектов C++, благодаря внепроцессному 64-битному отладчику.



Помогаем вашей команде работать вместе


Опираясь на работу, которую мы начали в Visual Studio 2017, мы улучшаем Visual Studio IntelliCode, наш контекстно-зависимый IntelliSense с интерфейсом AI, чтобы можно было обучать его в собственных репозиториях кода и делиться результатами с вашей командой. IntelliCode уменьшает количество требуемых нажатий, предлагая контекстуальные рекомендации для каждого конкретного кейса. Подробнее мы писали об этом здесь.



Ранее в этом году мы представили Visual Studio Live Share, инструмент, помогающий вам в реальном времени взаимодействовать с кем угодно по всему миру, используя Visual Studio или Visual Studio Code. Live Share по умолчанию устанавливается в Visual Studio 2019, поэтому вы можете немедленно пригласить своих коллег присоединиться к кодингу, чтобы устранить ошибку или помочь быстро внести изменения.



Наконец, в Visual Studio 2019 мы представляем совершенно новый путь использования pull request (PR), который позволяет проверять, запускать и даже отлаживать pull request от вашей команды, не покидая IDE. Сегодня мы поддерживаем код в Azure Repos, но собираемся вскоре расшириться и до GitHub. Чтобы начать, вы можете скачать расширение Pull Requests for Visual Studio из Visual Studio Marketplace.



.NET Core 3 Preview 1


Мы также объявили о выпуске .NET Core 3 Preview 1, и Visual Studio 2019 станет продуктом для поддержки создания приложений .NET Core 3 для любой платформы. Конечно, мы также продолжаем поддерживать и улучшать кроссплатформенную разработку на C++, а также разработку мобильных приложений .NET для iOS и Android с помощью Xamarin.





Подготовить эту статью нам помогли ребята из Microsoft Developer Community @msdevru, канала сообщества Microsoft Developer для разработчиков и всех, кто интересуется новыми технологиям.

Вы можете помочь и перевести немного средств на развитие сайта



Комментарии (46):

  1. kenoma
    /#19508564

    .NET Core 3 текущей версии студии поддерживаться не будет?

    • ICELedyanoj
      /#19512450 / +1

      Почему же не будет. VS 2017 умеет .Net Core 3.
      В инсталляторе отдельного SDK не нашёл, но если скачать SDK и Runtime с сайта Microsoft, то в VS 2017 можно кодить под него.
      Один маленький секрет. Заходите в Tools->Options->Projects and Solutions->.Net Core и отмечаете галочку «Use previews of the .NET Core SDK», т.к. третья версия пока в стадии Preview.
      После этого можно выбрать .Net Core 3 в свойствах проекта и всё заработает.

  2. lostmsu
    /#19508606

    Поддержку нескольких репозиториев или хотя бы submodules так и не добавили.

  3. 8street
    /#19509088 / +3

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

    • xi-tauw
      /#19509184 / +1

      Люто согласен.
      2015 студия — dvd образ и все отлично устанавливается. 2017 студия — скачал standalone на 22 гига, но на машине без интернета все равно не осилила встать. Кое-как прокинул интернет и, если я правильно, понял по логам, то скачалось около 3 мегабайт и этого хватило. Боюсь, что 2019 будет вести себя также.

    • IRainman
      /#19509556

      Люто плюсую про оффлайн установку. Она нужна и оффлайн обновления тоже очень и очень нужны.

    • Saamm
      /#19510352

      а кто сейчас работает без интернета?

      • xi-tauw
        /#19510530 / +1

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

        • Oxoron
          /#19510674 / +2

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

          По поводу оффлайн установки в целом: видимо, MS решили не гнаться за тем процентом людей, который использует VS для странного.

          • xi-tauw
            /#19510742

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

            В общем-то именно так я и поступил в этой ситуации. Причем, как я писал выше, к 22 гигабайтам докачалось всего около 3 мегабайт, чтобы успешно довести установку.
            В остальных ситуациях пришлось использовать более оффлайновые среды.

          • logran
            /#19511020 / +1

            «Для странного», говорите? Обычный белорусский университет. Всего лишь надо VS Community + Xamarin + C++ для учебного процесса. Чего в этом странного? А это немножко так ~40гб. На 3 аудитории кафедры. По 15 машин. 1.8 Тб выкачать. Как выдумаете, что мне скажут в ВЦ на просьбу предоставить такой объем трафика для установки ПО? Я уж молчу про скорость интернета в ВУЗах.

            Я понимаю Net-Install для каких-нибудь драйверов весом в 300мб и прочего. Но софт весом 30+гб лишать оффлайнового установщика — издевательство, имхо.

            • stork_teadfort
              /#19511908 / +1

              А в чем профит типовые машины не из образа раскатывать, а вручную конфигурить?

              • logran
                /#19514410

                В итоге и пришлось настроенную машину клонировать. Но с 5200 HDD это медленно. С оффлайн-установщиком было бы в разы проще.

                • IvanTamerlan
                  /#19519492

                  У меня похожая ситуация, думал клонировать каскадом, т.е. 1 на 1, полученные 2 на 2, и потом на оставшиеся 3 (всего 7 машин). Могут быть косяки с конфигурацией, т.к. из 7 машин 1-2 имеют другие параметры (другая мать?).
                  Но опечалили жесткие диски — они ~80гиг. Т.е. винда+эта среда + матлаб + еще пару прог… А, нет, все вместе не влезут. Это я не вспоминаю про юнити и Microsoft Office, которые тоже прожорливые. А еще 1С… //(*слышен звук выстрела*)//

    • Anton-V-K
      /#19517514

      Я в своё время озадачивался созданием offline-инсталлятора (с целью экономии места и развёртывания одной и той же версии Студии на нескольких компах без необходимости докачивания). Подход описал в блоге. Может, кому-то пригодится. Компоненты нужно будет подбирать под свои нужды — с этим придётся морочиться, но только в первый раз. Потом можно по тому же списку выкачивать новую версию в новый каталог.
      На данный момент сижу на 15.8.9 (C++ и C#), инсталлятор занимает ок. 3719 МБ (влезает на компакт).

  4. workless
    /#19509382

    Если убрать все тулбар-ы, то из-за кнопок в правой части не освобождается свободное вертикальное место :(
    image

    • aosja
      /#19509778

      Особенно странно выглядит кнопка PREVIEW, которая просто дублирует About. На лэптопе занимает дорогое место на экране. Неужели нельзя было это впихнуть рядом с Search Visual Studio и разрешить настраивать?

  5. TargetSan
    /#19509966

    Несколько скромных вопросов от С++ разработчика.


    1. Наследуемые include пути добавили? Чтобы не прописывать в зависимом проекте include paths зависимостей руками. Или для полноценной работы по-прежнему нужен CMake?
    2. Поддержка CMake по-прежнему требует Tools for Linux? Или эту странную зависимость (при этом неявную) всё-таки убрали?

    • KindDragon
      /#19510662

      Наследуемые include пути добавили? Чтобы не прописывать в зависимом проекте include paths зависимостей руками. Или для полноценной работы по-прежнему нужен CMake?

      Обычно же .props файлами можно решить эту проблему

      • TargetSan
        /#19510718

        Это всего лишь перенос ручной конфигурации в другое место. Сравните с CMake target_include_directories. Вы задаёте "публичные" и "приватные" пути у самого таргета. Далее, при подключении этого таргета как зависимости все его публичные include paths, а также include paths от всех его публичных зависимостей (в т.ч. транзитивных) автоматом попадают в ваш зависимый таргет. Таким же образом это работает для libraries, definitions etc.

  6. nightwolf_du
    /#19510672 / +2

    Когда уже x64 завезут-то?
    2018й год кончается, а студия х32 и во многих местах жутко синхронно работает с интерфейсом.
    Запуск большого билда приводит к фризам интерфейса :-(

    • sahsAGU
      /#19519714

      Если вы этого еще не сделали, сообщите о проблеме с потреблением памяти через «Сообщить о проблеме» в среде IDE. (https://docs.microsoft.com/en-us/visualstudio/ide/how-to-report-a-problem-with-visual-studio-2017) Это поможет нам улучить работу с VS.

      Что касается вашего вопроса о 64-битной версии Visual Studio: мы рассматриваем плюсы и минусы добавления 64-битной версии в каждом выпуске — от последствий для экосистемы расширений до влияния на производительность. Visual Studio 2019 мы не планируем делать x64. Тем не менее, мы продолжаем работу, начатую в Visual Studio 2017, по перемещению ресурсоемких компонентов и рабочих нагрузок в отдельные процессы. Например, некоторые ресурсоемкие компоненты языковых служб C#/VB уже выполняются в отдельных процессах, и начиная с Visual Studio 2019, компоненты отладчика C++ будут также выполняться в отдельном процессе.

  7. usego
    /#19510726

    Когда вы переведёте лицензирование студии на схему десятки (купил один раз и пользуйся апгрейдами)? Сейчас перепокупать студию раз в 2-3 года ни разу не интересно. Не говорю про то, что IDE можно было бы и вообще бесплатно раздавать, что бы окончательно не профукать полимеры.

    • ChymeNik
      /#19510844

      Окончательно не профукать полимеры? А что, есть начало или предпосылки к нему?

      • musuk
        /#19511010

        Да как бы тут всё просто: чем ниже уровень входа в разработку на .net, тем большая привлекательность у Azure.
        Сейчас купить Idea намного дешевле и проще, чем VS.
        Собственно, одна из причин провала WinPhone — это порог входа в разработку. Надо было лицензию покупать, студию да и платформа была довольно закрытая.

        • ChymeNik
          /#19511194 / +1

          А как же VS Community?

          • usego
            /#19511466

            Аутсорсерам надо работать на том, что клиенты используют, а часто это чуть ли не ентепрайз. В результате имеем что имеем.

          • musuk
            /#19519452

            Так это они позже уже сделали. До этого была убогая Visual Studio Express.
            И очень правильно, что теперь есть Community на которой сидят все инди.

  8. Sazonov
    /#19511398

    Конечно, мы также продолжаем поддерживать и улучшать кроссплатформенную разработку на C++

    Вот можно про этот момент чуть подробнее? А то вообще нет никакой информации о перспективах С++ в рамках MSVS 2019.
    И ещё вопрос. Может я не совсем правильно понял, но MSVS 2019 для Windows и MSVS 2019 для MacOS — это две совершенно разные IDE, которые теперь будут одинаково называться?

    • HaVok
      /#19512840

      Может я не совсем правильно понял, но MSVS 2019 для Windows и MSVS 2019 для MacOS — это две совершенно разные IDE, которые теперь будут одинаково называться?

      Да, это две разные IDE. Названия тоже разные. Для Windows просто Visual Studio. Для macOS — Visual Studio for Mac. VS for Mac основана на MonoDevelop, и доступна начиная с VS 2017.

      • Sazonov
        /#19513218 / -1

        Предложите, как можно сокращённо назвать msvs for Mac? Классическую студию мы с коллегами называем «вижла», что понятно. С Visual Studio Code тоже быстро разобрались, она стала называться «вэ эс код». Но маркетологи Майкрософта не успокаиваются :). Подскажите, как можно лаконично называть вижлу для мака?

        • kovserg
          /#19513252

          Так и называйте Маквжила как Дункан Маклауд и Макдональдс.

  9. NeoCode
    /#19512266 / +2

    Уж надо называть VS2020, до НГ пара недель осталась :)

    • alemiks
      /#19513080

      Как там, в будущем?

      • ICELedyanoj
        /#19513978

        Думаю, что это был сарказм на любовь разработчиков называть новые версии своих продуктов следующим годом. Мол, негоже в 2019-м выпускать [ProductName] 2019, и если MS не успевает выпустить VS 2019 в 2018-м, то её следует назвать VS 2020.
        С уважением, ваш Кэп.

  10. mapron
    /#19512312

    Еще вопрос от С++ разработчика — есть какие-то планы по работе над скоростью С++ компилятора? а то замедление в 3.5 раза просто при смене 2015-> 2017 вообще не радует.

    • sahsAGU
      /#19519726

      Спасибо за вопрос.

      Что касается компилятора C++, у нас есть новый toolset, который появится в VS 2019, но он не доступен для Preview 1. Он будет доступен в будущем превью.

      • mapron
        /#19524132

        Спасибо за ответ, буду тестить обязательно.

  11. kovserg
    /#19513200

    В Windows 7 работает или как Office 2019?

    • lonesimba
      /#19519730

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

  12. vlivyur
    /#19513740

    А xaml и aspx всё так же считаются обычными текстовыми файлами?
    А то как-то надоело смотреть на надпись «0 references» над методами типа _OnClick при явной их используемости.

    • sahsAGU
      /#19519736

      Будет добавлена поддержка XAML.

  13. balsoft
    /#19515378

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

  14. vba
    /#19516516

    Дайте угадаю, студия наконец то станет х64? Нет не угадал?

  15. QtRoS
    /#19524136

    Текст анонса крайне корявый, очень трудно читается.