Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Understanding the .NET ecosystem: The evolution of .NET into .NET 7

andrewlock.net

Post reply on HN
Print view View original

151–160 of 357 posts

Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7

#151

Post by emodendroket »

SiVal wrote: post #144
sylens wrote: post #14

Earlier quoted context omitted.

It really is like finding enlightenment after having to figure out which third party package is best for every little thing in Node. Visual Studio is a pretty powerful IDE as well.

Can you install it [edit: the .Net 7/8 platform that sounds interesting, not the IDE] for free on a Linux server and get the same benefits? (This isn't advocacy, it's a literal question about something I don't know.)

I prefer Rider as a C# IDE whether it's Windows or Linux, although the last time I was doing this there were still a handful of things you needed VS for.

Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7

#152

Post by bearzdev »

great_cormorant wrote: post #129

I spent a lot of time as a Java developer and have recently moved into a spot where I'm being asked to work with C#. A few things rub me the wrong way, and I'm wondering if it's just ignorance and / or me being stuck in my old ways. - Unit testing with mocking is kludgy compared to Java and Kotlin (Moq vs Mockito). There's no mocking of concrete implementations for technical reasons, perhaps unless you shell out mone…

There are other libraries than Moq. Nsubstitute, FakeItEasy, etc.

With Moq and most mocking libraries, you generally just need to make a method virtual for mocking concrete classes.

Most mocking libraries use Castle Project's Dynamic Proxy, so they should be able to inject things without the need of interfaces. Interfaces for everything comes from the .net community's obsession with patterns, abstraction, clean architecture, and DDD.

You can use vscode with file based projects. With Rider/Visual Studio you can show hidden folder so long as they are in a folder or subfolder of a project.

Otherwise, you'll need to add a solution folder and items to the solution folder.

Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7

#153

Post by emodendroket »

cyral wrote: post #12

Been using .NET for years now for backend web development after having taken a break from C#. It is such an improvement over the old .NET framework. When I started building my first backend with it, I was surprised how much was included and "just worked". Need to add authentication? Few lines. OAuth? Also built in. Response caching? Yes. ORM? EF Core is pretty good. Need to use env variables to override your JSON con…

I'm definitely a fan of the "batteries included" approach, but I am ambivalent on EF because I feel like it is still a bit too magic and gets abused. Though it's not like it's a big deal to use whatever else you prefer instead (I am a big fan of the inline SQL with Dapper approach).

Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7

#154

Post by andix »

alexjplant wrote: post #136
andix wrote: post #134

Earlier quoted context omitted.

Classic management f**-up. Some products/companies just die, because of bad management that doesn’t react to change. Get a new job ;)

> Get a new job ;) Done :-). > Some products/companies just die, because of bad management that doesn’t react to change Some don't have to because they get paid no matter what.

Sure, but at some point the last sane developer either quits or retires, and then they are completely f*ed.

Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7

#155

Post by Jochim »

lp0_on_fire wrote: post #27

I love the new dotnet ecosystem and use it professionally but am I the only one who thinks two years isn’t long enough for a “long term support” release? Obviously you’ll be able to run older versions of the framework so long as the underlying OS supports it but depending what type of environment you’re in this means you’re likely going to have to update perfectly working applications every two years. Do I think that…

I view frequent upgrades in the same way as LetsEncrypt's short certificate expiry. It encourages you to create a system that you trust to be upgradeable, rather than a beast that sits, untouched for fear it rears it's head in some ugly manner.

Frankly, places that put off updates have always been a bit of a mess from personal experience and I'd rather have smaller more frequent updates that take a day or two every few years than massive irregular ones that aren't feasible to apply.

Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7

#156

Post by starik36 »

NicoJuicy wrote: post #106
starik36 wrote: post #60

Earlier quoted context omitted.

I just ported a pretty large domain specific library from VB with .NET Framework 4.61 to C# with .NET 7. It took me probably 3 to 4 days to do with the assistance of Instant C# converter. There are lots of gotchas here and there and it does require a pretty reasonable understanding of both legacy and new frameworks.

I'm interested in this case! I have a bit app: Razor, MVC, EF, custom nuget packages, reflection, very advanced expressions ( linq) and my IoC is Autofac ( .net 4.7.2). 101 projects in one solution. Have you got any pointers on gotchas? Did a quick attempt ( 1 evening) and got blocked on my nugets+ Autofac.

> 101 projects

Yikes. This is in C# I assume? If in VB, I'd run one project through Instant C# and see how many problems you encounter. There are lots of VBisms that are simply not in C# (like statement for one, xml literals, etc...).

Run the simplest project through the `upgrade-assistant` tool. It'll convert it to .NET Core. I saw the sibling post recommend .NET Standard, but if you don't plan on using anything legacy this is more headache than its worth.

But yeah, I hear you on the nuget dependencies. Some of them were never ported to .NET Standard or Core so you are left trying to recompile them manually yourself.

Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7

#157

Post by bearzdev »

edandersen wrote: post #73

[flagged]

dotnet upgrade assistant or dotnet try-convert can help with that.

- dotnet try-convert: https://github.com/dotnet/try-convert

- dotnet upgrade assistant: https://dotnet.microsoft.com/en-us/platform/upgrade-assistan...

Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7

#158

Post by emodendroket »

mattmanser wrote: post #58
magicalhippo wrote: post #42

Earlier quoted context omitted.

Well that was my point, either you're writing a lot of code yourself ("assembly"), or you use EF ("Python"). We're not used to something like EF, perhaps it would work for us. But debugging generated queries due to performance issues is something we'd like to avoid. For now the decision was made to not use EF.

You can easily echo them to the console or debug window. To be honest you should keep all ORM queries fairly simple if you can. Where clauses fine. Inserts, updates, deletes, ORMs save so much code, and so much pain when you add new properties/remove them. But if a query is more than a few includes or joins you should be handcrafting it with FromSQL() or loading it piecemeal using Load(). And don't even think about u…

What I personally dislike about it is, for the easy stuff, I'm not sure it really saves that much code over a micro-ORM like Dapper, and for the hard stuff, well, everyone's a Linq wizard already so they're tempted to use it, especially if not in the habit of writing much SQL. With today's tools you can even get Intellisense on inlined SQL queries.

Also the lazy-loading and the in-memory provider for tests are both kind of misfeatures.

Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7

#160

Post by SgtBastard »

drdaeman wrote: post #122
cyral wrote: post #12

Been using .NET for years now for backend web development after having taken a break from C#. It is such an improvement over the old .NET framework. When I started building my first backend with it, I was surprised how much was included and "just worked". Need to add authentication? Few lines. OAuth? Also built in. Response caching? Yes. ORM? EF Core is pretty good. Need to use env variables to override your JSON con…

> I was surprised how much was included and "just worked". A simple HTTP server? Maybe I'm missing something, but when I needed it I hadn't found one. I believe, the closest it has is System.Net.HttpListener which is a very different thing from your typical Golang's net/http.Server or python's http.server.HTTPServer. I believe at some point they had switched from HTTP.sys to Kestrel, so at least it doesn't need the a…

… how often are you hand-parsing HTTP requests and hand-crafting HTTP responses one character at a time?

Productive devs want the request/response wrapper objects and routing constructs to handler methods to get work done and can still drop down into fine-grained request/response crafting as and when required.

Post reply on HN