Where did Java interop go?
Educated guess: shifted with net6.0-android. That is the core driver. Same as swift integration with net6.0-ios.
.NET 5.0
401–410 of 466 posts
Re: .NET 5.0
#402Would most people here agree that .NET is a much better platform for developing applications with a plugin-based architecture (which, I think, more or less, implies following Hexagonal aka Clean Architecture / Ports and Adapters Pattern [1]) than popular alternatives (e.g., Python, TypeScript/Node.js) due to a diverse set of comprehensive dependency injection (DI) implementations [2]? While it is possible to use a ma…
I think Python, TS/JS and other popular languages do not block onion architectures / hexagonal architecture. Or most other patterns. It is a matter of will and the right execution.
Also, DI is not the same DI containers. If I have three components and inject two into another one, I do DI but for sure will not instantiating a DI container for it ;)
Re: .NET 5.0
#403Earlier quoted context omitted.
I think they should have done what every other framework does and make it super easy to access, like this: Env.Config("Settings:MyEasyValue"); Or: Env.Config ().MySuperEasyTypedValue; And the Dependency Injection? Sure, add some version you can DI with. But not the default. I now know how to navigate the mess they've made, but it's not time that I feel where I gained anything in my life, it was just frustrating. Here…
The sheer length of the answer? That's because it shows optional, more advanced ways to get config stuff. Is this so hard? public class AccountController : Controller { private readonly IConfiguration _config; public AccountController(IConfiguration config) { _config = config; } public IActionResult ResetPassword(int userId, string code) { var vm = new ResetPasswordViewModel { PasswordRequiredLength = _config.GetValu…
Is this supposed to be ironic? Or just unintentionally?
"What's hard about [mass of code] compared to [one liner]?"
Re: .NET 5.0
#404I know .NET Core applications could run on Linux. But do they natively (without any wrappers) support Linux OR is there a wrapper to simulate windows within Linux?
It would never achieve its performance if it would wrap something. .NET on Linux is as native on Linux as is Java, Python or Go. Also priority in Microsoft has completely changed. Most .NET runs on Linux nowadays (dockerized or not).
It actually does the opposite: it is able to expose memory-alike resources (from e.g. the network interfaces) deep into its consuming programs by using abstractions like Span. And while that sounds like a wrapper, it is actually (depending on the "alike") just a typed and safe pointer.
Re: .NET 5.0
#405Earlier quoted context omitted.
I think they should have done what every other framework does and make it super easy to access, like this: Env.Config("Settings:MyEasyValue"); Or: Env.Config ().MySuperEasyTypedValue; And the Dependency Injection? Sure, add some version you can DI with. But not the default. I now know how to navigate the mess they've made, but it's not time that I feel where I gained anything in my life, it was just frustrating. Here…
They have that? You can call Configuration manually if you prefer that way. I feel like everyone in this thread is working overtime to justify complaining when there are multiple options to do what you want.
I was thinking about this last night, that's actually not at all true.
A 'new' C# programmer doesn't. You have to be advanced enough at C# to know you can do that (i.e. not a junior or outsider)
It's also not clear how the config works at first glance or the implications of using a POCO on the app lifecycle.
An experienced coder will have to ask themselves questions like, if I store the IOptions object, will it automatically update? If I assign the POCO in startup, will it be a single object, or does startup get called for every new request? Or maybe it will get called for every thread? Or maybe if there are no requests for 10 minutes it automatically shuts down?
Re: .NET 5.0
#406Earlier quoted context omitted.
The DI in .NET is really powerful and feels intuitive once you play around with it in a few different projects. We have almost 100 services injected into .NET Core DI and it always feels very stable and manageable. For us, we cheated a little bit on many services and just take a dependency on IServiceProvider to get at other services at runtime. This allows for any service to talk to any other service without worryin…
Thank you very much for sharing your DI experience. What is wrong with using IServiceProvider dependency? What is CTOR (hierarchy)?
CTOR hierarchy in this case refers to a rigid structure in which you are not allowed to have any circular dependencies. E.g.: If UserService and AccountService eventually evolve into needing to talk to each other, you can wind up in this situation. Most would argue you should refactor both services, create a 3rd service or slam the 2 together into 1. I argue that both have independent persistence layers and it makes a lot of sense from a business perspective to have these modeled separately.
So, the implication is that IServiceProvider is a way to "cheat" the system by not requiring you perform an impossible circular CTOR setup where UserService requires AccountService and vice versa. DI cannot resolve dependencies which require each other. In terms of actual harms, I do not really think there are any substantial ones to note. This is technically reflection but only slightly and I haven't been able to notice any performance impact, but we don't do IServiceProvider lookups in tight loops either.
Re: .NET 5.0
#407Maybe in a year or eighteen months, I'll be able to move to this, from Framework code that still has dependencies that nobody has ever updated to .NET Core. This version will be nearly out of support by then...
When your code depend on stuff not migrated yet, it will no longer happen. From a .NET Framework position, .NET 5 is a huge breaking change by loosing capabilities and using different base libraries (which will not be recovered later). From a .NET Core 3.1 perspective, it is a minor update.
.NET 5 reality is: They ported 90% of their app models (e.g. wpf, winforms, ...) and dropped some other (e.g. WCF, WWF, AppDomains, ...). That is not going to change.
.NET ecoysystem reality is: What is not ported until now, will not be ported. .NET Core is now 6 years old (2014?) and everything new is currently .NET Core. Someone who wants to stay in business, has ported already 2-3 years ago.
Re: .NET 5.0
#408Since Apple is announcing the new Macs with M1 SoC today, I'm wondering if it will support it from day 1 or we will have to wait?! edit: I guess I can't read. `We expect that Apple will announce new Apple Silicon-based Mac computers any day now. We already have early builds of .NET 6.0 for Apple Silicon and have been working with Apple engineers to help optimize .NET for that platform. We’ve also had some early commu…
I think this will be a patch release soonish. ARM is well supported already and the toolchain on macOS is also present already.
And they need it to support the development of .NET 6.
Re: .NET 5.0
#409Maybe in a year or eighteen months, I'll be able to move to this, from Framework code that still has dependencies that nobody has ever updated to .NET Core. This version will be nearly out of support by then...
When your code depend on stuff not migrated yet, it will no longer happen. From a .NET Framework position, .NET 5 is a huge breaking change by loosing capabilities and using different base libraries (which will not be recovered later). From a .NET Core 3.1 perspective, it is a minor update. .NET 5 reality is: They ported 90% of their app models (e.g. wpf, winforms, ...) and dropped some other (e.g. WCF, WWF, AppDomai…
Well, I've still got to support integrations with other Microsoft products that are in support for the next decade, and only have Fx SDKs.
Tooling in Visual Studio has sucked out loud for most of the Core stuff thus far. There's not a lot of value chasing the churn versus letting it settle out.
Re: .NET 5.0
#410Earlier quoted context omitted.
I think they should have done what every other framework does and make it super easy to access, like this: Env.Config("Settings:MyEasyValue"); Or: Env.Config ().MySuperEasyTypedValue; And the Dependency Injection? Sure, add some version you can DI with. But not the default. I now know how to navigate the mess they've made, but it's not time that I feel where I gained anything in my life, it was just frustrating. Here…
The sheer length of the answer? That's because it shows optional, more advanced ways to get config stuff. Is this so hard? public class AccountController : Controller { private readonly IConfiguration _config; public AccountController(IConfiguration config) { _config = config; } public IActionResult ResetPassword(int userId, string code) { var vm = new ResetPasswordViewModel { PasswordRequiredLength = _config.GetValu…
Makes perfect sense to me, even as a mostly-Python developer with very limited experience in .NET/C# or other ecosystems.