Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 23
Приходит мужик в Майкрософт, к нему менеджер выходит:
- Поздравляю, у вас NET3 и NetStandart!
Мужик довольный весь.
Через минуту:
- Теперь ещё и NET5!
Мужик еще больше обрадовался.
- О, у вас NET6, это такое чудо!
Мужик думает:" Надо же, действительно редкость!"
А менеджер все выходит: NET7, NET8, NET9...
Мужик думает что за хрен там творится? Заходит в опенспейс, а
там разраб в панике и поту по носится и орет:
GIT ГАСИТЕ, GIT! ОНИ ГАДЫ НА GIT ЛЕЗУТ!
Эх, .NET 4,5 и C# 5.0 золотое было время...
Судя по пресс-релизу они ещё сами не особо знаю что бы такого развивать в NET 9 - а это печально когда уже первый превью выпускается....
А вообще ждём развитие EFCore под NativeAOT, а то приличных ORM-ок пока не наблюдается под NAOT...
После выхода Net5 я окончательно запутался что и как надо использовать, чтобы мне, например, сделать простенькое консольное приложение в блокноте. Причём процесс компиляции настолько "упростили" по сравнению с "устаревшим" Net4.5, что без полноценной Visual Studio простые проекты уже особо и не сделать.
Начиная с этого момента все новые релизы дотнета для меня стали выглядеть как "выпустили новую бесполезную фигню"...
Ты втираешь нам какую-то дичь. Давай конкретику, что вызывает у тебя такие затруднения, что dotnet new console & dotnet build вызывает у тебя боль. Я так наоборот чертовски рад возможности забыть большую студию и уйти в vscode, потому что все делается из консоли значительно легче, чем в олдовом net45 или mono
Да, боль. Потому что ему теперь нельзя тупо скормить .cs файл и получить рядом exe/dll. Ему теперь надо "создать проект" с кучей файлов и папок и только потом его компилить. Получая еще кучу лишних файлов. Когда в старом дотнете я мог тупо вызвать "csc.exe /target:exe x.cs" и получить результат. И эту команду можно было без любого гуглежа получить - тупо вызвав "csc /?". А теперь попробуйте почитать встроенную справку которую вам "dotnet /?" и зацените ее полезность.
И я не спорю, что для gui-приложений какая-то среда программирования уже нужна, потому что формы "наощупь" кодить такое себе удовольствие. А для обычных консольных утилит нафига вот это вот всё сделали? Какую проблему они решали? И если они её таки решали, то почему нет возможности использовать и по-старому тоже?
Давай без заламывания рук. По факту без ide кодили три с половиной бородатых мужика которым место в музее религия не позволяет это делать с конца 80х. Нет никакой причины, чтобы ущемиться на dotnet new console. Никакой. Как и на msbuild который внедряется уже больше.. ну второй десяток лет точно.
надо "создать проект" с кучей файлов и папок и только потом его компилить
me@Cora:~/test$ ls
obj Program.cs test.csproj
me@Cora:~/test$ cat test.csproj
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net7.0</TargetFramework>
<ImplicitUsings>enable</ImplicitUsings>
<Nullable>enable</Nullable>
</PropertyGroup>
</Project>
me@Cora:~/test$ rm -R obj
me@Cora:~/test$ dotnet run
Hello, World!нужно два файла. два! один из которых просто содержит базовые настройки, говорящие компилятору на что агриться и какую версию использовать. 8 строк. ой многословно-многословно!
А теперь попробуйте почитать встроенную справку которую вам "dotnet /?" и зацените ее полезность.
Потому что надо читать dotnet --help
me@Cora:~/test$ dotnet --help
Usage: dotnet [runtime-options] [path-to-application] [arguments]
Execute a .NET application.
runtime-options:
--additionalprobingpath <path> Path containing probing policy and assemblies to probe for.
--additional-deps <path> Path to additional deps.json file.
--depsfile Path to <application>.deps.json file.
--fx-version <version> Version of the installed Shared Framework to use to run the application.
--roll-forward <setting> Roll forward to framework version (LatestPatch, Minor, LatestMinor, Major, LatestMajor, Disable).
--runtimeconfig Path to <application>.runtimeconfig.json file.
path-to-application:
The path to an application .dll file to execute.
Usage: dotnet [sdk-options] [command] [command-options] [arguments]
Execute a .NET SDK command.
sdk-options:
-d|--diagnostics Enable diagnostic output.
-h|--help Show command line help.
--info Display .NET information.
--list-runtimes Display the installed runtimes.
--list-sdks Display the installed SDKs.
--version Display .NET SDK version in use.
SDK commands:
add Add a package or reference to a .NET project.
build Build a .NET project.
build-server Interact with servers started by a build.
clean Clean build outputs of a .NET project.
format Apply style preferences to a project or solution.
help Show command line help.
list List project references of a .NET project.
msbuild Run Microsoft Build Engine (MSBuild) commands.
new Create a new .NET project or file.
nuget Provides additional NuGet commands.
pack Create a NuGet package.
publish Publish a .NET project for deployment.
remove Remove a package or reference from a .NET project.
restore Restore dependencies specified in a .NET project.
run Build and run a .NET project output.
sdk Manage .NET SDK installation.
sln Modify Visual Studio solution files.
store Store the specified assemblies in the runtime package store.
test Run unit tests using the test runner specified in a .NET project.
tool Install or manage tools that extend the .NET experience.
vstest Run Microsoft Test Engine (VSTest) commands.
workload Manage optional workloads.
Additional commands from bundled tools:
dev-certs Create and manage development certificates.
fsi Start F# Interactive / execute F# scripts.
user-jwts Manage JSON Web Tokens in development.
user-secrets Manage development user secrets.
watch Start a file watcher that runs a command when files change.
Run 'dotnet [command] --help' for more information on a command.
..но в целом это тоже маркер прогера-ортодокса. Потому что вся исчерпывающая информация давно лежит на https://learn.microsoft.com/ru-ru/dotnet/core/tools/dotnet это норма для сегодняшнего времени, когда интернет есть в каждом утюге.
По факту получается так, что раньше я свои консольные микро-утилиты мог делать в чем угодно, хоть в блокноте. А теперь мне надо полноценную ide использовать. Потому что даже если сделать dotnet new console, то после этого еще сам файл проекта надо будет так же вручную править, а его параметры без бутылки вообще не отредактируешь (и без онлайн-документации). И у msbuild та же самая проблема - 100500 параметров, узнать про которые можно только нагуглив, но даже после этого вручную их править - мазохизм.
А самое главное, я не понимаю - ради чего это всё делается? Что мне прям такого нового дает dotnet new console без чего я раньше на старом дотнете жить не мог?
Причем замечу, разобраться со старым csc - это пара минут. Ну пять - если надо нагуглить как правильно .dll подключить при компиляции. С тем как правильно создать, настроить и собрать проект через dotnet я ковырялся несколько часов - я долго и упорно искал как просто тупо скомпилить один .cs файл но так и не нашел. Что из утилит в итоге оказывается удобнее и лучше?
В ту же копилку идет и nuget - который сам по себе использовать будет только мазохизт. А в рамках ide - ты его и не увидишь, за тебя всё ide сделает.
Ну и, если честно, я постоянно смотрю новости про выход новых версий дотнета - и я в упор не вижу, ради чего мне свои мелкие проектики переводить на эти новые версии. Каких-то радикальных изменений в язык больше не добавляют. Новых библиотек не прибавилось. За все время лично мне полезным было только упоминание, что они доп. оптимизации в компиляторе сделали где-то в районе 6-ой версии.
По факту получается так, что раньше я свои консольные микро-утилиты мог делать в чем угодно, хоть в блокноте. А теперь мне надо полноценную ide использовать.
Не надо. Ты и сейчас можешь работать в блокноте. Оно и раньше с CSC было сложно, ты просто привык.
я в упор не вижу, ради чего мне свои мелкие проектики переводить на эти новые версии
А их надо переводить? Опыт подсказывает, что наколеночные листинги из блокнота, которые автор-артодокс компилит руками из csc ради пары секунд эстетического оргазма.. никому кроме него и не нужны. Мотивация мало кому понятна, и меньше людей этим воспользуются. Это как распространять готовый листинг рограммы на си без make файла.. круг потенциальных пользователей сужается потому что в make install могут все, а вот наоборот - нет. В общем Майкрософт не волнуют половые трудности единиц.
Так я с этого и начал вроде бы: для мелочей был простой и тупой csc, для всего остального ты просто берешь ide и тебя вообще не парит какими там внутри утилитами она проектами рулит. Сейчас же получается так, что простые пути убрали полностью, а то, что осталось "вручную" использовать - мазохизм. Т.е. у тебя банально не остается выбора - только ide. Даже для проектов уровня "пройтись по всем файлам во всех подпапках по заданному пути и сделать 'действие' к ним". Удобно?
Это вот типичный МС последнего десятилетия с подходом "жри че дали". Что вин11, что дотнет, что вон аутлук вместо предельно простого календаря всем запихивают...
Извините, а вы комментарии выше вообще читали?
Читал. Говорю же, на фоне работы со старым csc - новый dotnet тупо неудобен.
Это не означает, что им нельзя сделать всё то же самое, что делал csc. Но приходится делать кучу лишних телодвижений, причем ничего нового и полезного в итоге они не дают и нужны только чтобы это всё заработало "по-новому". Или переходить на полноценную ide вместо какой-нить Visual Studio Code или Notepad++.
Понял, я просто старый тулкит не пользовал никогда, сразу с IDE начинал. Максимум для С++ пользовался. А как дотнет вышел с новыми фичами я сразу его попробовал, кмк нормально. Особенно консольные программки и службы удобно делать. Хотя код всё равно через vscode пишу, давно отвык от Блокнота :D
А в чем проблема использовать IDE, хоть одна причина есть?
Начнем с того, что лично для меня C# - не основной язык. Использую я его исключительно для своих микропроектов, когда надо, например, массово обработать какие-то файлы.
Ну вот у меня задача была: во всех файлах в папке и подпапках определить видеокодек и добавить его в название файла (я постепенно перехожу на h265 и надо понимать где старые версии, а где уже новые).
Ну т.е. эта задача - плёвая, но готовый софт под нее отсутствует. Можно что-то попробовать нагородить через массовое переименование в TotalCommander, но там куча всякого и разбираться и искать плагины дольше, чем написать код самому. Чтобы было понятнее: весь код занимает ровно 77 строчек + внешняя dll для чтения информации о кодеке, скачанная с гитхаба.
Ради этого мне ставить Visual Studio, да? Всё её 100500 гигабайт неведомой, но очень нужной фигни, без которой просто нельзя обойтись? Или Visual Studio Lite - которая давно уже нифига не lite.
А в новом дотнете еще обязательно надо создать аж цельный проект - ради 77 строк кода и одной dll. Удобно! Ведь просто вызвать csc.exe /r:NReco.VideoInfo.dll /target:exe ren.cs - это как-то не по современному же!
Берешь F# и прям из консоли обрабатываешь, делов то)
"целый проект" - это 2-5 строчек файла проекта и файл main.cs с минимум бойлеплейт кода, как в каком-нибудь питоне. IDE для этого кстати ставить не нужно, нужен только Net SDK. В других языках программирования тоже кстати SDK нужен для разработки, так что разницы нет.
Раньше надо было создавать класс Program со статическим методом Main, а сейчас можно сразу писать код, причём для простых случаев даже using не нужен -все уже прописано. Раньше Нужен был монструозный файл проекта с отдельной секцией под каждую из конфигураций, и ссылками на все файлы проекта, а сейчас достаточно тега "Project Sdk="Microsoft.NET.Sdk". Раньше нужен был отдельный файл для NuGet библиотек, а сейчас все в файле проекта.
Раньше нужно было ссылаться на системные библиотеки (штук 10 в типичном проекта), а сейчас достаточно указать нужный SDK. Где вы усложнение тут увидели - я лично не понял. Как по мне, так одни сплошные упрощения. Даже шаблон ASP Net приложения стал в разы проще и лаконичнее: при использовании Minimal API все веб приложение можно уместить в один файл
Вот специально для вас поискал как сейчас делать так как было раньше https://stackoverflow.com/questions/46065777/is-it-possible-to-compile-a-single-c-sharp-code-file-with-the-net-core-roslyn-c/56133028#56133028
М... Ну, полезное оттуда почерпнуть можно. Но я искренне хочу поинтересоваться: вы правда считаете, что вон та портянка кода на баше - это проще чем было?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Microsoft выпустила первую предварительную версию .NET 9 и раскрыла цели разработки новой версии открытой платформы