Comments 202
На windows7 пускается?
Должна:
Канеш! Я уже кодю на ней под Win7 Embedded x86 в vbox :)
Я так понимаю теперь длинный список vcredit-ов которые надо поставить чтобы заработал какой-нибудть автокад пополнится еще одним. Надеюсь имя фала при скачивании будет более информативное чем у предшественников:
www.itechtics.com/microsoft-visual-c-redistributable-versions-direct-download-links
vcredist_x86.exe - VS2005
vcredist_x64.exe - VS2005
vcredist_x86(1).exe - VS2008
vcredist_x64(1).exe - VS2008
vcredist_x86(2).exe - VS2010
vcredist_x64(2).exe - VS2010
vcredist_arm.exe - VS2010
vcredist_x86(3).exe - VS2012
vcredist_x64(3).exe - VS2012
vcredist_arm(1).exe - VS2012
vc_redist.x86.exe - VS2013
vc_redist.x64.exe - VS2013
vc_redist.arm.exe - VS2013
VC_redist.x86.exe - VS2017
VC_redist.x64.exe - VS2017
VC_redist.arm.exe - VS2017
www.itechtics.com/microsoft-visual-c-redistributable-versions-direct-download-links
картинка
Самый главный вопрос, который сейчас волнует нашу команду — в блоге была упомянута обратная совместимость между v140 и v142 тулсетами, т.е. можно в коде, скомпиленном с v142, использовать библиотеки с v140 (vs2015).
А есть ли совместимость с v140_xp библиотеками? Формально, проект собирается и бинарники запускаются, но гарантируется ли какая-то работоспособность? Очень хочется получить ответ, пересобрать все зависимости за раз не хочется.
p.s. не уверен, правда, по месту ли это не в профильном блоке MS спрашивать. Но вдруг кто из коллег уже озадачивался этим вопросом.
А есть ли совместимость с v140_xp библиотеками? Формально, проект собирается и бинарники запускаются, но гарантируется ли какая-то работоспособность? Очень хочется получить ответ, пересобрать все зависимости за раз не хочется.
p.s. не уверен, правда, по месту ли это не в профильном блоке MS спрашивать. Но вдруг кто из коллег уже озадачивался этим вопросом.
Поддержку HiDPI мониторов добавили или нет?
Поддержки hidpi в windows до сих пор нет, на должном уровне, а вы про VS интересуетесь.
Очень странное и ошибочное заявление, среди трёх основных десктопных ОС она только в Windows нормально и реализована. Может, ещё в каких-то отдельных линуксовых GUI, а вот в Gnome и macOS точно нет. У меня два монитора с существенно разным DPI и разными коэффициентами масштабирования, так что все баги я сразу вижу.
Может, ещё в каких-то отдельных линуксовых GUIЖёстко вы с Qt.
Скриншот из KDE 5, появилось в 4 версии.
Собственно последняя настройка регулирует не только шрифты, но и вообще весь рендер. Приложения на Gtk естественно в пролёте и емнип рисуются под 96 dpi.
KDE давно не пробовал. В Gnome нормально реализовано масштабирование, НО только для всех мониторов одинаково, нет раздельного управления, что делает мой второй монитор неюзабельным.
Разный DPI для мониторов не возможен в принципе в X server, собственно одна из фич у Wayland.
Разный DPI для мониторов не возможен в принципе в X server
Неверно, как минимум в Qt поддержка разного dpi реализована.
This will still result in poor rendering when a window spans multiple montiors, but if you can live with a 2-inch bezel in the middle of your window, you can probably survive misrendering due to poor choice of device pixel ratios.Тут дело немножко не в тулкитах. В иксах вы можете назначить RANDR-у разные DPI у мониторов, но поскольку они собираются в один общий framebuffer, то с каким DPI приложение запустили — с таким оно и будет рендериться.
Не совсем так. Если перемещать окно между мониторами, то dpi пересчитывается корректно на лету и окно перерисовывается. Но если растянуть окно на два монитора — тогда да, на одном из них будет либо всё слишком крупно, либо слишком мелко, об этом и написано в вашей цитате. 2-inch bezel in the middle of your window — это имеется в виду рамка самого монитора. ;)
Именно такое поведение я и наблюдал c qt приложениями. Кстати, в винде так же всё работает и, если мне не изменяет память, в gnome в wayland сессии.
Именно такое поведение я и наблюдал c qt приложениями. Кстати, в винде так же всё работает и, если мне не изменяет память, в gnome в wayland сессии.
среди трёх основных десктопных ОС она только в Windows нормально и реализована
По принципу «чем хуже — тем лучше»? На _одном_ 4к мониторе в Windows беспорядок.
Все программы вразнобой работают, какие-то реагируют на настройку DPI, какие-то нет, да даже в пределах одной программы бывает бардак.
А вот на Маке всё отлично.
Что же за софт-то вы используете?
Я испытываю проблемы только при смене DPI (подключение по RDP) — не все приложения поддерживают это дело на лету, и система начинает их интерполировать — приходится перезапускать приложения.
Я испытываю проблемы только при смене DPI (подключение по RDP) — не все приложения поддерживают это дело на лету, и система начинает их интерполировать — приходится перезапускать приложения.
Программерский. В основном проприетарный софт на дотнете плюс всякое старое говно типа тотал-коммандер. Всё вместе это выглядит ужасно.
В основном проприетарный софт на дотнете
В .NET Framework 4.7 значительно улучшили поддержку HighDPI для старых приложений, написанных на Windows Forms. Возможно, вам стоит ещё поиграться со настройками HighDPI в параметрах совместимости в свойствах приложения.
Ну и последние версии Windows 10 вроде как лучше умееют в HighDPI.
плюс всякое старое говно типа тотал-коммандер
Попробуйте Far Manager.
А что у TC не так с HiDPI?
у говно_кодера и и свои и чужие программы говно. Тотал Комаандер отлично идёт на десятке
UFO just landed and posted this here
Минуточку, вы не путайте поддержку со стороны ОС и корявые руки программистов (и/или три года не обновлявшиеся программы). Мой софт ведёт себя правильно, и реализовать это было очень не сложно. А что половина софтописателей до сих пор не осилили то, что должны были сделать года три назад — да, есть такое.
Она и в 2017 есть. В этой вот такую опцию добавили:
Use Visual Studio as a Per-Monitor Awareness application through a new, experimental setting. When on, this setting helps parts of Visual Studio, such as the shell and the editor, render more sharply regardless of your display configuration and/or scaling.
VS как программа поддерживает HiDPI. Генерировать dpiAware-объявление в манифесте тоже умеет. Остальное — дело разработчика, пишущего в VS программы.
Исторически каждая следующая студия была тормознутее предыдущей — как в скорости компиляции (С/С++) так и в плане GUI. Интересно как с этой 2019? И это при том что никаких супер-востребованных фич за все время так и не добавилось. Удобный редактор, дерево проектов, отличный отладчик (куда лучше чем реализация в Qt Creator к примеру). Но все это было еще в VS6 (1998)! Зато скорость работы падает в несколько раз с каждой новой версией. И самое печальное, что нет универсальных механизмов обратной совместимости компиляторов и IDE (т.е. меня вполне бы устроила оболочка скажем от 2005/2008/2010 студий, но компилятор и набор библиотек чтобы был новейший).
Интересно как с этой 2019?
Релиз не тестил еще, но TP были тормознее. Обещали какие-то оптимизации по скорости.
механизмов обратной совместимости компиляторов и IDE
Обратная совместимость как раз есть — вы можете в новой IDE переключать на тулсеты старых компиляторов.
А то что вы хотите, это называется прямая, и ее не так просто реализовать.
Представьте, запустили вы новый компилятор, а подсветка кода не работает =) Это очень сильно ударит по имиджу «поддержки» такой фичи. А модель кода портировать в старые версии — это может быть половину кода IDE затрагивать)
(ну и да, тут еще финансовая сторона — скорее всего, продажи бы упали раз так в ндцать, т.к. многие компании покупают лицензии только ради компилятора).
Если дело только в подсветке синтаксиса, то это ударит по имиджу разработчиков, не предусмотревших элементарную модульность. Подсветка синтаксиса должна описываться простейшими правилами во внешнем файле.
Для C++ это не поможет, для правильной полной подсветки C++11&later кода нужна полноценная code model.
Ну для меня отсутствие идеально точной подсветки не так уж критично по сравнению с тормозами во время работы:)
А кто-нибудь подскажет, как на счет «structured binding» и «if statement with initializer». У меня в 2017 версия 15.8.0 черкает все красным.
Не завезли еще пока.
Должно работать в последней VS2017. Проверьте в настройках проекта что используется актуальный тулсет, а не тот что был в VS2015.
Вы точно включили 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.
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.
Теперь будет ставиться не полдня, а целый день, и занимать не 20, а 40 Гб.
Весь необходимый набор для разработки классических десктопных приложений на C++ у меня вышел менее двух гигабайтов для скачивания (установка выполняется во время скачивания компонентов, так что не сильно больше времени занимает, чем само скачивание) и где-то пять гигабайтов в установленном виде. Главное — отметить только нужные флажки в установщике.
Я бы не назвал редактор студии удобным. Зубодробительные шорткаты по умолчанию (кто вообще придумал все эти комбинации вроде "Ctrl+E, V"), до 2017 не было даже функции "дублировать строку" без затирания буфера обмена через copy/paste, мультикурсор вроде до сих пор не завезли, а также много раздражающих мелочей вроде отсутствия подсветки текущей строки до 2015 (делалось только расширением Visual Assist и т.п.). В общем, по сравнению с современными редакторами редактор классической студии всегда был довольно убогим. VSCode в этом плане шагнул далеко вперед.
Также студия никогда не была особо удобной для разработки на C++, IntelliSense из коробки вообще ни о чём (по сравнению с тем же Visual Assist), отсутствие адекватной поддержки CMake ну и т. д. и т. п.
Кстати, 2010 студия была переписана на WPF, с этого момента начались тормоза и лаги. В следующем релизе они отказались от WPF, но тормоза почему-то остались. Особенно дикие связаны как раз с IntelliSense, которая может тупить по несколько минут при поиске какого-либо символа или при переходе от прототипа к определению функции/класса.
мультикурсор вроде до сих пор не завезлиalt+shift+Click; ctrl+alt+Click;
UFO just landed and posted this here
И где тут мультикурсор? Это просто выделение блоком, и что с этим дальше делать?
Мультикурсор - это вот, например
второе сочетание вы конечно не пробовали…
Пробовал, оно выделяет слово, точно так же как это делает двойной клик.
Сначала оно не заработало из-за Goto Ctrl+Mouse в VAssist, потом оно тоже не заработало, потому что в VS2015 этой функциональности нет, она появилась в 2017 судя по ссылке на справку ниже. :)
При поиске/замене несколько точек редактирования тоже доступны? Чтобы не кликать.
UFO just landed and posted this here
оно тоже не заработало, потому что в VS2015 этой функциональности нет«до сих пор»
В первом комменте я написал "вроде бы". :)
На рабочем проекте VS2015 из-за компилятора. Ведь это так "удобно", когда компилятор гвоздями прибит к IDE.
Использование тулсета из VS2015 поддерживается в VS2019.
UFO just landed and posted this here
Грязью поливать? Серьёзно? Прямо так написали, словно вы мои слова как личное оскорбление восприняли. Успокойтесь, посчитайте до 10, откройте студию, видите, она чистая, никто её грязью не облил. Можете дальше спокойно работать. :)
Я знаю про тулсеты, но кроме тулсетов есть ещё расширения, например, для CUDA с которыми вечно какие-то проблемы в новых студиях, а также прочие особенности перехода на новые версии студии.
А про компилятор, прибитый к IDE я разве неправду написал? Вы можете скачать и поставить MSVC-компилятор без студии?
Я бы не сказал, что проблемы расширений — это прям беда Visual Studio.
Проблема обычно со всякими CMake и т.п. Решения давно уже не меняются внутри. Toolset-ы предыдущих версий можно спокойно ставить через installer.
А MSVC, кстати, можно скачать без IDE (MSVC Build Tools).
Да и VS официально поддерживает GCC и CLang.
Проблема обычно со всякими CMake и т.п. Решения давно уже не меняются внутри. Toolset-ы предыдущих версий можно спокойно ставить через installer.
А MSVC, кстати, можно скачать без IDE (MSVC Build Tools).
Да и VS официально поддерживает GCC и CLang.
скачать и поставить MSVC-компилятор без студии?
есть варианты, начиная с DDK(WDK по новому) или экзотика типа Visual C++ Compiler Package for Python
Visual C++ Compiler Package for Python
Нет, ну это уже совсем экзотика. Они это сделали только для того, чтобы собирать экстеншены для Py27 без установки студии. По сути это уже почти никому не нужно. А вот ответ выше верный, значит я был не прав на счёт компилятора (частично, потому как было время, когда MS эту возможность убрали и убрали компилятор в том числе из Driver Kit)
>Исторически каждая следующая студия была тормознутее предыдущей
Кстати, это не совсем так. Руководствуясь этой логикой я не уходил с 2013, но оказалось, что 2013 была особенно тормозной, а 2015 наоборот заметно ускорилась, и 2017 вроде не потеряла после этого в производительности. Это в GUI, в компиляции у 2013 вообще был какой-то странный баг, который иногда подвешивал мой проект на стадии линковки минут эдак на 5.
Кстати, это не совсем так. Руководствуясь этой логикой я не уходил с 2013, но оказалось, что 2013 была особенно тормозной, а 2015 наоборот заметно ускорилась, и 2017 вроде не потеряла после этого в производительности. Это в GUI, в компиляции у 2013 вообще был какой-то странный баг, который иногда подвешивал мой проект на стадии линковки минут эдак на 5.
К тому же каждая новая версия IDE жрет памяти все больше и больше.
UFO just landed and posted this here
Простите за едкость, у вас-то есть коммерчески успешный продукт, в котором вы продолжаете поддерживать версии вышедшие 20 лет назад? Если да, скиньте ссылочку, будет интересно.
Вам никто не запрещает пользоваться ХР до сих пор. Просто почему бы например Win2000 не поддерживать в новой IDE? или Win95? где-то же должен быть предел.
Поддержка ХР была рекордно длительное время, но это не может продолжаться вечно.
Это не просто прихоть маркетинга (иначе бы выкидывали поддержку всего кроме вин10), с т.зр. разработки реально приходится сталкиваться с ограничениями в API. попробуйте-ка всякие TLS и shared_mutex реализовать, когда нативной поддержки нормальной нет)
Вам никто не запрещает пользоваться ХР до сих пор. Просто почему бы например Win2000 не поддерживать в новой IDE? или Win95? где-то же должен быть предел.
Поддержка ХР была рекордно длительное время, но это не может продолжаться вечно.
Это не просто прихоть маркетинга (иначе бы выкидывали поддержку всего кроме вин10), с т.зр. разработки реально приходится сталкиваться с ограничениями в API. попробуйте-ка всякие TLS и shared_mutex реализовать, когда нативной поддержки нормальной нет)
UFO just landed and posted this here
Я не автор исходного комментария, но у нас такие продукты есть, например http://octonus.com/oct/products/mbox/2.0/. Софт для ограночных предприятий, в которых все было настроено и установки работают много лет. Кстати, расширенная поддержка XP закончилась в 2014 году, всего 5 лет назад. Обновлять систему и останавливать на время производство никому не хочется. Можно поставить клиентов перед фактом, но это не очень здорово скажется на имидже. Тем более, что машины не подключены к интернету и защищаться от уязвимостей им по большому счету ни к чему. А для новых продуктов, конечно, мы требуем Windows7+.
но из пдф по вашей ссылке жеж:
Так что нет у вас XP.
А если для конкретных заказчиков за отдельную цену — ну как-то это не считается. так и 3.1 можно поддерживать за 100500 миллионов
Windows 7 Prof. (64 Bit) / Windows 10 Prof. (64 Bit)
Так что нет у вас XP.
А если для конкретных заказчиков за отдельную цену — ну как-то это не считается. так и 3.1 можно поддерживать за 100500 миллионов
pdf — для новых клиентов. Спасибо, что не поленились посмотреть:)
Если старые всю жизнь сидели на XP, то "либо обновляйся, либо плати" — это повсеместная стратегия ныне, но мы ведь сами не любим, когда с нами так поступают.
Впрочем, в нашем случае проблема решается штатно — вполне хватает VS2015, а уж переходить в бизнес-разработке на свежий компилятор до первой пары сервис-паков — вообще выстрел себе в ногу. Так что пока до VS 2019 очередь дойдет, XP и у оставшихся клиентов умрет своей смертью.
P.s. Вообще, как представлю себе многолетнюю поддержку отдельной ветки приложения на старом компиляторе и версии WinAPI для отдельных клиентов, так и 100500 миллионов выглядят не так уж привлекательно;)
Да мне просто было интересно реально ли кто такое предлагает, имхо — это глупо. Да если код есть, то просто взять «компилятор» другой, поправить одну строчку кода и пересобрать — это дно. А когда надо заморочиться с железом/спец софтом/людьми кто знает как эту старую версию собирать на текущем CI (или поднять старый CI) — это уже другое.
Но такова жизнь, альтруистов не много на свете.
Например до сих пор попадаются вакансии на Cobol'e, но это ничего не говорит о каком либо альтруизме по поддержке старых клиентов — а только о том что клиент готов платить отдельные деньги для поддержания его старой, но возможно рабочей, инфраструктуры.
то «либо обновляйся, либо плати» — это повсеместная стратегия ныне, но мы ведь сами не любим, когда с нами так поступают.
Но такова жизнь, альтруистов не много на свете.
Например до сих пор попадаются вакансии на Cobol'e, но это ничего не говорит о каком либо альтруизме по поддержке старых клиентов — а только о том что клиент готов платить отдельные деньги для поддержания его старой, но возможно рабочей, инфраструктуры.
Есть много программ которые под dos работают. В Германии, например, терминалы у врачей, кассовые аппараты на бензозаправках…
Дык они ж работают на операционке, которая до сих пор поддерживается. А XP в этом году таки всё… кончится…
UFO just landed and posted this here
статью еще не прочитал, но уже сразу хочу срочно спросить, чтобы читать и ставить или остаться на 2015: глюк с ребилдом для CUDA исправили?
Начиная с cuda10 vs2017 офф интегрированаю. Глюков с ребилдами не замечал, киньте ссылку плз.
проблема в том что 2017 не обнаруживает автоматом изменения в cuda-коде, приходится сперва руками очищать и затем билдить. мелочь казалось бы, а в больших солюшенах из нескольких проектов на разных языках — это невероятно бесит. Потому сижу на 2015 где все ок. Кстати, почему Вы говорите, что поддержка куды только с 2017? в 2015 из коробки все ок. нсайт даже для 2010вроде есть официально причем, не? (если что, то использую cuda10.0 + VS2015)
вот кто-то спрашивает на стекеоверфлоу такое же:
stackoverflow.com/questions/48183845/visual-studio-2017-not-detecting-change-in-cu-cuda-files
вот кто-то спрашивает на стекеоверфлоу такое же:
stackoverflow.com/questions/48183845/visual-studio-2017-not-detecting-change-in-cu-cuda-files
Никогда не замечал, т.к. видимо модуль всегда собирался не через msbuildовый саппорт а через свои props-файлы nvcc
По вашей же ссылке
Так это же не студийная, проблема а кривая msbuildовая таска у самой куды. Т.е. просто при обновлении msbuild таска работать нормально перестала.
Т.е. претензии к кривой реализации таски msbuildа nvidiей а не к студии.
Потому что оффициально поддержка vs2017 появилось с cuda10.0 и вся либа msvc стала собирабельна nvcc. До этого приходилось юзать костыли в cu файлах.
+ По вашей же ссылке пишут что зачинили в 10.1
По вашей же ссылке
Так это же не студийная, проблема а кривая msbuildовая таска у самой куды. Т.е. просто при обновлении msbuild таска работать нормально перестала.
Т.е. претензии к кривой реализации таски msbuildа nvidiей а не к студии.
Потому что оффициально поддержка vs2017 появилось с cuda10.0 и вся либа msvc стала собирабельна nvcc. До этого приходилось юзать костыли в cu файлах.
+ По вашей же ссылке пишут что зачинили в 10.1
кривая msbuildовая таска у самой куды
смотря с какой стороны посмотреть. видел аналогичный тикет на сайте майков где их саппорт довольно мутно в своем стиле уходил от ответа (ссылку сейчас с ходу не нашел). кто-то из них должен был починить наконец-то.
зачинили в 10.1
этого не знал ибо «answered yesterday» по ссылке )) 10.1 еще не рисковал опробовать. посмотрим, если нвидиа озаботилась и подстроилась под 2017 и 2019 то и хорошо.
Хорошо, что поддержку Python допиливают — можно будет соскочить с PyCharm.
UFO just landed and posted this here
Это на фоне последних новостей — на случай, если в PyCharm тоже что-нибудь «отечественное» захотят встроить.
А вам прямо нужны фичи из enterprise, для интеграции с architect, построение UML из кода, TTD(единственная наверное полезная фича из Enterprise)?
Просто везде где писали на студии enterprise стояла у 1-2х человек а все использовали professional и не парились
Просто везде где писали на студии enterprise стояла у 1-2х человек а все использовали professional и не парились
Таблицу сравнения посмотрите, не совсем ясно, почему вы студию за 6к выбрали, а не за 250 на месяц без доп плюшек вроде доступа в МСДН, кредита на ажур, курсов и тд и тп.
Если вам нужна полноценная отладка кода, то Rider будет проигрывать студии.
Смотря для чего. Если разработка идет на .net core, у студии преимуществ практически нет. А у студии без R# — совсем нет.
Я про всякие полезные мелочи: остановка в момент выброса исключения, кастомные визуализаторы объектов, нормальная работа с асинхронным кодом и ещё что-то, чем я был сильно недоволен, когда пробовал Rider. Возможно, сейчас всё стало лучше.
Ну и подсветка синтаксиса в Rider хромает: невозможна подсветка операторов отдельным цветом, ещё в VS мне нравится подсветка структур и классов разным цветом.
Ну и подсветка синтаксиса в Rider хромает: невозможна подсветка операторов отдельным цветом, ещё в VS мне нравится подсветка структур и классов разным цветом.
А у студии без R# — совсем нет.У R# много крутых вещёй, но так много ли используется?
Как-то видел человека, который самыми используемыми им фичами R# назвал фичи самой студии.
Буквально пара первых пришедших в голову вещей, ради которых плачу, колюсь, но мирюсь с R#
- Умный build. Когда цикл изменил-собрал-запустил в solution из десятка проектов занимает 10 секунд вместо 50, это прямо таки меняет жизнь.
- dotPeek, позволяющий одним тыком посмореть внутреннюю кухню, вместо попыток найти необходимое на github'e
- (спорно, но все же) в нашем небольшом коллективе возможность одной кнопкой причесать код с более-менее вменяемым результатом (раскрыть var'ы и т.п) сильно экономит жизнь как разработчиками, так и ревьюерам
А у rider'a, на мой взгляд, есть родовая травма. Не привычно как-то с 16gb уходить нв 3-4 открытых проектах в глубокий OOM. Кроме этого — нравится, в принципе, все.
Я не спорю, что есть люди, которые действительно им пользуются. Но некоторые мучаются зря, так как фичи, ради которых они ставят R# уже есть в студии.
Не знаю, а dotPeek нельзя отдельно от R# использовать? конкурентов вроде можно.
Не знаю, а dotPeek нельзя отдельно от R# использовать? конкурентов вроде можно.
возможность одной кнопкой причесать кодсам ещё не пробовал, но в 2019 заявлена поддержка форматирования. но выглядит как-то сложно docs.microsoft.com/en-us/visualstudio/releases/2019/release-notes#dotnet-format
UFO just landed and posted this here
Вообще после Вашей реакции попробовал пожить вместо Rider'a на свежей VS2019 без R#. Как раз надо было попилить UWP приложение, с которым без VS никак. Докладываю о впечатлениях.
- Рефакторинг практически сравнялся. "Причесать код" умеет сама VS, настройки сохраняет в .editorconfig, под автоформат xaml есть прекрасный XAML Styler.
- ILSpy по сравнению с dotPeek — кустарная поделка. По идее, dotPeek можно использовать как отдельный symbol server, но еще не разбирался.
- VS по сравнению с Rider'ом грузится мгновенно. В принципе, 2019 даже по сравнению с 2017 грузится мгновенно. А вот подлагивания на ровном месте никуда не делись.
- Build heuristic не хватает, да. Это никуда не делось.
- Глобальный поиск (не find usages, а ctrl-shift-f который) в Visual Studio ну просто совершенно отвратителен. Дело, в моем случае, усугубляется наличием в проекте кучки json-файлов мегабайт на 40.
- Ну и моя давняя претензия к Visual Studio: в рабочем режиме она выглядит примерно вот так:
. Только еще и по бокам половина места отожрана. На двух мониторах отлично, а вот на лаптопе это форменное издевательство.
. Только еще и по бокам половина места отожрана. На двух мониторах отлично, а вот на лаптопе это форменное издевательство.В целом, ощущение после пары дней у меня следующее: без R# мне оказалось на удивление комфортно. Правда, в самой VS не особо :)
Так ведь все эти панели настраиваются. Лишние всегда можно спрятать или закрыть…
Кстати, по поводу «по бокам место отожрано». На широкоформатных мониторах это даже плюс, а на обычных, как я уже писал, всё лишнее можно скрыть.
Кстати, по поводу «по бокам место отожрано». На широкоформатных мониторах это даже плюс, а на обычных, как я уже писал, всё лишнее можно скрыть.
UFO just landed and posted this here
Он-то, конечно, да, настраиваются. Но по факту на экране нужно минимум:
- Solution/team explorer (одна панель)
- Тесты
- Error list
- Output
А в режиме отладки еще diagnostics tools, call stack, watch. Как-то у меня ну совсем не получается это все разместить на одном экране лаптопа с 125/150% масштабированием.
Так если они нужны вам, то в чём суть претензий к студии?
Я вот все панели кроме Solution explorer скрыл и спокойно работаю в студии, когда надо заглянуть в них — беру мышу и заглядываю.
На старом квадратном мониторе Solution explorer я тоже скрывал.
Вот при отладке — да, места резко становится мало. Но, опять-таки, никогда у меня не было задачи, для которой мне бы пришлось смотреть на diagnostics tools, call stack и watch одновременно и никак иначе…
Я вот все панели кроме Solution explorer скрыл и спокойно работаю в студии, когда надо заглянуть в них — беру мышу и заглядываю.
На старом квадратном мониторе Solution explorer я тоже скрывал.
Вот при отладке — да, места резко становится мало. Но, опять-таки, никогда у меня не было задачи, для которой мне бы пришлось смотреть на diagnostics tools, call stack и watch одновременно и никак иначе…
UFO just landed and posted this here
Было бы удобно искать по реальным файлам проекта, но при этом исключить из поиска используемые библиотеки, формально тоже являющимся частью проекта.
Изменилось ли в этом смысле что-нибудь в VS 2019 по сравнению с VS 2017? Например, в PhpStorm можно искать по папке: правая кнопка → «Find in Path». Спасибо.
Изменилось ли в этом смысле что-нибудь в VS 2019 по сравнению с VS 2017? Например, в PhpStorm можно искать по папке: правая кнопка → «Find in Path». Спасибо.
Я, видимо, избалован jetbrains.
Хочу:
а) Поиск в scope (вот от этой папки и вниз, за исключением node_modules и *.json)
б) preview результатов до того, как я нажал кнопку "Find all" — например, в случае regexp поиска я не всегда уверен, правильно ли я ли он.
в) Если поиск захватывает json на пару мб, VS зависает на добрую минуту.
г) Хочу контекстный поиск типа "найди мне user только в комментариях "
Кажется это прямой путь в developercommunity.visualstudio.com
Ну и моя давняя претензия к Visual Studio: в рабочем режиме она выглядит примерно вот такОчень странно, я сразу открепляю лишние панели и у меня в дебаге UWP VS2019 выглядит так
Глобальный поиск (не find usages, а ctrl-shift-f который) в Visual Studio ну просто совершенно отвратителен. Дело, в моем случае, усугубляется наличием в проекте кучки json-файлов мегабайт на 40.Хм…
1) он позволяет искать по проектам, по открытым файлам и поо пути.
2) вы часто именно по строкам ищите? точно ctrl+, не подходит?
Умный build. Когда цикл изменил-собрал-запустил в solution из десятка проектов занимает 10 секунд вместо 50, это прямо таки меняет жизнь.
А за счёт чего магия возможна?
А у rider'a, на мой взгляд, есть родовая травма. Не привычно как-то с 16gb уходить нв 3-4 открытых проектах в глубокий OOM.
Если не секрет, насколько большие проекты? Регулярно работаю на 16Gb с солюшенами на 10-15 проектов, но это, правда, небольшие микросервисы, и никаких видимых проблем не испытываю.
Search Everywhere киллер фича.
Аналогичный поиск в студии медленнее и не такой fuzy
Find Using лучше, который позволяет искать например наследников. Но м.б. в студии это уже появилось.
Аналогичный поиск в студии медленнее и не такой fuzy
Find Using лучше, который позволяет искать например наследников. Но м.б. в студии это уже появилось.
UFO just landed and posted this here
Аналогичный поиск в студии медленнее и не такой fuzyне знаю насчёт скорости. А что значит «не такой fuzy»
мои 5 копеек: для python лучше IDE чем Komodo не встречал. но он слегка платный.
UFO just landed and posted this here
я начал использовать vscode для нового проекта — в целом нормально.
UFO just landed and posted this here
У меня один вопрос, ВС 2019 наконец то стал х64 или все так же остается 32 битным, с ограничением в <2Гб оперативной памяти?
Reddit говорит, что IDE 32-битная.
А зачем IDE жрать больше 2 ГБ?
Если используется ещё и 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.»
«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.»
так extensionы уже давно можно в отдельные host-процессы выносить в чем проблема то, так много уже кто делает тот же assist вроде так умеет
По поводу 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. Но, судя по последним комментам, это вот все до сих пор находится в стадии «мы над этим работаем».
Там, как по мне, больше не с памятью трабла, а то что их все эти рефакторинги вычисляются в 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. Но, судя по последним комментам, это вот все до сих пор находится в стадии «мы над этим работаем».
Ну, про Roslyn они изначально (ещё до анонса Rider) заявили, что не будут его использовать по причинам «там доступно не всё, что нам надо» и «нам для этого пришлось бы R# чуть ли не с нуля переписать». Можно спорить, правильное ли это решение, но всё-таки тут не «годами ждут непонятно чего для миграции», а «сразу приняли решение не мигрировать и ничего не ждут».
На DotNext в 2015-м был связанный с этим доклад, мне запомнился такой слайд:
На DotNext в 2015-м был связанный с этим доклад, мне запомнился такой слайд:
UFO just landed and posted this here
почему?
я лет 5 не юзал студию (и ReSharper тоже), интересно
я лет 5 не юзал студию (и ReSharper тоже), интересно
Вот список того, что на 95% заменяет ReSharper
Не забудьте: Microsoft.CodeQuality.Analyzers, Microsoft.NetCore.Analyzers.
А затем что это IDE и на дворе не 1999. Ваш браузер наверное раза в два больше кушает памяти, не так ли?
У меня установлен Visual Assist, никогда не видел расход памяти больше 700 МБ процессом VS. Спасибо, не нужно, чтобы единственная хорошая IDE под Windows стала жрать столько же, сколько поделки JetBrains на Java.
На что браузеры расходуют столько памяти — отдельный вопрос и так себе пример для сравнения. ААА-игры зачастую потребляют меньше.
На что браузеры расходуют столько памяти — отдельный вопрос и так себе пример для сравнения. ААА-игры зачастую потребляют меньше.
Скачайте хромиум, сгенерите для него студийные проекты, откройте и попробуйте чуть-чуть подебажить. Увидите как студия весело откушает всю доступную 32-хбитному процессу память под дебаг-символы и свалится (или повиснет).
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Может я чего-то недопонимаю… 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 из-за его неадекватной тормознутости и невозможности включать/отключать этот ручной тормоз без полной деинсталляции приложения.
Upd
Выше написали, и я поддерживаю это мнение, что лимит для x64 OS должен быть в районе 4 Гб для x86 приложений (во всяком случае для тех, которые не творят магии со знаковым битом адреса).
К сожалению, нет возможности проверить данную гипотезу — ибо от R# я отказался с переходом на VS2017 из-за его неадекватной тормознутости и невозможности включать/отключать этот ручной тормоз без полной деинсталляции приложения.
Я вчера ради прикола поставил райдер чтобы сравнить скорость в нашем текущем солюшене.
Первый запуск проекта в райдере — 12 минут. Студия за минуту справляется
Память. Райдер 2.3гб, VS 750мб
Повторное открытие проекта. Райдер 2 минуты. Студия 40 секунд.
Вы знаете, пусть уж 32 бита будет.
Первый запуск проекта в райдере — 12 минут. Студия за минуту справляется
Память. Райдер 2.3гб, VS 750мб
Повторное открытие проекта. Райдер 2 минуты. Студия 40 секунд.
Вы знаете, пусть уж 32 бита будет.
Что-то мне новый экран приветствия не по нраву. Старый был лучше — там и последние новости показывались, и все возможности нового экрана приветствия, плюс он был нормально интегрирован в среду (открывался в виде вкладки). И похоже что настройки для возврата старого экрана приветствия нет — можно только совсем его отключить =(
Если тоже хотите вернуть старый Start Page, проголосуйте за это вот тут.
Если тоже хотите вернуть старый Start Page, проголосуйте за это вот тут.
Я так понимаю, основная мотивация ввести стартовый экран была в том, чтобы не грузить все тяжеленное UI со старта. Хотя решение спорное, согласен. Учитывая что, скорее всего, большинство при открытии всегда грузит один и тот же солюшен в 80% случаев. Я, например, неделями просто не закрываю студию с основным солюшеном, если что-то надо еще — открываю в другом экземпляре. В настройках стоит «Empty Environment».
Подскажите, кто знает! Когда переходишь на новую строку, таб применяется только полке того как завершишь строку ";". В 2017 жмешь ентер — уже с табом на новой строке....
Микрософту осталось только сделать чтоб всё ставилось быстро, а то я ставил год назад VS и он ставился у меня полдня. Я уже не говорю про приколы с активацией типа открываешь ноут в метро а тебе: «активацию давай».
Это, видимо, от состава установки зависит. Я вот ставлю только .NET desktop development и 2019 поставилась за полчаса.
Странно, дефолтный набор десктопной разработки ставится минут 15. Более-менее «жирный» набор — минут 40-50. У 2015 версии этот процесс занимал до 1ч и 2,5 ч. соотвественно.
Минимальное время установки студии — 2.5 минуты. Правда это просто шел, который максимум сможет файлы открывать.
До сих пор не получается нормально отформатировать простой код на c#. Приходится использовать табы и вручную расставлять нужные отступы. Может в новой версии это исправили.
VS 2017. Версия 15.9.9
VS 2017. Версия 15.9.9
Код со скрина
using System.Collections.Generic;
namespace TempProject
{
public class Temp
{
public static void Example()
{
Dictionary<string, object> temp = new Dictionary<string, object>
{
{ "a","a" },
{ "b","b" },
{ "c",new {
a = "qwe"
} }
};
}
}
}
UFO just landed and posted this here
Если вы не зарепортили эту проблему с этим примером разработчикам VS, то и не исправят.
Да репортили уже. Проблема в том что они исправляют ну очень долго. Когда вышла VS2015, они там так поломали форматирование в Razor, что стандартным редактором стало просто невозможно пользоваться. Обычная вставка кода была: CTRL + V, CTRL + Z — потому что после CTRL + V всегда срабатывало автоформатирование которое невозможно не как отключить. Приходилось продолжать пользоваться VS2013 в которой все было нормально с форматированием. И такое отношение явно разочаровывает.
Значит нужно не полениться поставить плюсик под этот репорт, а то там всего 2 плюсика. Они же явно смотрят на количество плюсов при разборе того на что ругаются пользователи.
Да репортили уже.Понятно, почему не фиксят. В этом репорте совершенно не ясно, что сломалось и как должно быть правильно. Поэтому и лайков нет. Хотя б иллюстрации вставили (если это вы репортили).
Выделить кусок, нажать Control, нажать K, отпустить K, нажать F, отпустить F, отпустить Control
Хм, судя по числу комментов, в плане .net разработчиков дефицита нет
Вот так новость, у меня уже 2, апдейта на неё прилетело, а тут оказывается VS только вышел.
Что-то я не нашёл, куда они пулл реквесты встроили. Кто-нибудь обнаружил уже?
UFO just landed and posted this here
А не слышно, когда фичи C# 8.0 окончательно завезут, а не в виде предварительной версии?
А от нового синтаксиса методов-расширений они отказались? Помнится они хоте ввести новый синтаксис и позволить еще всякими полями расширять классы без наследования.
А от нового синтаксиса методов-расширений они отказались? Помнится они хоте ввести новый синтаксис и позволить еще всякими полями расширять классы без наследования.
Релиз .Net Core намечен на вторую половину 2019 года...
А разве Core и C# 8.0 как-то взаимосвязаны? Например, ничего не мешает компилировать компилятором C# 7.0 под какую-нибудь старую версию .Net Framework.
ничего не мешает компилировать компилятором C# 7.0 под какую-нибудь старую версию .Net Framework.C# с 4го по 7й работает на 4й версии CLR. Для C# 8 они вроде новую версию CLR делают. Конкретнее вот так:
Many of the C# 8.0 language features have platform dependencies. Async streams, indexers and ranges all rely on new framework types that will be part of .NET Standard 2.1. As Immo describes in his post Announcing .NET Standard 2.1, .NET Core 3.0 as well as Xamarin, Unity and Mono will all implement .NET Standard 2.1, but .NET Framework 4.8 will not. This means that the types required to use these features won’t be available on .NET Framework 4.8. Likewise, default interface member implementations rely on new runtime enhancements, and we will not make those in the .NET Runtime 4.8 either.
Sign up to leave a comment.
Выпущена Visual Studio 2019