[tabtab]

Re: I would say the learning curve is pretty high

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?

[mieseratte]

Having just come into a .NET shop in the last couple months, having spent much time with Spring / Java the documentation and clarity of what to use is troublesome. I really expected Microsoft to have great documentation, but sadly I’ve not found it great.

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.

[blyat]

If you want a more batteries-included less-glue-requiring IoC container, can't recommend Autofac enough. Always up-to-date, responsive developers, thorough documentation. I chose it over ten years ago after reading https://www.manning.com/books/dependency-injection-in-dot-ne...? and have never looked back.

[keithnz]

its very simple to get .net core DI working, shouldn't be much code other than registering your types / service.

await new HostBuilder().ConfigureServices((context, services) => { // services.AddTransient.... }).UseConsoleLifetime().Build.RunAsync()

[mieseratte]

I’m talking DI for ASP.NET MVC 5, non-Core.

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?

[avgDev]

That is because MVC 5 did not support DI out of the box. This has been fixed with Core. It is quite easy now, since I was able to figure it out haha.

[jsingleton]

It depends where your starting point is. Core bundles a lot of stuff together that was previously separate or just good practice. If you are familiar with MVC / WebAPI / EF / OWIN and already doing DI / Logging etc. then it's not much of a leap.

[avgDev]

This is correct. I did not use DI before moving to Core and that was probably the toughest. Once learned, DI is great.

MVC 5 to Core should be a pretty easy transition if you know DI.

[nikon]

I feel "DI" in the context of .NET Core is often the IoC container you feel forced to use. DI is a pattern, but even trying to use the logger extension without the service provider is a pain.

[james_s_tayler]

Rough spot for me is the way Startup.cs works. I mean, I'm glad it works at all, but I find the UX a bit nasty compared to how to configure SpringBoot applications.

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.

[alfromspace]

I went from developing front-end only with the MEAN stack, to full-stack with Webforms, to MVC...and I was easily more confused with the transition to MVC than anything else. Even being accustomed to EF now, I still would bet money that I could write data access code twice as quickly with half as many issues. I fail to see what's so much better about working with an object than understanding SQL and your data. Everyone claims MVC is a more natural, transparent web development paradigm, which I sort of agree with, but anyone who hasn't written APIs or worked with EF before will find themselves trading a lot of productivity for it.