Сегодня стала доступна новая версия IDE от Microsoft: состоялся релиз Visual Studio 2019 и её «двоюродной сестры» Visual Studio 2019 for Mac.
Visual Studio находится в немного странном положении, и разработчикам впору спрашивать, почему такой релиз вообще существует. Visual Studio 2017 с момента своего выхода два года назад получила девять минорных обновлений и бесчисленные патчи. Каждый из этих релизов приносил новые фичи и багфиксы, и использование Visual Studio оказывалось сродни, например, Google Chrome, где каждая новая версия приносит стабильный поток инкрементальных улучшений.
Режим Live Share, слева код открыт в Visual Studio 2019, справа — в Visual Studio Code
И ведь эту интерактивную инкрементальную модель Microsoft продвигает (и использует) в сервисах вроде Azure DevOps, и её можно сравнить с непрерывной разработкой у ежемесячно обновляемых Office 365 и Visual Studio Code. Когда используется такой подход к разработке, кто-то может удивиться, зачем вообще было заморачиваться с «Visual Studio 2019»: давайте просто будет «Visual Studio», и она вечно будет обновляться.
Зачем придерживаться старого подхода к релизам? Есть потребители, покупающие бессрочные лицензии, а ещё новая мажорная версия позволяет легко внести определённые изменения — например, прекратить поддержку старых платформ или масштабно изменить библиотеку C++. Visual Studio 2019 (наконец) бросает поддержку Windows XP для проектов на С++, так что вам придётся использовать старый компилятор Visual Studio 2017, если хотите по-прежнему таргетироваться на давно устаревшую операционную систему. Также новая мажорная версия — это подходящий момент для больших изменений интерфейса, и первым делом при установке Visual Studio 2019 будет заметен новый экран приветствия, новый интерфейс для создания проектов, и новая строка заголовка, включающая сразу и меню приложения, и переработанный поиск фич в IDE.
Также новая версия приносит штуки, которых не было в 2017. Меня больше всего привлекает то, что дошла до стадии general availability система Live Share. Это система для совместного редактирования, которая работает и в Visual Studio, и в Visual Studio Code, позволяя парам разработчиков кодить и отлаживать вместе, при этом видя перед собой интерфейс, соответствующий их личным предпочтениям. Изначальная превью-версия Live Share, появившаяся в ноябре 2017-го, поддерживала только JavaScript (вместе с его успешной майкрософтовской разновидностью TypeScript) и C#.
В ответ на спрос со стороны пользователей в Live Share добавили C++ и Python. Пока что Python для Visual Studio всё ещё в новинку; поддержка этого скриптового языка была добавлена в Visual Studio 2017 с одним из обновлений. Visual Studio 2019 расширяет это поддержкой различных рантаймов Python (позволяя легче переключаться между интерпретаторами и версиями), более функциональным отладчиком и более умным IntelliSense-дополнением.
Разработчики на С++ получают улучшение оптимизации в компиляторе, улучшение поддержки для проектов, собранных CMake, и частичную поддержку lifetime profile — набора правил, позволяющих компилятору предупреждать о небезопасном использовании указателей и итераторов.
Теперь, когда GitHub — часть Microsoft, в Visual Studio набирает обороты интеграция с GitHub; в 2019 появляется поддержка гитхабовской модели пулл-реквестов для управления интеграцией патчей в кодовую базу прямо в IDE. Также появилась поддержка возможности “stash” из git, позволяющей сохранить набор изменений, чтобы переключиться на другую ветку без необходимости коммитить эти изменения и без риска их потерять.
И как с любой новой версией Visual Studio, тут есть обычная череда обновлений компиляторов и языковых версий: превью возможностей C# 8.0, новые рефакторинги и тому подобное.
Visual Studio for Mac (созданная на основе Xamarin IDE, когда Microsoft купил Xamarin) сегодня также была обновлена. Первая её версия, по сути, была ребрендингом приложения Xamarin Studio (с добавлением компилятора C# и .NET-библиотек от Microsoft) и имела мало отношения к «настоящей» Visual Studio.
Однако похоже, что Microsoft всерьёз старается сблизить эти продукты в тех аспектах, где это имеет смысл. В Visual Studio for Mac 2019 появилось превью нового текстового редактора, основанного на том же движке, что и в Visual Studio для Windows, с нативным для macOS интерфейсом и возможностями. Это значит, что теперь у обеих Visual Studio похожие возможности в вещах вроде IntelliSense, дополнения кода и quick-fix’ов. Новый редактор не включен по умолчанию, но его можно включить для C# и XAML, а после доведения их до стабильного состояния планируется добавить больше языков. Экран приветствия теперь тоже выглядит очень похоже на собрата из Windows:
Microsoft сближает две Visual Studio и в других областях: отладчик Unity на Mac и Windows теперь одинаковый, а в будущем апдейте намерены частично принести Windows Xamarin Forms XAML на Mac.
Помимо всего этого, есть улучшения производительности и стабильности, а также много улучшений в accessibility.
В случае с обеими версиями Visual Studio в Microsoft подчёркивают значимость пользовательского фидбека в процессе разработки. Как минорные, так и мажорные апдейты основывались на фидбеке — например, в случаях с Python и Live Share новые возможности появились как прямой ответ на запросы пользователей. Постоянный поток минорных релизов позволяет Microsoft предоставить новую функциональность пользователям гораздо быстрее, чем было бы с одними мажорными апдейтами, и эта функциональность может видоизменяться и расширяться в ответ на фидбек. По сравнению со старыми временами, когда ты заводил баги на сайте Microsoft Connect лишь для того, чтобы они канули в пучину, нынешнее положение дел — освежающее улучшение.
От переводчиков: тема Visual Studio нам близка, потому что в мае мы увидим многих её российских пользователей на нашей конференции DotNext. Раз вам интересен этот релиз, вполне возможно, вам интересно и что-то из программы DotNext.
kovserg
На windows7 пускается?
phillennium Автор
Должна:
NeoCode
RC запускалась. И это хорошо!
Magic_B
Канеш! Я уже кодю на ней под Win7 Embedded x86 в vbox :)
kovserg
Я так понимаю теперь длинный список vcredit-ов которые надо поставить чтобы заработал какой-нибудть автокад пополнится еще одним. Надеюсь имя фала при скачивании будет более информативное чем у предшественников:
www.itechtics.com/microsoft-visual-c-redistributable-versions-direct-download-links
navion
Для 2015-2019 достаточно последнего.
kovserg
Я про информативные названия файлов при скачивании — очень удобно.
navion
Удобно, не надо менять инсталяционный скрипт при сборке в новой студии.
vlivyur
Ага. А потом получается что опакетили с новой версией, а на самом деле как работали со старой, так и работает, но только её теперь невозможно поставить, т.к. «более новая уже стоит».
mapron
Самый главный вопрос, который сейчас волнует нашу команду — в блоге была упомянута обратная совместимость между v140 и v142 тулсетами, т.е. можно в коде, скомпиленном с v142, использовать библиотеки с v140 (vs2015).
А есть ли совместимость с v140_xp библиотеками? Формально, проект собирается и бинарники запускаются, но гарантируется ли какая-то работоспособность? Очень хочется получить ответ, пересобрать все зависимости за раз не хочется.
p.s. не уверен, правда, по месту ли это не в профильном блоке MS спрашивать. Но вдруг кто из коллег уже озадачивался этим вопросом.
MikeLP
Сори не в ту веткуMikeLP
Поддержку HiDPI мониторов добавили или нет?
0xcffaedfe
Поддержки hidpi в windows до сих пор нет, на должном уровне, а вы про VS интересуетесь.
VioletGiraffe
Очень странное и ошибочное заявление, среди трёх основных десктопных ОС она только в Windows нормально и реализована. Может, ещё в каких-то отдельных линуксовых GUI, а вот в Gnome и macOS точно нет. У меня два монитора с существенно разным DPI и разными коэффициентами масштабирования, так что все баги я сразу вижу.
chupasaurus
Скриншот из KDE 5, появилось в 4 версии.
Собственно последняя настройка регулирует не только шрифты, но и вообще весь рендер. Приложения на Gtk естественно в пролёте и емнип рисуются под 96 dpi.
VioletGiraffe
KDE давно не пробовал. В Gnome нормально реализовано масштабирование, НО только для всех мониторов одинаково, нет раздельного управления, что делает мой второй монитор неюзабельным.
chupasaurus
Разный DPI для мониторов не возможен в принципе в X server, собственно одна из фич у Wayland.
hjarvard
Неверно, как минимум в Qt поддержка разного dpi реализована.
chupasaurus
hjarvard
Не совсем так. Если перемещать окно между мониторами, то dpi пересчитывается корректно на лету и окно перерисовывается. Но если растянуть окно на два монитора — тогда да, на одном из них будет либо всё слишком крупно, либо слишком мелко, об этом и написано в вашей цитате. 2-inch bezel in the middle of your window — это имеется в виду рамка самого монитора. ;)
Именно такое поведение я и наблюдал c qt приложениями. Кстати, в винде так же всё работает и, если мне не изменяет память, в gnome в wayland сессии.
beeruser
По принципу «чем хуже — тем лучше»? На _одном_ 4к мониторе в Windows беспорядок.
Все программы вразнобой работают, какие-то реагируют на настройку DPI, какие-то нет, да даже в пределах одной программы бывает бардак.
А вот на Маке всё отлично.
DistortNeo
Что же за софт-то вы используете?
Я испытываю проблемы только при смене DPI (подключение по RDP) — не все приложения поддерживают это дело на лету, и система начинает их интерполировать — приходится перезапускать приложения.
beeruser
Программерский. В основном проприетарный софт на дотнете плюс всякое старое говно типа тотал-коммандер. Всё вместе это выглядит ужасно.
DistortNeo
В .NET Framework 4.7 значительно улучшили поддержку HighDPI для старых приложений, написанных на Windows Forms. Возможно, вам стоит ещё поиграться со настройками HighDPI в параметрах совместимости в свойствах приложения.
Ну и последние версии Windows 10 вроде как лучше умееют в HighDPI.
Попробуйте Far Manager.
oracle_and_delphi
Far Manager — на любителя. Кому-то в кайф, а кому-то очень неудобно.
MTonly
А что у TC не так с HiDPI?
ditstk
у говно_кодера и и свои и чужие программы говно. Тотал Комаандер отлично идёт на десятке
Am0ralist
И вновь в том, что программисты не умеют писать программы виновата ОС…
Схожая проблемы начались, когда МС запретило сохранять программам данные в программфайлз. Сразу столько претензий к плохой ОС началось!
yatagarasu
Виноват кривой апи, который отдаёт все заботы на усмотрение разработчика.
Am0ralist
Если не ошибаюсь (сам не программист, я только ошибки за ними при внедрении нахожу постоянно, но из обсуждений в прошлом осталось в памяти такое):
Если программа не умеете в дпи — система делает сама как умеет (старые проги = мыло), если программист заявил, что умеет — то система ему верит и считает, что программа сама сможет. Так что если же он действительно в это умеет — программа работает нормально, если же у программиста лапки — то ОС в этом то как виновата? Плюс вроде как теперь конкретным прогам можно указывать, чтоб ОС их не трогала и не пыталась ничего сделать, ибо у программиста — лапки.
Понимаете, когда в 2016 году одна программа на оплачиваемой техподдержке, которая за несколько лет только мажорных версий сменила, так и продолжала криво работать при установке её в программфайлз без полных прав на директорию… Так вот, АПИ может и кривой, однако почему тогда у других получается?
dimaaan
Виноваты те, кто любит ругать даже не попытавшись разобраться в проблеме.
Папка Program Files впервые появилась в Windows 95, когда ОС была еще однопользовательской.
Интересно было бы послушать, как бы вы решили эту проблему.
VioletGiraffe
Минуточку, вы не путайте поддержку со стороны ОС и корявые руки программистов (и/или три года не обновлявшиеся программы). Мой софт ведёт себя правильно, и реализовать это было очень не сложно. А что половина софтописателей до сих пор не осилили то, что должны были сделать года три назад — да, есть такое.
0xd34df00d
А где заканчивается ОС и начинается софт для ОС?
А то X server тоже можно в софт записать.
Am0ralist
Вот только одно дело, когда в ОС невозможно что-то сделать либо только через низкоуровневые хаки, и другое, когда программист не хочет разбираться с нововведениями ОС и реализовывает их криво.
Так то да, X-server в идеале можно взять и выкинуть, заменив своим решением. Но будете ли вы это делать, если вы пишете новый молодежный калькулятор?
ad1Dima
Она и в 2017 есть. В этой вот такую опцию добавили:
MTonly
VS как программа поддерживает HiDPI. Генерировать dpiAware-объявление в манифесте тоже умеет. Остальное — дело разработчика, пишущего в VS программы.
NeoCode
Исторически каждая следующая студия была тормознутее предыдущей — как в скорости компиляции (С/С++) так и в плане GUI. Интересно как с этой 2019? И это при том что никаких супер-востребованных фич за все время так и не добавилось. Удобный редактор, дерево проектов, отличный отладчик (куда лучше чем реализация в Qt Creator к примеру). Но все это было еще в VS6 (1998)! Зато скорость работы падает в несколько раз с каждой новой версией. И самое печальное, что нет универсальных механизмов обратной совместимости компиляторов и IDE (т.е. меня вполне бы устроила оболочка скажем от 2005/2008/2010 студий, но компилятор и набор библиотек чтобы был новейший).
mapron
Релиз не тестил еще, но TP были тормознее. Обещали какие-то оптимизации по скорости.
Обратная совместимость как раз есть — вы можете в новой IDE переключать на тулсеты старых компиляторов.
А то что вы хотите, это называется прямая, и ее не так просто реализовать.
Представьте, запустили вы новый компилятор, а подсветка кода не работает =) Это очень сильно ударит по имиджу «поддержки» такой фичи. А модель кода портировать в старые версии — это может быть половину кода IDE затрагивать)
(ну и да, тут еще финансовая сторона — скорее всего, продажи бы упали раз так в ндцать, т.к. многие компании покупают лицензии только ради компилятора).
NeoCode
Если дело только в подсветке синтаксиса, то это ударит по имиджу разработчиков, не предусмотревших элементарную модульность. Подсветка синтаксиса должна описываться простейшими правилами во внешнем файле.
Kobalt_x
Для C++ это не поможет, для правильной полной подсветки C++11&later кода нужна полноценная code model.
NeoCode
Ну для меня отсутствие идеально точной подсветки не так уж критично по сравнению с тормозами во время работы:)
mayorovp
Ладно отсутствие подсветки, проблема еще и в её наличии (студия будет подчеркивать красным все чего не поняла)
0xd34df00d
В C++ отсутствие code model и полноценных вычислений на этапе компиляции — это не вопрос идеальности подсветки, это вопрос хоть какой-то адекватности подсветки. Если в вашем коде есть хоть немного темплейтов или констекспра, конечно.
olsamurai
А кто-нибудь подскажет, как на счет «structured binding» и «if statement with initializer». У меня в 2017 версия 15.8.0 черкает все красным.
mapron
Не завезли еще пока.
VEG
Должно работать в последней VS2017. Проверьте в настройках проекта что используется актуальный тулсет, а не тот что был в VS2015.
olsamurai
Используется актуальный toolset
dev96
Вы точно включили toolset vc141 и C++17?
structured bindings точно работали в 15.9.5, а if statement with initializer я начал юзать уже в RC19.
Вообще вот: docs.microsoft.com/en-us/cpp/overview/visual-cpp-language-conformance?view=vs-2019
И то и другое с 15.3 работают.
Уточню на всякий случай, что по умолчанию проект настроен на C++14.
olsamurai
У меня стоит 15.8.0. Может надо обновиться до 15.9.5 и тогда заработает. Все настроено на с++17. Компилятор все поддерживает. А вот IntelliSense подчеркивает…
WhisperingOak
Теперь будет ставиться не полдня, а целый день, и занимать не 20, а 40 Гб.
VD42
Весь необходимый набор для разработки классических десктопных приложений на C++ у меня вышел менее двух гигабайтов для скачивания (установка выполняется во время скачивания компонентов, так что не сильно больше времени занимает, чем само скачивание) и где-то пять гигабайтов в установленном виде. Главное — отметить только нужные флажки в установщике.
iroln
Я бы не назвал редактор студии удобным. Зубодробительные шорткаты по умолчанию (кто вообще придумал все эти комбинации вроде "
Ctrl+E, V"), до 2017 не было даже функции "дублировать строку" без затирания буфера обмена через copy/paste, мультикурсор вроде до сих пор не завезли, а также много раздражающих мелочей вроде отсутствия подсветки текущей строки до 2015 (делалось только расширением Visual Assist и т.п.). В общем, по сравнению с современными редакторами редактор классической студии всегда был довольно убогим. VSCode в этом плане шагнул далеко вперед.Также студия никогда не была особо удобной для разработки на C++, IntelliSense из коробки вообще ни о чём (по сравнению с тем же Visual Assist), отсутствие адекватной поддержки CMake ну и т. д. и т. п.
Кстати, 2010 студия была переписана на WPF, с этого момента начались тормоза и лаги. В следующем релизе они отказались от WPF, но тормоза почему-то остались. Особенно дикие связаны как раз с IntelliSense, которая может тупить по несколько минут при поиске какого-либо символа или при переходе от прототипа к определению функции/класса.
ad1Dima
IvanNochnoy
Мультикаретка, во-первых, во-вторых, она недоделанная — попробуйте скопировать и вставть текст в мультирежиме.
ad1Dima
iroln
И где тут мультикурсор? Это просто выделение блоком, и что с этим дальше делать?
ad1Dima
второе сочетание вы конечно не пробовали…
mayorovp
Пробовал, оно выделяет слово, точно так же как это делает двойной клик.
IvanNochnoy
Multi-caret selection
iroln
Сначала оно не заработало из-за Goto Ctrl+Mouse в VAssist, потом оно тоже не заработало, потому что в VS2015 этой функциональности нет, она появилась в 2017 судя по ссылке на справку ниже. :)
При поиске/замене несколько точек редактирования тоже доступны? Чтобы не кликать.
IvanNochnoy
Ctrl+Shift+Alt+, Add all matching text as selections
iroln
Ctrl+Shift+Alt+,Адовые шорткаты для инопланетян со щупальцами, я же говорю. В Sublime просто Alt+Enter. :)
ad1Dima
iroln
В первом комменте я написал "вроде бы". :)
На рабочем проекте VS2015 из-за компилятора. Ведь это так "удобно", когда компилятор гвоздями прибит к IDE.
VEG
Использование тулсета из VS2015 поддерживается в VS2019.
DarkWanderer
Вы бы хоть матчасть подучили, прежде чем грязью инструменты поливать. Современные VS поддерживают все более старые Visual C++ компиляторы начиная с 2012. Я на работе так долго сидел — Visual Studio 2015 с компилятором vc110_xp, потом vs2017 с компилятором от 2013
iroln
Грязью поливать? Серьёзно? Прямо так написали, словно вы мои слова как личное оскорбление восприняли. Успокойтесь, посчитайте до 10, откройте студию, видите, она чистая, никто её грязью не облил. Можете дальше спокойно работать. :)
Я знаю про тулсеты, но кроме тулсетов есть ещё расширения, например, для CUDA с которыми вечно какие-то проблемы в новых студиях, а также прочие особенности перехода на новые версии студии.
А про компилятор, прибитый к IDE я разве неправду написал? Вы можете скачать и поставить MSVC-компилятор без студии?
dev96
Я бы не сказал, что проблемы расширений — это прям беда Visual Studio.
Проблема обычно со всякими CMake и т.п. Решения давно уже не меняются внутри. Toolset-ы предыдущих версий можно спокойно ставить через installer.
А MSVC, кстати, можно скачать без IDE (MSVC Build Tools).
Да и VS официально поддерживает GCC и CLang.
iroln
Это событие я что-то проспал, да.
Mov_AX_0xDEAD
есть варианты, начиная с DDK(WDK по новому) или экзотика типа Visual C++ Compiler Package for Python
iroln
Нет, ну это уже совсем экзотика. Они это сделали только для того, чтобы собирать экстеншены для Py27 без установки студии. По сути это уже почти никому не нужно. А вот ответ выше верный, значит я был не прав на счёт компилятора (частично, потому как было время, когда MS эту возможность убрали и убрали компилятор в том числе из Driver Kit)
jaguard
>Исторически каждая следующая студия была тормознутее предыдущей
Кстати, это не совсем так. Руководствуясь этой логикой я не уходил с 2013, но оказалось, что 2013 была особенно тормозной, а 2015 наоборот заметно ускорилась, и 2017 вроде не потеряла после этого в производительности. Это в GUI, в компиляции у 2013 вообще был какой-то странный баг, который иногда подвешивал мой проект на стадии линковки минут эдак на 5.
Singapura
Microsoft, прямо как кислотный ожог. Всё растворяет и поглощает, переделывая во что-то своё,… а потом откладывает за ненадобностью, как с ХР. А ведь ХР, нормальная среда обитания для многих. Я вообще считаю ХР самой красивой OS.
mapron
Простите за едкость, у вас-то есть коммерчески успешный продукт, в котором вы продолжаете поддерживать версии вышедшие 20 лет назад? Если да, скиньте ссылочку, будет интересно.
Вам никто не запрещает пользоваться ХР до сих пор. Просто почему бы например Win2000 не поддерживать в новой IDE? или Win95? где-то же должен быть предел.
Поддержка ХР была рекордно длительное время, но это не может продолжаться вечно.
Это не просто прихоть маркетинга (иначе бы выкидывали поддержку всего кроме вин10), с т.зр. разработки реально приходится сталкиваться с ограничениями в API. попробуйте-ка всякие TLS и shared_mutex реализовать, когда нативной поддержки нормальной нет)
Singapura
Я думаю, если-бы MS продали-бы Win ХР, компании уровня Intel. Тогда они-бы(MS), поняли-бы кто именно всех кормит, из семейства их успешных продуктов. Они потеряли-бы самую большую часть своих клиентов. При всём уважении к остальным продуктам компании.
expeon
А тем временем, в параллельной вселенной, например, на Стиме 2/3 (67.15%) пользователей используют Виндоуз 10.
Singapura
Здесь на Хабре, юмор про MS не приветствуется)) Просто удивительное количество минусов за спокойный текст))) «Правда, глаза колит» (пословица народная) минусовщикам)))
Sioln
Колит — это воспалительное заболевание такое.
Скобка, скобка, скобка.
NLO
НЛО прилетело и опубликовало эту надпись здесь
Steed
Я не автор исходного комментария, но у нас такие продукты есть, например http://octonus.com/oct/products/mbox/2.0/. Софт для ограночных предприятий, в которых все было настроено и установки работают много лет. Кстати, расширенная поддержка XP закончилась в 2014 году, всего 5 лет назад. Обновлять систему и останавливать на время производство никому не хочется. Можно поставить клиентов перед фактом, но это не очень здорово скажется на имидже. Тем более, что машины не подключены к интернету и защищаться от уязвимостей им по большому счету ни к чему. А для новых продуктов, конечно, мы требуем Windows7+.
defiaNtBY
но из пдф по вашей ссылке жеж:
Так что нет у вас XP.
А если для конкретных заказчиков за отдельную цену — ну как-то это не считается. так и 3.1 можно поддерживать за 100500 миллионов
Steed
pdf — для новых клиентов. Спасибо, что не поленились посмотреть:)
Если старые всю жизнь сидели на XP, то "либо обновляйся, либо плати" — это повсеместная стратегия ныне, но мы ведь сами не любим, когда с нами так поступают.
Впрочем, в нашем случае проблема решается штатно — вполне хватает VS2015, а уж переходить в бизнес-разработке на свежий компилятор до первой пары сервис-паков — вообще выстрел себе в ногу. Так что пока до VS 2019 очередь дойдет, XP и у оставшихся клиентов умрет своей смертью.
P.s. Вообще, как представлю себе многолетнюю поддержку отдельной ветки приложения на старом компиляторе и версии WinAPI для отдельных клиентов, так и 100500 миллионов выглядят не так уж привлекательно;)
defiaNtBY
Да мне просто было интересно реально ли кто такое предлагает, имхо — это глупо. Да если код есть, то просто взять «компилятор» другой, поправить одну строчку кода и пересобрать — это дно. А когда надо заморочиться с железом/спец софтом/людьми кто знает как эту старую версию собирать на текущем CI (или поднять старый CI) — это уже другое.
Но такова жизнь, альтруистов не много на свете.
Например до сих пор попадаются вакансии на Cobol'e, но это ничего не говорит о каком либо альтруизме по поддержке старых клиентов — а только о том что клиент готов платить отдельные деньги для поддержания его старой, но возможно рабочей, инфраструктуры.
SergejT
Есть много программ которые под dos работают. В Германии, например, терминалы у врачей, кассовые аппараты на бензозаправках…
Singapura
Народ! Это был добрый юмор!)))) Всмотритесь в свои мысли сами!)))
Vassili5946
статью еще не прочитал, но уже сразу хочу срочно спросить, чтобы читать и ставить или остаться на 2015: глюк с ребилдом для CUDA исправили?
Kobalt_x
Начиная с cuda10 vs2017 офф интегрированаю. Глюков с ребилдами не замечал, киньте ссылку плз.
Vassili5946
проблема в том что 2017 не обнаруживает автоматом изменения в cuda-коде, приходится сперва руками очищать и затем билдить. мелочь казалось бы, а в больших солюшенах из нескольких проектов на разных языках — это невероятно бесит. Потому сижу на 2015 где все ок. Кстати, почему Вы говорите, что поддержка куды только с 2017? в 2015 из коробки все ок. нсайт даже для 2010вроде есть официально причем, не? (если что, то использую cuda10.0 + VS2015)
вот кто-то спрашивает на стекеоверфлоу такое же:
stackoverflow.com/questions/48183845/visual-studio-2017-not-detecting-change-in-cu-cuda-files
Kobalt_x
Никогда не замечал, т.к. видимо модуль всегда собирался не через msbuildовый саппорт а через свои props-файлы nvcc
По вашей же ссылке
Так это же не студийная, проблема а кривая msbuildовая таска у самой куды. Т.е. просто при обновлении msbuild таска работать нормально перестала.
Т.е. претензии к кривой реализации таски msbuildа nvidiей а не к студии.
Потому что оффициально поддержка vs2017 появилось с cuda10.0 и вся либа msvc стала собирабельна nvcc. До этого приходилось юзать костыли в cu файлах.
+ По вашей же ссылке пишут что зачинили в 10.1
Vassili5946
смотря с какой стороны посмотреть. видел аналогичный тикет на сайте майков где их саппорт довольно мутно в своем стиле уходил от ответа (ссылку сейчас с ходу не нашел). кто-то из них должен был починить наконец-то.
этого не знал ибо «answered yesterday» по ссылке )) 10.1 еще не рисковал опробовать. посмотрим, если нвидиа озаботилась и подстроилась под 2017 и 2019 то и хорошо.
xfaetas
Хорошо, что поддержку Python допиливают — можно будет соскочить с PyCharm.
msin
а я наоборот задумался о покупке лицензии на Rider…
Студия при работе выдает неясные глюки в виде небольших подвисаний интерфейса или вдруг начинает обновлять компоненты тулбокса в UI-потоке — приходится постигать дзен.
По моим ощущениям интерфейс Rider более отзывчивый
Еще Студия явно начала выпиливать Resharper, было сообщение об использовании устаревшего API в этом расширении, но функционально Студии еще далеко до него.
Возможно, корпоративная версия Студии очень удобная, но $6000 как-то неприлично круто за годовую лицензию…
xfaetas
Это на фоне последних новостей — на случай, если в PyCharm тоже что-нибудь «отечественное» захотят встроить.
Kobalt_x
А вам прямо нужны фичи из enterprise, для интеграции с architect, построение UML из кода, TTD(единственная наверное полезная фича из Enterprise)?
Просто везде где писали на студии enterprise стояла у 1-2х человек а все использовали professional и не парились
IvanNochnoy
Live Unit Testing полезен
vdasus
ncrunch и дешевле и полезнее (по крайней мере из того что я пробовал)
bondarenkod
Таблицу сравнения посмотрите, не совсем ясно, почему вы студию за 6к выбрали, а не за 250 на месяц без доп плюшек вроде доступа в МСДН, кредита на ажур, курсов и тд и тп.
msin
всего $250 в месяц это заметное дороже годовой лицензии Rider (ReSharper Ultimate + Rider стоят $179 за первый год, дальше — дешевле). Тем более я не очень понимаю, какие настолько полезные функции я покупаю за $3000 в год… Мне сложно поверить, что функциональность платной версии студии на порядок выше, чем у Rider.
Крайне удобные Live Unit Tests есть только в Enterprise редакции или нужно отдельно докупать NCrunch ($159). В Rider всё это есть из коробки (видел в 19.1 EAP 4).
Я не планирую отказаться от студии совсем, но большую часть работы с кодом думаю перенести в Rider. Релизы придется делать в студии, потому что обфускатор интегрирован в студию.
DistortNeo
Если вам нужна полноценная отладка кода, то Rider будет проигрывать студии.
mjr27
Смотря для чего. Если разработка идет на .net core, у студии преимуществ практически нет. А у студии без R# — совсем нет.
DistortNeo
Я про всякие полезные мелочи: остановка в момент выброса исключения, кастомные визуализаторы объектов, нормальная работа с асинхронным кодом и ещё что-то, чем я был сильно недоволен, когда пробовал Rider. Возможно, сейчас всё стало лучше.
Ну и подсветка синтаксиса в Rider хромает: невозможна подсветка операторов отдельным цветом, ещё в VS мне нравится подсветка структур и классов разным цветом.
KvanTTT
Не знаю когда вы пробовали, но такое есть уже довольно давно. Не было Edit & Contrinue, но и его скоро завезут. Не хватает межпроцессной отладки, хотя и довольно специфичный кейс.
DistortNeo
Давно, пару лет назад, наверное. Потом перестал пользоваться, потому что EAP свернули.
ad1Dima
Как-то видел человека, который самыми используемыми им фичами R# назвал фичи самой студии.
mjr27
Буквально пара первых пришедших в голову вещей, ради которых плачу, колюсь, но мирюсь с R#
А у rider'a, на мой взгляд, есть родовая травма. Не привычно как-то с 16gb уходить нв 3-4 открытых проектах в глубокий OOM. Кроме этого — нравится, в принципе, все.
ad1Dima
Я не спорю, что есть люди, которые действительно им пользуются. Но некоторые мучаются зря, так как фичи, ради которых они ставят R# уже есть в студии.
сам ещё не пробовал, но в 2019 заявлена поддержка форматирования. но выглядит как-то сложно docs.microsoft.com/en-us/visualstudio/releases/2019/release-notes#dotnet-formatНе знаю, а dotPeek нельзя отдельно от R# использовать? конкурентов вроде можно.
IvanNochnoy
Можно отдельно. Автоформат всего солюшена может делать бесплатный CodeMaid, например.
mayorovp
А за счёт чего магия возможна?
IvanNochnoy
Студия тупо сравнивает файлы на предмет последней модификации — если время последнего изменения обновилось, то она перекомпилирует проект и все проекты, от него зависимые. ReSharper проверяет изменения публичного API сборки, если публичное API не изменилось, то зависимые проекты не перестраиваются.
timiskhakov
Если не секрет, насколько большие проекты? Регулярно работаю на 16Gb с солюшенами на 10-15 проектов, но это, правда, небольшие микросервисы, и никаких видимых проблем не испытываю.
workless
Search Everywhere киллер фича.
Аналогичный поиск в студии медленнее и не такой fuzy
Find Using лучше, который позволяет искать например наследников. Но м.б. в студии это уже появилось.
IvanNochnoy
Ctrl+F12 ищет наследников без ReSharper
ad1Dima
workless
Например в R# ищет класс DatabaseParametersProcessor по введенным символам
DatParPro
DatProPar
ВфеЗфкЗкщ (при вводе в русской раскладке)
Ну его проще попробовать, а потом будет тяжело отказаться.
ad1Dima
Ок, по первой студия найдёт, по двум другим- нет.
qw1
А по «datparpro» найдёт?
ad1Dima
По «datparpro» или «datParPro» найдет по «Datparpro», похоже что нет. Если первая буква большая — включается боллее строгий поиск походу.
Vassili5946
мои 5 копеек: для python лучше IDE чем Komodo не встречал. но он слегка платный.
faoriu
О, у них даже есть Community Edition
faoriu
Надеюсь версия для Мака стала более стабильной.
Gorniv
я начал использовать vscode для нового проекта — в целом нормально.
faoriu
То VSCode, а это — Visual Studio.
Gorniv
я понимаю :D
Visual Studio for Mac — не пошел, тяжелый, ui — какой-то не тот, стабильность тоже не порадовала и запуск тестов так себе был.
Давно еще пытался использовать Rider — ui от Idea тяжеловат, возможно если настроить, то будет хорошо, но я лучше на VSCode буду, туда бы еще resharper(мечты)
timiskhakov
Субъективно с релиза 2018.2 стало сильно лучше и заметных лагов UI почти нет.
vba
У меня один вопрос, ВС 2019 наконец то стал х64 или все так же остается 32 битным, с ограничением в <2Гб оперативной памяти?
Vest
Reddit говорит, что IDE 32-битная.
vba
Мда, нечего сказать...
vdasus
Там все не так просто. Они выносят жрущие процессы в 64 бита (запускают отдельно). Например, вроде, дебаггинг. (Но это неточно. Если интересно — копайте в эту сторону. Я точно где-то то-ли видел то ли читал)
dev96
На хабре была статья о том, что начиная с VS19 отладчик запускается в отдельном 64-битном процессе. И гифка с примером на Gears Of War.
VioletGiraffe
А зачем IDE жрать больше 2 ГБ?
phillennium Автор
Если используется ещё и ReSharper, то вместе они в процесс влезают со скрипом, JetBrains сами признают, что в части случаев это вызывает проблемы:
«Visual Studio and ReSharper, which share the same 32-bit process push your system to its limits. Often, this is reported to happen on large-size solutions and when ReSharper is installed to Visual Studio v. 2015 or later.»
Kobalt_x
так extensionы уже давно можно в отдельные host-процессы выносить в чем проблема то, так много уже кто делает тот же assist вроде так умеет
zhaparoff
По поводу R# отдельная история.
Там, как по мне, больше не с памятью трабла, а то что их все эти рефакторинги вычисляются в UI процессе, синхронно, что превращает работу в студии с R# в сплошной поток фризов (как вспомню — в дрожь бросает, это просто АД).
MS давно сказала разработчикам экстеншенов — «вот вам Roslyn API, используйте его и будет вам счастье». CTP, если верить вики, был доступен с 2010 года, еще под VS 2010. Даже если учитывать сомнения взлетит/не взлетит, то релиз был уже в VS 2013. У Jet Brains было минимум 5 лет чтобы мигрировать. Но они, судя по всему, пилили свой IDE с шахматами и поэтессами, а на R# просто подзабили.
В прошлом году что-то их таки расшевелило, возможно отток юзеров, возможно еще что. Я нашел такую вот статью у них: blog.jetbrains.com/dotnet/2018/05/29/taking-resharper-process-resharper-performance-series. Но, судя по последним комментам, это вот все до сих пор находится в стадии «мы над этим работаем».
phillennium Автор
Ну, про Roslyn они изначально (ещё до анонса Rider) заявили, что не будут его использовать по причинам «там доступно не всё, что нам надо» и «нам для этого пришлось бы R# чуть ли не с нуля переписать». Можно спорить, правильное ли это решение, но всё-таки тут не «годами ждут непонятно чего для миграции», а «сразу приняли решение не мигрировать и ничего не ждут».
На DotNext в 2015-м был связанный с этим доклад, мне запомнился такой слайд:
IvanNochnoy
Год назад мною было принято стратегическое решение свалить с ReSharper сами знаете почему. Вот список того, что на 95% заменяет ReSharper (С#)
Басплатные расширения:
Visual Studio:
Для веб-дева использую VS Code. Результатом доволен. Хоть поверте, хоть проверте.
aavoron
почему?
я лет 5 не юзал студию (и ReSharper тоже), интересно
IvanNochnoy
Конечно, есть удобные штуки, типа семантического поиска, непрерывного тестировния и умного билда… Но, черт возьми, это не перекрывает всех остальных недостатков. Я тоже боялся, что без Решарпера будет хреново, ан, нет, Студия + расширения вполне так себе справляются
aavoron
спасибо, что так подробно все расписали, буду иметь в виду
Qbit
Не забудьте: Microsoft.CodeQuality.Analyzers, Microsoft.NetCore.Analyzers.
vba
А затем что это IDE и на дворе не 1999. Ваш браузер наверное раза в два больше кушает памяти, не так ли?
VioletGiraffe
У меня установлен Visual Assist, никогда не видел расход памяти больше 700 МБ процессом VS. Спасибо, не нужно, чтобы единственная хорошая IDE под Windows стала жрать столько же, сколько поделки JetBrains на Java.
На что браузеры расходуют столько памяти — отдельный вопрос и так себе пример для сравнения. ААА-игры зачастую потребляют меньше.
hasu0
Скачайте хромиум, сгенерите для него студийные проекты, откройте и попробуйте чуть-чуть подебажить. Увидите как студия весело откушает всю доступную 32-хбитному процессу память под дебаг-символы и свалится (или повиснет).
Kobalt_x
начиная с 2019 дебаггер — отдельный процесс.
F0iL
Попробуйте, например, поработать с исходным кодом Chromium, репа с исходниками которого сама по себе занимает 11 гигабайт, а с разными зависимостями типа V8 и Skia, которые тоже выкачиваются в дерево исходников, еще больше, а IDE еще нужно всё это проанализировать, построить индекс для автодополнения, быстрого поиска и навигации по определениям и реализациям типов и классов, и многое другое.
А о том, какое веселье начнется при отладке, выше уже написали.
Kobalt_x
У вас какая-то другая ide это нормально переваривает P.S. CLion например нет(даже с java heap лимитом под 16gb)
F0iL
Я использую 64-битный Visual Studio Code с C/C++ расширением, на десктопе 32 гигабайта ОЗУ и SSD-диск.
Да, возможности все-таки не как у полноценной IDE, но для работы хватает, и бегает вполне бодро.
0xd34df00d
На моём хобби-проекте (которому, правда, 13 лет и 800 kLOC и много темплейтов) CLion жрёт 20-25 гигабайт, если в нём код писать хотя бы с недельку, примерно поровну деля их между самим процессом IDE и clangd (которые на Java и на C++ соответственно, чтобы ремарок про джаву не было).
VioletGiraffe
C недельку писать, не закрывая IDE, или что вы имеете в виду?
0xd34df00d
Да, естественно. Не закрывая и не перезапуская.
IvanNochnoy
Уточнение: лимит виртуальной памяти Visual Studio — 4Гб на x64-системах
zhaparoff
Может я чего-то недопонимаю… Win 10 Ent x64, VS 2017 Pro. Только что открыл самый жирный файлик в C# проекте на 300k SLOC (если что, это не я, это сторонняя тулза такое делает) + еще пару тулов/окошек, запустил билд… в общем развлекался как мог. Таск менеджер показывает Working Set = 3+ Гб для devenv.exe. ЧЯНТД? Возможно, ограничение в 2 Гб есть только при запуске VS на 32-битных версиях окон?
Upd
Выше написали, и я поддерживаю это мнение, что лимит для x64 OS должен быть в районе 4 Гб для x86 приложений (во всяком случае для тех, которые не творят магии со знаковым битом адреса).
К сожалению, нет возможности проверить данную гипотезу — ибо от R# я отказался с переходом на VS2017 из-за его неадекватной тормознутости и невозможности включать/отключать этот ручной тормоз без полной деинсталляции приложения.
DarkWanderer
4Гб это как раз для приложений, которые "творят магию" (/largeaddressaware), по умолчанию 2Гб
mayorovp
/largeaddressaware это не магия, это подписка о неколдовстве :-)
euroUK
Я вчера ради прикола поставил райдер чтобы сравнить скорость в нашем текущем солюшене.
Первый запуск проекта в райдере — 12 минут. Студия за минуту справляется
Память. Райдер 2.3гб, VS 750мб
Повторное открытие проекта. Райдер 2 минуты. Студия 40 секунд.
Вы знаете, пусть уж 32 бита будет.
VEG
Что-то мне новый экран приветствия не по нраву. Старый был лучше — там и последние новости показывались, и все возможности нового экрана приветствия, плюс он был нормально интегрирован в среду (открывался в виде вкладки). И похоже что настройки для возврата старого экрана приветствия нет — можно только совсем его отключить =(
Если тоже хотите вернуть старый Start Page, проголосуйте за это вот тут.
zhaparoff
Я так понимаю, основная мотивация ввести стартовый экран была в том, чтобы не грузить все тяжеленное UI со старта. Хотя решение спорное, согласен. Учитывая что, скорее всего, большинство при открытии всегда грузит один и тот же солюшен в 80% случаев. Я, например, неделями просто не закрываю студию с основным солюшеном, если что-то надо еще — открываю в другом экземпляре. В настройках стоит «Empty Environment».
VEG
Не вижу разницы в скорости появления этого окна в VS2019 и полноценной стартовой страницы в интерфейсе IDE VS2017. И там и там это занимает меньше двух секунд. Если бы это стартовое окно появлялось мгновенно, то можно было бы понять ещё зачем оно нужно. А так…
Magic_B
Подскажите, кто знает! Когда переходишь на новую строку, таб применяется только полке того как завершишь строку ";". В 2017 жмешь ентер — уже с табом на новой строке....
saintbyte
Микрософту осталось только сделать чтоб всё ставилось быстро, а то я ставил год назад VS и он ставился у меня полдня. Я уже не говорю про приколы с активацией типа открываешь ноут в метро а тебе: «активацию давай».
konoplinovich
Это, видимо, от состава установки зависит. Я вот ставлю только .NET desktop development и 2019 поставилась за полчаса.
Allozorro
Странно, дефолтный набор десктопной разработки ставится минут 15. Более-менее «жирный» набор — минут 40-50. У 2015 версии этот процесс занимал до 1ч и 2,5 ч. соотвественно.
buldo
Минимальное время установки студии — 2.5 минуты. Правда это просто шел, который максимум сможет файлы открывать.
devlev
До сих пор не получается нормально отформатировать простой код на c#. Приходится использовать табы и вручную расставлять нужные отступы. Может в новой версии это исправили.
VS 2017. Версия 15.9.9
IvanNochnoy
Не в этот раз
VEG
Если вы не зарепортили эту проблему с этим примером разработчикам VS, то и не исправят.
devlev
Да репортили уже. Проблема в том что они исправляют ну очень долго. Когда вышла VS2015, они там так поломали форматирование в Razor, что стандартным редактором стало просто невозможно пользоваться. Обычная вставка кода была: CTRL + V, CTRL + Z — потому что после CTRL + V всегда срабатывало автоформатирование которое невозможно не как отключить. Приходилось продолжать пользоваться VS2013 в которой все было нормально с форматированием. И такое отношение явно разочаровывает.
VEG
Значит нужно не полениться поставить плюсик под этот репорт, а то там всего 2 плюсика. Они же явно смотрят на количество плюсов при разборе того на что ругаются пользователи.
ad1Dima
Starl1ght
Выделить кусок, нажать Control, нажать K, отпустить K, нажать F, отпустить F, отпустить Control
devlev
А у вас получилось нормально отформатировать? Я вставил код в студию, удалил пробелы с помощью CTRL + TAB несколько раз, нажал как вы написали
Zam_dev
Инициализация списков обычно не форматируется в VS, тоже не понял причину… возможно в ней не всегда присутствует порядок для выравнивания.
DistortNeo
Скорее всего, для сохранения пользовательского выравнивания.
Аналогично с аргументами функции на несколько строк.
vlivyur
Terras
Хм, судя по числу комментов, в плане .net разработчиков дефицита нет
alier
Вот так новость, у меня уже 2, апдейта на неё прилетело, а тут оказывается VS только вышел.
OrangeCrusty
Что-то я не нашёл, куда они пулл реквесты встроили. Кто-нибудь обнаружил уже?
IvanNochnoy
Pull Requests for Visual Studio
OrangeCrusty
Написано ж было, что интегрировали в IDE
IvanNochnoy
Check out the optional extension available on the Visual Studio Market Place, Pull Requests for Visual Studio, that integrates Pull Request reviews into Visual Studio.
Не Студия интегрирует, а расширение
OrangeCrusty
Ясно, спасибо