.NET Core 3.0(devblogs.microsoft.com) |
.NET Core 3.0(devblogs.microsoft.com) |
Also, Visual Studio is an insane IDE. Although, I recently did have some nasty bugs but updates are coming out pretty quickly.
Edit: Microsoft has also added many new videos to help beginners, these cover various topics https://dotnet.microsoft.com/learn/videos.
Being an early adopter sucks unless you're just testing it out. If it's your job then wait for it to stabilise and for the real-world bug fixes.
The next Long Term Support version of .NET Core will be 3.1. It should be out in November.
If you had to rank and list the top rough spots in the transition, what would they be? Entity-Framework changes are often cited, but what else is different enough?
So far I’ve done some WCF SOAP work, and an ASP.NET MVC 5 application. Figuring out what the latest frameworks and tools is a bit of legwork. Things aren’t always clear, and not always well integrated.
Figuring out authentication was not clear, whether to use Membership, Identity, where OWIN fit into the picture. If you need custom authentication finding details is hard. Ultimately I figured it out, but it’s clear as mud from a fresh eyes standpoint.
Then setting up DI, which container? Well I had Core DI available, figured that would be a good choice. Except I have to write a good bit of glue code to make it work.
I’m definitely enjoying C# as a language and the standard library. But the ecosystem is a bit clunky.
It just feels very clunky in comparison. I have to remember so many things, which I invariably can't so I have to look them up.
I find EF Core pretty straightforward.
If cost is a concern, there's Rider or even MonoDevelop.
That and I never got to develop successfully beyond Forms - which I wish was not in preview from designer standpoint. I know old tech, but frankly for older programmers I find it easier and quicker to get stuff up with.
- https://devblogs.microsoft.com/dotnet/announcing-net-core-3-...
- https://devblogs.microsoft.com/aspnet/asp-net-core-and-blazo...
- https://devblogs.microsoft.com/dotnet/announcing-f-4-7/
- https://devblogs.microsoft.com/dotnet/announcing-ef-core-3-0...
- https://dotnet.microsoft.com/download/dotnet-core (if you're on 2.2 you have until the end of the year to update to 3.1, which will be LTS)
- https://www.dotnetconf.net/ live now
Shame about the bad timing with the UN summit: http://webtv.un.org/
static State ChangeState(State current, Transition transition, bool hasKey) =>
(current, transition) switch
{
(Opened, Close) => Closed,
(Closed, Open) => Opened,
(Closed, Lock) when hasKey => Locked,
(Locked, Unlock) when hasKey => Closed,
_ => throw new InvalidOperationException($"Invalid transition")
};https://devblogs.microsoft.com/dotnet/performance-improvemen...
How could a mature standard library / frameworks have so much performance gains to be had?
Also, is Java working on this too? I heard that they have Maybe, but that's pointless without non nullability.
There are some really good write-ups by the C# team on the creation of non-nullable types and how it's implemented but my google-fu is failing me on it.
It's obviously a bit a of hack involving annotations/attributes but for the end user the result is pretty seamless.
In other words: I used to have `null` problems. Then I used `Optional`, and now I have two `null` problems!
We've been using the server-side components for lots of internal apps. It's very fast and productive to work with, and a great option for internal/enterprise/LOB apps that don't have a lot of users and can handle an occasional reconnection/interruption.
Not knowing much about Blazor, what are you referring to here? The size of the WASM blob for your own code, or does Blazor have an associated runtime that's large? And what is considered "large"?
I'm really rooting for the project to gain some support. Right now I'd love to try porting our custom UI component at work to Avalonia, just to try it out. But that's time not well invested in something with little backing and potentially few customers for us.
I am not the biggest fan of HTML, but considering the maturity of that ecosystem, design tools and knowledge among designers, that could be a very valid move.
That's a big deal! Nice.
Azure has started investing heavily in offloading the task from CPU to GPU and FPGA. There are really good framework on .NET to achieve the same.
NVIDIA CUDA GPU - https://devblogs.nvidia.com/hybridizer-csharp/
GPU scripting and CUDA - http://www.aleagpu.com/release/3_0_4/doc/
FPGA - https://hastlayer.com/project, https://netfpga.org/site/#/
I hope Java gets this one day.. would be a cool feature
MS does this sort of thing a good amount, preserving backwards compatibility but enhancing the experience.
Anyone recently migrated projects from ASP.NET MVC to ASP.NET Core? I hope there is a gradual way, like this: https://www.hackernoon.com/how-to-migrate-project-from-aspne...
The largest change is dependency injection and Entity Framework. DI is insanely better and just more intuitive. EF is really a move from EF to EF Core which has quite a few differences that can introduce some road bumps.
In my opinion, I've gained the most from moving from HTML helpers in Razor to Tag Helpers. It's basically just components for Razor, but it allows us to make a really nice UI library and cuts down on so much of our markup without having to write a bunch of overloads for the same helper.
As far as MVC vs. Razor Pages, I'm still not in love with Pages. It feels a bit too much like ASP.NET Web Forms did. I still use MVC practices and it's almost the same exact experience. AJAX forms are a bit better this time around, but I'm really waiting until Blazor becomes more viable before I make a jump like that.
That isn't true. You can target .Net framework 4.0 onwards.
It's also possible to build an Electron wrapper around an ASP.NET Core web app: https://github.com/ElectronNET/Electron.NET
How you approach this is very dependent on where you're coming from (i.e. existing solution) but with WPF and Winforms now part of Core 3.0 you can then build a native, single exe by specifying the target architecture (ex: win x64) and then bundling the framework with your app. They do some trimming as well (i.e. tree shaking) to get the exe size down but have admitted it's still in early stages and sometimes drops required framework components. You can fix this by adding an explicit reference to the assembly in your project source though...
There are a million ways to get onto different platforms though, ranging from the above, to xamarin to electron (via blazor), to net-new apps, etc.
.NET was always really solid tech. Microsoft has always had stellar developer technology. But the love affair with open source and the super villain role that Microsoft played, is what kept people away, not the tech itself.
I remember wanting to give a talk about how amazing C# was to a ruby group. I never did it, but it was definitely a quaint idea in 2011. But rubyists would’ve loved C#.
As a Rubyist, I'll admit that C# is the least bad of the C++/Java style of static OOP languages, but it was that it was always too tied to the .NET ecosystem and heavyweight enterprise tooling more than Microsoft's “supervillian role” with regard to FOSS that made it unattractive for lots of places where I would want to use Ruby. That's improved with Core, somewhat.
Now the Windows exclusivity of .NET is no longer a thing it's much, much more appealing (who wants to run Windows Server over a Linux server if they can avoid it?).
What we have seen over the years is:
1. Deploying on Windows became less popular, partly because it was much harder to manage at scale than Linux, and partly because of the price of licensing.
2. Mono was seen as a toy, and is often considered a critical risk by purchasers. This was even true after Microsoft bought Xamarin, and thus de-facto control of the project, and despite the fact that it was far easier to patch bugs in the open source runtime than in the closed-source .NET Framework (and we ran into several in each).
C# (and even more so F#) is a great language, but was hamstrung early on by Microsoft's approach to competition - I think had this been different early on, the world would look very different with respect to popularity for critical infrastructure vs the JVM. Whether it's late enough to salvage something for a large number of non-traditional-MS is debatable - it will be interesting to see how it plays out over the next few years.
And in 2.1 https://devblogs.microsoft.com/dotnet/performance-improvemen...
3.0 has new JIT capabilities like CPU hardware intrinsics; devirtualization; Span etc which in turn enable new techniques in the standard library.
Though 3.0 is a vast set of improvements compared to the previous two
IMO, .NET Framework should be relegated to the dustbin of history. There is no longer a reason to use it unless you are writing legacy code (which, granted, is a legitimate reason in many cases). For greenfield projects, I hope you're using .NET Standard and .NET Core.
I suspect that the CLI and the JVM are about as fast, about 2 to 10 times slower than C++. But that .nets libraries are more performant.
It's not a direct comparison, because the features aren't quite the same, but the Electron Teams app uses about 10x more memory than the relatively heavy WPF Skype for Business client that it's supposed to replace.
But now that .NET runs everywhere, it has to compete with projects that have been shipping performance improvements all along. Happily, since it's now open-source too, it can accept those changes from anyone.
This yields some constraints in whatever is possible changing. Want to add new IL instructions? No can do. Need to change the debugger API? No can do.
Please also see this: https://news.ycombinator.com/item?id=18364032
Using one of the enterprise frameworks, sure, those all have boilerplate, in any language, especially the older frameworks.
And for some tasks, the amount of boilerplate is tiny. I can write out a struct/class with property names matching my JSON, and watch as C# automatically data binds the JSON to a UI. The amount of boilerplate I need to do that in the browser is pretty much identical, or I can learn / figure out some fancy auto-binding toolkit that has its own boiler plate and learning curve.
You can be seriously functional in C#. Passing around lambdas and using functional techniques to manipulate data has been idiomatic C# for over a decade.
> I've also noticed that most C# programmers don't usually know another language
Stereotyping is not good. I <3 C#, but I've written embedded C, C++, JavaScript, Typescript, and Python.
If you go to most corporate dev places, you will find a significant population of single language devs. Same things happen with any popular corporate language. While I agree that learning multiple programming languages makes for better developers, blaming a language for being popular is hardly fair.
Heck the number of developers who have historically only worked in C/C++ was really high for multiple decades.
You also might need to find better C# programmers as I honestly don't know any C# programmers who only know one language or one editor. An awesome IDE is big perk to development. I don't think that should be considered a con.
.NET also has tons of "magic features" like Data Annotations & Attribute Tags for those who want some magic that reduces code & helps get stuff done faster.
JS & other languages reference it when looking to introduce new features.
C# is anything but dated. One could call it bloated as it is one of the most flexible languages with about 10 ways to do anything. That is a strength & a weakness of any language that positions itself as a Swiss army knife type tool that wants to be able to be used everywhere. With C# you can write a lot of nice fairly functional programming style code & OOP code which is a nice perk.
It's the most practical functional language that I've tried. Great for domain modeling and it can used in C# projects.
I also think that c# is too verbose so what I normally do: asp.net core mvc for routing, templating, authentication / authorization, data access etc and then reference an f# project that contains the domain logic. The best of both worlds.
If you're a C# dev who hasn't dug in to reflection yet, the gist is that all the things that the MVC, ORM, DI frameworks do, you can also do. This allows you to build custom frameworks which eliminate boilerplate.
.Net (and Java) run the Fortune 1000 so there will of course be lots of devs specialized in that. There's nothing wrong with being very good with 1 language and stack when you're paid to be productive for the company. Also you can definitely write C# with a simple text editor if you have to, and VSCode is pretty slim already, but why would you want to when there's such a powerful IDE available?
This sounds like a purity argument about how to be a "real programmer", but I would much rather work with people who are good at what they do and get things done instead.
Yeah, it requires more lines to achieve the same thing in other languages, that isn't a pro or con.
And myself personally, I started with Basic, and have used C++, C, Python, Java, JS and C# throughout my career, but I'm also sure you can find many more Python/Go developers who only know Python/Go
It'a unfortunate you don't like the language and I hope Microsoft and the open-source developers continue to add more features so that one day you'll find the joy may developers have found in using C#
I wrote a console application to splat some addresses in a hex file with version info and keys. Difficulty you want to be able to diff the files afterwards. Was pretty trivial.
But I definitely lean on the intellisense of the IDE fairly regularly, I don't think I would completely lost, but it would take me longer.
"talk to more C# devs from different kinds of businesses"
As a PHP dev who's done C#, Java, Perl, CF, VB and more... I'd rarely find any other PHP devs at our local MS and Java user groups. In a few cases, I was the first "PHP developer" some of these people had ever met.
Java/C# tend to be used in larger enterprises, and they tend to be used by people who are... somewhat more 'corporate' in their life. Go to work, do the job, go home - going to local groups/conferences and socializing with non-work tech folks is often not high on their priority list (family, etc may rank higher).
Maybe it's generalizing some, but it's also a lot of my experience over the past 20+ years. I've met some phenom tech/dev folks at pretty much every event I go to, and I meet more "professional" polyglots today than I did 15 years ago, but I found I had to make an effort to find them (beyond just going to my own favorite events).
- https://github.com/aspnet/AspNetCore/issues/13696 - https://github.com/aspnet/AspNetCore/issues/13715
(Edit: corrected first link)
They're working on making the runtime smaller and faster to start still a lag since your code has to be parsed and interpreted everytime, although the DLLs are pretty small already and easily compressed.
If I remember correctly, for example, the @NotNull annotation in javax.validation.constraints cannot be used for a local variable, but the one provided by the checkerframework can.
I'm happy to never need to use R# anymore.
It took a while to configure the colour scheme to something I was comfortable with, but otherwise the experience has been really positive - I love it!
Can even do Type-checking now thanks to Stripe! https://sorbet.org/
Play around with the f# language (don't touch the js inter-op) until you can figure out if you actually like f#. Take it slow, it's not just a new language, it's a different paradigm. If you get frustrated, take a break for a few days, watch some f# videos and let the knowledge settle. You'll eventually start having evrika moments.
Look into other functional languages. Maybe you'll like others more. Accumulate knowledge and experience until you start thinking "I could do this a lot simpler in f# (or other lang)".
Then, if you want to use f# in a c# project you just need to learn how to reference a project in another project.
If you want some resources: https://fsharpforfunandprofit.com/video/ some of these videos can get you "hyped up" for functional languages
https://www.youtube.com/watch?v=4YO4XmtPFQw
https://www.youtube.com/watch?v=EPfpO_6uFAA
the entire https://fsharpforfunandprofit.com/ site is a good resource to learn everything from the basics to the wizard level stuff.
As an editor you can use Visual Studio but I'd recommend Visual Studio Code with the Ionide extension.
Last CRUD app I did in WinForms:
1. Auth
2. Real time push updates from my database
3. Platform native looking UI
4. Automatic 2 way data binding between my backing JSON and my UI controls.
I hadn't used C# for ~2 years, I had never used that particular DB library or done any work with JSON in C#.
I got it done in under 4 hours.
If I did it now, yeah, even faster.
The amount of code I wrote is insanely tiny. I wanted some custom date/time formatting stuff so I had to implement that myself.
I just checked the source out, I wrote under 120 LOC total, and that is including the repetitive ~70 LOC I did for handling days of the week and auto-formatting user entered times. (Time sucks, working with time sucks.)
Without that my code would've been limited to:
1. Wiring login button up to sending username/password to the DB 2. Attaching a listener to the DB (C# has had native event handling as a primitive type since forever!) 3. The save button to push stuff to the DB.
Did I have to drag and drop some UI elements onto a page? I sure did. It was rather nice.
WinForms was the go to solution for CRUD apps for a reason. Sure VB6 was probably better at popping CRUD apps out in no time, but after that died out, WinForms was a really good replacement.
MVC 5 to Core should be a pretty easy transition if you know DI.
But I'm far more interested by real world user facing performance metrics such as: FPS, vsync consistency, input latency and comparing cpu and gpu usage (thus allowing to infer battery usage).
Disclaimer: I do not generally encourage the usage of PHP :)
VS Code doesn't come close.
I use VS Code when doing front end stuff with Vue/TypeScript and I love it for that, but .NET Core was painful on VS Code compared to Rider.
Since dotnet core includes a CLI executable, I interact with the project through the CLI. I manually edit the config files. I could run the stack from a netbook if I wanted to.
VS has had it's own F# problems. The latest Preview edition is pretty solid, with one annoying bug. Almost every time I open my big multi-project solution I need to rebuild to get Intellisense to eliminate the red squigglies, and then close VS and re-open. It's a known issue. Hope MS fixes it soon.
await new HostBuilder().ConfigureServices((context, services) => { // services.AddTransient.... }).UseConsoleLifetime().Build.RunAsync()
That required a custom provider (trivial), and non-obviously a custom ControllerFactory as I picked Core DI instead of a more fully-fledged solution.
Unfortunately there is very little obviousness in documentation and germs often get conflated and confused. Perhaps this is MS trying to get me to take one of their infamous certification courses?
If anything, I'd say there's less choice in the Ruby world, especially in the data science and ML fields.
I came from the Java ecosystem to .NET and even they are different. The .NET ecosystem was held back a little by the lack of embracing open source at the beginning and being super commercially focused. So things like finding a good library for easily working with PDF will set you back $400 rather than just using the defacto library that everyone has used forever and is free. I've encountered that with PDF libraries, rules engines, workflow engines, job scheduling libraries.
It's still a decent ecosystem, it just is different because of its roots.
If you were knowledgeable, you would know for example that chromium 2D rendering engine (skia) is the current state of the art. Benchmarking fps, vsync stability, input latency, etc would be enlightening. There are order of magnitude more engineers working at optimizing chromium than WPF.
Anyway, did you know that chromium is the GUI framework that allow you to have the smallest Binary size? Instead of bundling it like you would with most GUI frameworks (GTK, QT) you can just use the locally installed chrome instance through Carlo.
I do wish people would give the language that has (relative to this ^ trend) 'already arrived' a chance.
Right now most companies (in the .NET world) just run on C# and no one tries anything new except when it arrives in C# (and even then its a struggle - even though the situation has improved a lot in recent years). A mixed model would also open other scenarios.
The mixed compilation is something that current web tech (using bundlers) has in advance. I can do crazy things and end up with the best (optimized) output using a common denominator.
On the F# track I fully agree - its a wonderful language that more people should try out.
I watched a talk about F# on YouTube recently and the guy said they used F# for domain logic and C# for plumbing code and he showed them working together...
> While early adopters may accept some problems on the way (like immature tooling), the majority expects a definite productivity improvement without disrupting the way they work (evolution instead of revolution).
Tooling in F# was/is bad for ages, and also lags in other areas. You have to put up with some disruption to your normal workflow to really embrace it.
The thing I always hated most about the .NET ecosystem was having to run on Windows Server, so that's definitely a welcome change with .NET Core.
But C# has always been a wonderful language to work with. And you never really feel the static typing slow you down, yet get all the benefits of not having to write a bunch of useless tests that replace what a compiler should do in the first place.
(Not trying to make this a dynamic/static flame war by the way. I'm a full-time elixir developer nowadays, so I'm still in dynamic-land and enjoy it. Just not dogmatic about any of it)
ps. my personal favourite programming languae at the moment is by far Julia and I encourage anybody to have a peek at it - I've missed it somehow[1] [2]; followed by crystal
[1] https://youtu.be/DRKKAFYM9yo [2] https://youtu.be/HAEgGFqbVkA
There's a parallel world out there where the Gnome project and Linux distributions rallied around C# as a strong way to write applications, instead of the weird backlash/demonization they all soon received that ended such a brief "golden age".
.NET Core is an absolute pleasure to work with, and while I'm not into Razor views, the web startup modularity and extensability of the pipeline make swapping out solutions a breeze. I can run a full React app in some a wwwroot folder that has almost 0 dependencies on the outer C# code, such that I can plug out the folder and copy it into a new directory and run it like any other React application - that was mind-numbing with ASP non-Core. I love it
[1]: https://stackoverflow.com/questions/39684974/docker-for-wind...
These 2 requirements make this fundamentally unusable for most.
- Windows 10 64-bit: Pro, Enterprise, or Education (Build 15063 or later). - Hyper-V and Containers Windows features must be enabled.
Part of me misses .NET, but I've been mostly working with Golang and Node lately. Visual Studio Code is pretty stellar. Maybe someday VS will catch up to VSC. :)
Never had perf issues with VSC, which is surprising considering it's web tech. It's a different class of app to VS but much nicer to use, and of course it's cross platform.
To their credit, I've had great experiences with RubyMine, but that was the exception to the rule for my experiences with Jetbrains IDEs.
Edit: Before anyone else downvotes, I'll point out that I realize this is not the experience others have had, but I was not exaggerating these claims.
> Basically a single assembly has to be written in the same language.
This is like saying a single js file has to come from only js files, still bundlers today merge all kinds of types in there - in a single sweep.
I am not writing this since I think mixing C#/F# is the future (well, it would be cool), but because it could allow the C# ecosystem to improve. Right now the best thing we have for metaprogramming in C# is Fody; and I personally think we could do better.
Hopefully this expressed my idea a little bit better.
Or, you know, use ILMerge, which is pretty much the equivalent of the JS bundlers you mention. With some custom MSBuild targets you should be able to create a project file that contains C# and F# files, both of them compile to intermediate assemblies (although you can't have circular dependencies between both), and a step afterwards merges the assemblies into the actual one.
`<OutputType>module</OutputType>` in your project file (or `/target:module` at the command line, and you get a smaller unit.
This is actually untrue - though the tooling does not make it easy.
If the output type of a 'project' is set to `module` instead of `assembly`, it can be added as a module reference to another project which builds an assembly.
The downside used to be that completion in the IDE didn't work, but as far as I'm aware there's no real reason why multi-module assemblies couldn't easily be exposed by tooling if it was considered important enough.