Comments 202
Канеш! Я уже кодю на ней под Win7 Embedded x86 в vbox :)
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_xp библиотеками? Формально, проект собирается и бинарники запускаются, но гарантируется ли какая-то работоспособность? Очень хочется получить ответ, пересобрать все зависимости за раз не хочется.
p.s. не уверен, правда, по месту ли это не в профильном блоке MS спрашивать. Но вдруг кто из коллег уже озадачивался этим вопросом.
Может, ещё в каких-то отдельных линуксовых GUIЖёстко вы с Qt.
Скриншот из KDE 5, появилось в 4 версии.
Собственно последняя настройка регулирует не только шрифты, но и вообще весь рендер. Приложения на Gtk естественно в пролёте и емнип рисуются под 96 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 приложение запустили — с таким оно и будет рендериться.
Именно такое поведение я и наблюдал c qt приложениями. Кстати, в винде так же всё работает и, если мне не изменяет память, в gnome в wayland сессии.
среди трёх основных десктопных ОС она только в Windows нормально и реализована
По принципу «чем хуже — тем лучше»? На _одном_ 4к мониторе в Windows беспорядок.
Все программы вразнобой работают, какие-то реагируют на настройку DPI, какие-то нет, да даже в пределах одной программы бывает бардак.
А вот на Маке всё отлично.
Я испытываю проблемы только при смене DPI (подключение по RDP) — не все приложения поддерживают это дело на лету, и система начинает их интерполировать — приходится перезапускать приложения.
В основном проприетарный софт на дотнете
В .NET Framework 4.7 значительно улучшили поддержку HighDPI для старых приложений, написанных на Windows Forms. Возможно, вам стоит ещё поиграться со настройками HighDPI в параметрах совместимости в свойствах приложения.
Ну и последние версии Windows 10 вроде как лучше умееют в HighDPI.
плюс всякое старое говно типа тотал-коммандер
Попробуйте Far Manager.
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.
Интересно как с этой 2019?
Релиз не тестил еще, но TP были тормознее. Обещали какие-то оптимизации по скорости.
механизмов обратной совместимости компиляторов и IDE
Обратная совместимость как раз есть — вы можете в новой IDE переключать на тулсеты старых компиляторов.
А то что вы хотите, это называется прямая, и ее не так просто реализовать.
Представьте, запустили вы новый компилятор, а подсветка кода не работает =) Это очень сильно ударит по имиджу «поддержки» такой фичи. А модель кода портировать в старые версии — это может быть половину кода IDE затрагивать)
(ну и да, тут еще финансовая сторона — скорее всего, продажи бы упали раз так в ндцать, т.к. многие компании покупают лицензии только ради компилятора).
Ну для меня отсутствие идеально точной подсветки не так уж критично по сравнению с тормозами во время работы:)
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.
Я бы не назвал редактор студии удобным. Зубодробительные шорткаты по умолчанию (кто вообще придумал все эти комбинации вроде "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;
И где тут мультикурсор? Это просто выделение блоком, и что с этим дальше делать?
Сначала оно не заработало из-за Goto Ctrl+Mouse в VAssist, потом оно тоже не заработало, потому что в VS2015 этой функциональности нет, она появилась в 2017 судя по ссылке на справку ниже. :)
При поиске/замене несколько точек редактирования тоже доступны? Чтобы не кликать.
оно тоже не заработало, потому что в VS2015 этой функциональности нет«до сих пор»
В первом комменте я написал "вроде бы". :)
На рабочем проекте VS2015 из-за компилятора. Ведь это так "удобно", когда компилятор гвоздями прибит к IDE.
Грязью поливать? Серьёзно? Прямо так написали, словно вы мои слова как личное оскорбление восприняли. Успокойтесь, посчитайте до 10, откройте студию, видите, она чистая, никто её грязью не облил. Можете дальше спокойно работать. :)
Я знаю про тулсеты, но кроме тулсетов есть ещё расширения, например, для CUDA с которыми вечно какие-то проблемы в новых студиях, а также прочие особенности перехода на новые версии студии.
А про компилятор, прибитый к IDE я разве неправду написал? Вы можете скачать и поставить MSVC-компилятор без студии?
Проблема обычно со всякими 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.
Вам никто не запрещает пользоваться ХР до сих пор. Просто почему бы например Win2000 не поддерживать в новой IDE? или Win95? где-то же должен быть предел.
Поддержка ХР была рекордно длительное время, но это не может продолжаться вечно.
Это не просто прихоть маркетинга (иначе бы выкидывали поддержку всего кроме вин10), с т.зр. разработки реально приходится сталкиваться с ограничениями в API. попробуйте-ка всякие TLS и shared_mutex реализовать, когда нативной поддержки нормальной нет)
Я не автор исходного комментария, но у нас такие продукты есть, например http://octonus.com/oct/products/mbox/2.0/. Софт для ограночных предприятий, в которых все было настроено и установки работают много лет. Кстати, расширенная поддержка XP закончилась в 2014 году, всего 5 лет назад. Обновлять систему и останавливать на время производство никому не хочется. Можно поставить клиентов перед фактом, но это не очень здорово скажется на имидже. Тем более, что машины не подключены к интернету и защищаться от уязвимостей им по большому счету ни к чему. А для новых продуктов, конечно, мы требуем Windows7+.
Windows 7 Prof. (64 Bit) / Windows 10 Prof. (64 Bit)
Так что нет у вас XP.
А если для конкретных заказчиков за отдельную цену — ну как-то это не считается. так и 3.1 можно поддерживать за 100500 миллионов
pdf — для новых клиентов. Спасибо, что не поленились посмотреть:)
Если старые всю жизнь сидели на XP, то "либо обновляйся, либо плати" — это повсеместная стратегия ныне, но мы ведь сами не любим, когда с нами так поступают.
Впрочем, в нашем случае проблема решается штатно — вполне хватает VS2015, а уж переходить в бизнес-разработке на свежий компилятор до первой пары сервис-паков — вообще выстрел себе в ногу. Так что пока до VS 2019 очередь дойдет, XP и у оставшихся клиентов умрет своей смертью.
P.s. Вообще, как представлю себе многолетнюю поддержку отдельной ветки приложения на старом компиляторе и версии WinAPI для отдельных клиентов, так и 100500 миллионов выглядят не так уж привлекательно;)
то «либо обновляйся, либо плати» — это повсеместная стратегия ныне, но мы ведь сами не любим, когда с нами так поступают.
Но такова жизнь, альтруистов не много на свете.
Например до сих пор попадаются вакансии на Cobol'e, но это ничего не говорит о каком либо альтруизме по поддержке старых клиентов — а только о том что клиент готов платить отдельные деньги для поддержания его старой, но возможно рабочей, инфраструктуры.
вот кто-то спрашивает на стекеоверфлоу такое же:
stackoverflow.com/questions/48183845/visual-studio-2017-not-detecting-change-in-cu-cuda-files
По вашей же ссылке
Так это же не студийная, проблема а кривая msbuildовая таска у самой куды. Т.е. просто при обновлении msbuild таска работать нормально перестала.
Т.е. претензии к кривой реализации таски msbuildа nvidiей а не к студии.
Потому что оффициально поддержка vs2017 появилось с cuda10.0 и вся либа msvc стала собирабельна nvcc. До этого приходилось юзать костыли в cu файлах.
+ По вашей же ссылке пишут что зачинили в 10.1
кривая msbuildовая таска у самой куды
смотря с какой стороны посмотреть. видел аналогичный тикет на сайте майков где их саппорт довольно мутно в своем стиле уходил от ответа (ссылку сейчас с ходу не нашел). кто-то из них должен был починить наконец-то.
зачинили в 10.1
этого не знал ибо «answered yesterday» по ссылке )) 10.1 еще не рисковал опробовать. посмотрим, если нвидиа озаботилась и подстроилась под 2017 и 2019 то и хорошо.
Хорошо, что поддержку Python допиливают — можно будет соскочить с PyCharm.
Это на фоне последних новостей — на случай, если в PyCharm тоже что-нибудь «отечественное» захотят встроить.
Просто везде где писали на студии enterprise стояла у 1-2х человек а все использовали professional и не парились
Смотря для чего. Если разработка идет на .net core, у студии преимуществ практически нет. А у студии без R# — совсем нет.
Ну и подсветка синтаксиса в Rider хромает: невозможна подсветка операторов отдельным цветом, ещё в VS мне нравится подсветка структур и классов разным цветом.
остановка в момент выброса исключения
Не знаю когда вы пробовали, но такое есть уже довольно давно. Не было Edit & Contrinue, но и его скоро завезут. Не хватает межпроцессной отладки, хотя и довольно специфичный кейс.
А у студии без R# — совсем нет.У R# много крутых вещёй, но так много ли используется?
Как-то видел человека, который самыми используемыми им фичами R# назвал фичи самой студии.
Буквально пара первых пришедших в голову вещей, ради которых плачу, колюсь, но мирюсь с R#
- Умный build. Когда цикл изменил-собрал-запустил в solution из десятка проектов занимает 10 секунд вместо 50, это прямо таки меняет жизнь.
- dotPeek, позволяющий одним тыком посмореть внутреннюю кухню, вместо попыток найти необходимое на github'e
- (спорно, но все же) в нашем небольшом коллективе возможность одной кнопкой причесать код с более-менее вменяемым результатом (раскрыть var'ы и т.п) сильно экономит жизнь как разработчиками, так и ревьюерам
А у rider'a, на мой взгляд, есть родовая травма. Не привычно как-то с 16gb уходить нв 3-4 открытых проектах в глубокий OOM. Кроме этого — нравится, в принципе, все.
Не знаю, а dotPeek нельзя отдельно от R# использовать? конкурентов вроде можно.
возможность одной кнопкой причесать кодсам ещё не пробовал, но в 2019 заявлена поддержка форматирования. но выглядит как-то сложно docs.microsoft.com/en-us/visualstudio/releases/2019/release-notes#dotnet-format
Вообще после Вашей реакции попробовал пожить вместо 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 не особо :)
Кстати, по поводу «по бокам место отожрано». На широкоформатных мониторах это даже плюс, а на обычных, как я уже писал, всё лишнее можно скрыть.
Он-то, конечно, да, настраиваются. Но по факту на экране нужно минимум:
- Solution/team explorer (одна панель)
- Тесты
- Error list
- Output
А в режиме отладки еще diagnostics tools, call stack, watch. Как-то у меня ну совсем не получается это все разместить на одном экране лаптопа с 125/150% масштабированием.
Я вот все панели кроме Solution explorer скрыл и спокойно работаю в студии, когда надо заглянуть в них — беру мышу и заглядываю.
На старом квадратном мониторе Solution explorer я тоже скрывал.
Вот при отладке — да, места резко становится мало. Но, опять-таки, никогда у меня не было задачи, для которой мне бы пришлось смотреть на diagnostics tools, call stack и watch одновременно и никак иначе…
Изменилось ли в этом смысле что-нибудь в VS 2019 по сравнению с VS 2017? Например, в PhpStorm можно искать по папке: правая кнопка → «Find in Path». Спасибо.
Я, видимо, избалован jetbrains.
Хочу:
а) Поиск в scope (вот от этой папки и вниз, за исключением node_modules и *.json)
б) preview результатов до того, как я нажал кнопку "Find all" — например, в случае regexp поиска я не всегда уверен, правильно ли я ли он.
в) Если поиск захватывает json на пару мб, VS зависает на добрую минуту.
г) Хочу контекстный поиск типа "найди мне user
только в комментариях "
Ну и моя давняя претензия к 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 проектов, но это, правда, небольшие микросервисы, и никаких видимых проблем не испытываю.
Аналогичный поиск в студии медленнее и не такой fuzy
Find Using лучше, который позволяет искать например наследников. Но м.б. в студии это уже появилось.
Аналогичный поиск в студии медленнее и не такой fuzyне знаю насчёт скорости. А что значит «не такой fuzy»
Visual Studio for Mac — не пошел, тяжелый, ui — какой-то не тот, стабильность тоже не порадовала и запуск тестов так себе был.
Давно еще пытался использовать Rider — ui от Idea тяжеловат, возможно если настроить, то будет хорошо, но я лучше на VSCode буду, туда бы еще resharper(мечты)
У меня один вопрос, ВС 2019 наконец то стал х64 или все так же остается 32 битным, с ограничением в <2Гб оперативной памяти?
Мда, нечего сказать...
«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.»
Там, как по мне, больше не с памятью трабла, а то что их все эти рефакторинги вычисляются в 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. Но, судя по последним комментам, это вот все до сих пор находится в стадии «мы над этим работаем».
На DotNext в 2015-м был связанный с этим доклад, мне запомнился такой слайд:
я лет 5 не юзал студию (и ReSharper тоже), интересно
Вот список того, что на 95% заменяет ReSharper
Не забудьте: Microsoft.CodeQuality.Analyzers, Microsoft.NetCore.Analyzers.
А затем что это IDE и на дворе не 1999. Ваш браузер наверное раза в два больше кушает памяти, не так ли?
На что браузеры расходуют столько памяти — отдельный вопрос и так себе пример для сравнения. ААА-игры зачастую потребляют меньше.
Upd
Выше написали, и я поддерживаю это мнение, что лимит для x64 OS должен быть в районе 4 Гб для x86 приложений (во всяком случае для тех, которые не творят магии со знаковым битом адреса).
К сожалению, нет возможности проверить данную гипотезу — ибо от R# я отказался с переходом на VS2017 из-за его неадекватной тормознутости и невозможности включать/отключать этот ручной тормоз без полной деинсталляции приложения.
Первый запуск проекта в райдере — 12 минут. Студия за минуту справляется
Память. Райдер 2.3гб, VS 750мб
Повторное открытие проекта. Райдер 2 минуты. Студия 40 секунд.
Вы знаете, пусть уж 32 бита будет.
Если тоже хотите вернуть старый Start Page, проголосуйте за это вот тут.
Подскажите, кто знает! Когда переходишь на новую строку, таб применяется только полке того как завершишь строку ";". В 2017 жмешь ентер — уже с табом на новой строке....
Минимальное время установки студии — 2.5 минуты. Правда это просто шел, который максимум сможет файлы открывать.
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"
} }
};
}
}
}
Да репортили уже.Понятно, почему не фиксят. В этом репорте совершенно не ясно, что сломалось и как должно быть правильно. Поэтому и лайков нет. Хотя б иллюстрации вставили (если это вы репортили).
The key combination (Ctrl+K, F) is not a commandНо даже Ctrl+E,F (Format Selection) не помогает, всё остаётся как на скриншоте.
А от нового синтаксиса методов-расширений они отказались? Помнится они хоте ввести новый синтаксис и позволить еще всякими полями расширять классы без наследования.
Релиз .Net Core намечен на вторую половину 2019 года...
ничего не мешает компилировать компилятором 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.
Выпущена Visual Studio 2019