Pull to refresh

Comments 53

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

Почему же не будет. VS 2017 умеет .Net Core 3.
В инсталляторе отдельного SDK не нашёл, но если скачать SDK и Runtime с сайта Microsoft, то в VS 2017 можно кодить под него.
Один маленький секрет. Заходите в Tools->Options->Projects and Solutions->.Net Core и отмечаете галочку «Use previews of the .NET Core SDK», т.к. третья версия пока в стадии Preview.
После этого можно выбрать .Net Core 3 в свойствах проекта и всё заработает.
А Вы пробовали создать проект прежде чем писать? При создании проекта в VS2017 (с установленной галочкой «Use previews») она пишет: ASP.NET Core 3.0 or newer projects are not supported by this version of Visual Studio. И ссылка на:
github.com/aspnet/Tooling/blob/master/dotnet-core-3.0-preview1.md
Где четко сказано, что .NET Core 3.0 только на VS2019
А Вы? Не буду врать, что проверил весь функционал — просто собрал и запустил консольный проект. Не исключаю, что могут быть проблемы с другими типами проектов — не пробовал, но консольный создаётся и запускается. Вот, специально попробовал ещё раз.

UFO just landed and posted this here
Честно говоря — стыд и позор. Это же чистая косметика, и нужна очень многим. Уже много лет народ просит, в роадмапе когда-то на VS2018 было запланировано.

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

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

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

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

Я понимаю Net-Install для каких-нибудь драйверов весом в 300мб и прочего. Но софт весом 30+гб лишать оффлайнового установщика — издевательство, имхо.
А в чем профит типовые машины не из образа раскатывать, а вручную конфигурить?
В итоге и пришлось настроенную машину клонировать. Но с 5200 HDD это медленно. С оффлайн-установщиком было бы в разы проще.
У меня похожая ситуация, думал клонировать каскадом, т.е. 1 на 1, полученные 2 на 2, и потом на оставшиеся 3 (всего 7 машин). Могут быть косяки с конфигурацией, т.к. из 7 машин 1-2 имеют другие параметры (другая мать?).
Но опечалили жесткие диски — они ~80гиг. Т.е. винда+эта среда + матлаб + еще пару прог… А, нет, все вместе не влезут. Это я не вспоминаю про юнити и Microsoft Office, которые тоже прожорливые. А еще 1С… //(*слышен звук выстрела*)//
тоже интересная ситуация, но есть выходы и «административные штуки» что бы скачать на 1 машину обнову, а на другие типо списать образ, а потом -->
докачалось всего около 3 мегабайт,
В целом согласен, но по этому пункту есть тривиальнейший хак: включаем инет, ставим студию, вырубаем интернет, пишем злодейский код.
когда-нибудь подключаем интернет… и накопленная телеметрия улетает...)
Если в этом плане, пожалуй полностью соглашусь.
Работая в Минских офисах и разных компаниях пока такого не встречал. Надеюсь в не КГБ:)
Я в своё время озадачивался созданием offline-инсталлятора (с целью экономии места и развёртывания одной и той же версии Студии на нескольких компах без необходимости докачивания). Подход описал в блоге. Может, кому-то пригодится. Компоненты нужно будет подбирать под свои нужды — с этим придётся морочиться, но только в первый раз. Потом можно по тому же списку выкачивать новую версию в новый каталог.
На данный момент сижу на 15.8.9 (C++ и C#), инсталлятор занимает ок. 3719 МБ (влезает на компакт).
Если убрать все тулбар-ы, то из-за кнопок в правой части не освобождается свободное вертикальное место :(
image
Особенно странно выглядит кнопка PREVIEW, которая просто дублирует About. На лэптопе занимает дорогое место на экране. Неужели нельзя было это впихнуть рядом с Search Visual Studio и разрешить настраивать?

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


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

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

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

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

Что касается вашего вопроса о 64-битной версии Visual Studio: мы рассматриваем плюсы и минусы добавления 64-битной версии в каждом выпуске — от последствий для экосистемы расширений до влияния на производительность. Visual Studio 2019 мы не планируем делать x64. Тем не менее, мы продолжаем работу, начатую в Visual Studio 2017, по перемещению ресурсоемких компонентов и рабочих нагрузок в отдельные процессы. Например, некоторые ресурсоемкие компоненты языковых служб C#/VB уже выполняются в отдельных процессах, и начиная с Visual Studio 2019, компоненты отладчика C++ будут также выполняться в отдельном процессе.
Когда вы переведёте лицензирование студии на схему десятки (купил один раз и пользуйся апгрейдами)? Сейчас перепокупать студию раз в 2-3 года ни разу не интересно. Не говорю про то, что IDE можно было бы и вообще бесплатно раздавать, что бы окончательно не профукать полимеры.
Окончательно не профукать полимеры? А что, есть начало или предпосылки к нему?
Да как бы тут всё просто: чем ниже уровень входа в разработку на .net, тем большая привлекательность у Azure.
Сейчас купить Idea намного дешевле и проще, чем VS.
Собственно, одна из причин провала WinPhone — это порог входа в разработку. Надо было лицензию покупать, студию да и платформа была довольно закрытая.
Аутсорсерам надо работать на том, что клиенты используют, а часто это чуть ли не ентепрайз. В результате имеем что имеем.
Так это они позже уже сделали. До этого была убогая Visual Studio Express.
И очень правильно, что теперь есть Community на которой сидят все инди.
Конечно, мы также продолжаем поддерживать и улучшать кроссплатформенную разработку на C++

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

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

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

Так и называйте Маквжила как Дункан Маклауд и Макдональдс.
Уж надо называть VS2020, до НГ пара недель осталась :)
UFO just landed and posted this here
Думаю, что это был сарказм на любовь разработчиков называть новые версии своих продуктов следующим годом. Мол, негоже в 2019-м выпускать [ProductName] 2019, и если MS не успевает выпустить VS 2019 в 2018-м, то её следует назвать VS 2020.
С уважением, ваш Кэп.
Еще вопрос от С++ разработчика — есть какие-то планы по работе над скоростью С++ компилятора? а то замедление в 3.5 раза просто при смене 2015-> 2017 вообще не радует.
Спасибо за вопрос.

Что касается компилятора C++, у нас есть новый toolset, который появится в VS 2019, но он не доступен для Preview 1. Он будет доступен в будущем превью.
Спасибо за ответ, буду тестить обязательно.
так в офис 2019 так мало изменений, что смысла переходить с 2016 нет. Они же на 365 сосредоточились, не удивлюсь, если следующий релиз за 2019 будет последним
А xaml и aspx всё так же считаются обычными текстовыми файлами?
А то как-то надоело смотреть на надпись «0 references» над методами типа _OnClick при явной их используемости.
Будет добавлена поддержка XAML.
"-- Угу"
Сказали суровые сибирские мужики и пошли дальше писать в код в блокноте.

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

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

Sign up to leave a comment.