.Net core is fantastic. What a surprise to find a software from Microsoft that worked a LOT smoother on Linux than on Windows* :D
* VSCode/Linux vs VSCode/Windows. Full VS on Windows worked OK.
.NET Core 3.0 Concludes the .NET Framework API Porting Project
101–110 of 317 posts
Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project
#102Earlier quoted context omitted.
Are you making interfaces for everything? Just register and use the class with constructor injection. All those layers of indirection just waste time. What would change with functions outside of classes? You already have anonymous functions/lambdas, static classes and extension methods if it's about instantiation overhead, and local (nested) functions. Can you explain a scenario where this doesn't work for you? For n…
It would seem to me that you wouldn't be able to mock all the classes if you followed this strategy.
You can mock classes with virtual methods/properties.
I prefer making interfaces instead, though. I find it useful to make the boundaries between components explicit.
Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project
#103Earlier quoted context omitted.
JetBrains stuff does feel sluggish and occasionally hangs on my 2016 XPS-13 with 8G of ram. It gets the job done, but it's not pleasant. On my new Ryzen 3600 with 32G of ram it runs smooth. So if you go for JetBrains, I definitely advise not to cheap out on the hardware. Rider on Linux was very good for me, working on C# azure functions.
32G?!? Where does one find such employers??? Not to mention how crazy it sounds having 32GB for an IDE. Visual Studio, Netbeans and Eclipse run perfectly fine with 8 GB.
It depends on your use-case.
Add Docker, VM, development database server etc. to the bill, and a 32 GB machine is pretty reasonable for a dev.
Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project
#104I've tried to port a MVC project to .NETCore 2 a while ago, it was pretty painful mainly due to lack of @helper syntax in views (everything which relied to @helper had to be changed). Also, from what i saw, nobody is actually in a rush to "move" to .NETCore, most big shops still rely on .Net Framerwork , i still do some occasional work on a project which is using .Net Remoting :)
There are some similarities to Python 3 in .NET Core adoption. I know plenty of people that would love nothing more than to be up to date and to start using .NET Core, but many of them rely on certain libraries that simply aren't there yet. I know a load of Umbraco devs that are eager to make the jump, but until their CMS supports it, they're kinda stuck if it's a dependency.
Just with the difference, that there is not 2/3 culture split here. Everyone agrees that .NET Core is the future and should be used. The universal cloud adoption (e.g. AWS Lambda), containerization and Linux deployments are so huge selling points for .NET Core.
People are hold back because of deprecated tech and because no one touches a running system without need. And maybe that black matter developers just do not know yet ;).
Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project
#105Given that our deployment platform was Linux (for a .Net Core 3.0 project), I was determined to use Linux and VS Code for development. That was a fail; the verbose nature of C# and the Framework APIs make it impossible to be productive without significant help from a full-fledged IDE like Visual Studio. One might think the verbosity can be reduced by clever coding (and adopting a functional style), but that's not so…
> Allow functions outside of classes Why? You can put them in a static class, and if C# ever had this feature, it would just be syntactic sugar for a hidden static class. But that would mean optimising for "hello world" and other small script scenarios, which isn't a goal of the language design. > Adopt (files and dirs) instead of forcing namespace declarations Likewise. > Structural typing Like "dynamic" in C# 4 ? B…
> But that would mean optimising for "hello world" and other small script scenarios, which isn't a goal of the language design.
Fairly complex programs can be written with just plain functions, all of them elegantly starting off column 0 instead of being tabbed for namespaces and classes. It works especially well with directory structure based namespaces. eg: Microsoft's own TypeScript.
> Like "dynamic" in C# 4 ?
No not dynamic, I wouldn't use that very much either. https://en.wikipedia.org/wiki/Structural_type_system
Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project
#106Earlier quoted context omitted.
Well do you really need to mock everything? And if so, how is that different than any other stack? Most of the time this is just "enterprise patterns" without any thought about whether it's worth it. I've seen too many small LOB apps that have 5 tiers of code for no reason.
I am seeing it all the time when consulting for companies. Their developers just love taking relatively small things and turning it into multilayered monster with insane amount of dependencies for code, development building pipelines and deployment.
I see that too - but I also see plenty of completely un-testable code, because the controller constantly reads from AppSettings, or creates a new database connection directly, or similar issues.
For small applications, instead of going full on DI, I sometimes just make a few simple public static properties, that I initialize on program startup. Then you can initialize them differently in your test harness. This is a lot easier to understand if you're not an expert in the chosen DI framework or app framework.
Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project
#107Earlier quoted context omitted.
> Allow functions outside of classes Why? You can put them in a static class, and if C# ever had this feature, it would just be syntactic sugar for a hidden static class. But that would mean optimising for "hello world" and other small script scenarios, which isn't a goal of the language design. > Adopt (files and dirs) instead of forcing namespace declarations Likewise. > Structural typing Like "dynamic" in C# 4 ? B…
> But that would mean optimising for "hello world" and other small script scenarios, which isn't a goal of the language design. That's what the Powershell integration is for.
> That's what the Powershell integration is for.
And projects such as scriptcs and cake
Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project
#108Given that our deployment platform was Linux (for a .Net Core 3.0 project), I was determined to use Linux and VS Code for development. That was a fail; the verbose nature of C# and the Framework APIs make it impossible to be productive without significant help from a full-fledged IDE like Visual Studio. One might think the verbosity can be reduced by clever coding (and adopting a functional style), but that's not so…
> Allow functions outside of classes Why? You can put them in a static class, and if C# ever had this feature, it would just be syntactic sugar for a hidden static class. But that would mean optimising for "hello world" and other small script scenarios, which isn't a goal of the language design. > Adopt (files and dirs) instead of forcing namespace declarations Likewise. > Structural typing Like "dynamic" in C# 4 ? B…
Structural typing is different from dynamic typing. C# supports structural typing in the form of tuples and anonymous types. But you can't return an anonymous type from a method. This is a significant limitation.
As for "free" functions: C# already recognizes the usefulness of this in the "using static" directive. This is useful for a lot more than "hello world".
Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project
#109.NET Core 3.0 was major achievement for Microsoft and I like the air surrounding the project and some around it like Visual Studio Code and Windows Subsystem for Linux. The teams working for Windows development are overall on a roll these days and it's both sad and a little mysterious how Windows 10 is still struggling with QA issues, decisions like dismantling their internal testing teams, dual control panels and in…
Windows userland is being rewritten in COM since Vista, as the Windows team picked up the Longhorn ideas and used them in COM after winning the WinDev vs DevTools politics, I doubt they will change route. The best we can hope for is that with the new AOT/JIT infrastructure, it gets more equal footing with C++/WinRT in platform APIs. After all, it has won the UI, MFC is legacy and XAML/C++ doesn't have much uptake as…
> After all, it has won the UI
LOL, you are stuck in 2004 my friend, .net is a huge bloated piece of garbage technology stuck trying to catchup with java
They had the balls to show us a simple calculator app written in .net core 3.0 and WPF that was JUST 140mb
Now please, stop trying to make windows even more bloated, and maybe take a look at macOS, and understand why NOBODY WANTS JIT garbage collected shit in UI
Windows became a huge pile of dogshit because people like you promote the WIN32 and now UWP enterprise bloatware
Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project
#110Earlier quoted context omitted.
It would seem to me that you wouldn't be able to mock all the classes if you followed this strategy.
Well do you really need to mock everything? And if so, how is that different than any other stack? Most of the time this is just "enterprise patterns" without any thought about whether it's worth it. I've seen too many small LOB apps that have 5 tiers of code for no reason.
I once "inherited" a project where I counted more than thirty levels between the web pages and the send/receive on a queue to the system that actually did the work.
Funnily enough they had a huge team (and over 30 thousand classes) and a lot of time (over two years) but they couldn't finish it.
Edit: Should have said it was J2EE rather than .Net