The best Nuget package you’ve never heard of

Hello everybody I'm Nick and in this video I will introduce you to a Nuget which is used in tons of places and has more than 350 MILLION downloads but you don't know about. It has some really practical usecases and we will take a look at them in this video.

Don't forget to comment, like and subscribe :)

Social Media:

#csharp #dotnet #nuget

[rade]

Congratulations on becoming full time content creator. You deserve the best.

[somarzein]

"Full time content creator". Too bad for hungry companies, too good for us developers :D. Thanks!

[winstonstrongarm]

Love this series, it's like unboxing videos for coding

[boskovicboris]

I love this guy's enthusiasm. When I get stuck on a boring task, I come here for some inspiration. :D

[queenstownswords]

Congrats Nick. Your videos have always been high quality, a great learning tool, and a go-to reference. Between you, Tim Cory, and James Montemagno, I think you guys have C# covered.

[ronsijm]

Also if you're testing, there's "Autofac.Extras.DynamicProxy" - which easily allows you to intercept anything, and then basically set up things, or detect things that you wouldn't detect otherwise. For example, for my APIs I have an interceptor "Exceptions must be documented" - the interceptor will make sure that if an exception leaves a controller, that controller has a swagger attribute of `[ProducesResponseType(typeof(InvalidDataException), 401)]` so that API consumers know what to expect

[Rein______]

I hope nuget packages like this are not bait for beginners so they make their codebase way to complicated. Add a few of these 'cool magic packages' together in the wrong hands and you have the maintenance nightmare of the future... A good enough design that is as simple as possible beats overengineering anytime. For me that means only use the minimum amount of packages, and only if it has a clear responsibility so it can be swapped out if that project dies or something...

[OllyWood]

Since nobody else will do it I'll tip my hat at the suggestive thumbnail you absolute chad.

The performance pit in this scenario wouldn't be the call to the intercepted methods, but the building of the proxy... there is where all the "reflection magic" occurs .. in a containerized application wouldn't be that important since you only do this once at app startup, but it can be a big hit in performance for serverless functions for example, where every time your function does a cold start, all the reflection is done again... but yet, Castle.Core is a great library for some things if used carefully.

[dcuccia]

Great tutorial - had no idea AOP was this easy. Thanks for covering "But, Nick. Performance." How about "But, Nick. AOT compilation scenarios (no System.Reflection.Emit)."?

[GrimReaper]

Congratulation Nick. You deserve it, your content is some of the best detailed guides that you can find on the internet. On wards and upwards my friend :) lets get to 150k by end of year.

[SchmataB]

congrats! and yes, I never heard of this nuget although I use Moq on daily basis so thanks a lot for bringing this up.

[sofusskovgaard]

Thank you for the introduction, i will definitely be using this in the near future

[antonmartyniuk]

I have used this library for creating a RPC type of communication in production. It's a great tool

[brianp]

Congratulations Nick. It is well deserved, your expertise is the best.

[pawenowak]

Congratulations!:) And an idea about one of next videos: Your Blazor up-to-date impressons :)

[dnl_blkv]

In a full decorator implementation, you'd just create a DecoratorBase with all the methods set virtual and calling the decorated instance by default, and then in concrete decorators you'd only override the methods you need to override :)

Interceptors can still be massively useful in various cases, it is just that decorator is solvable in a nice manner without them %)

[sinyor.]

Nice tricks, Nick. And congrats for becoming full time content creator, can't wait for another useful tutorial :)

[seangwright]

Congrats on being able to do content creation and education full time. You're great at it!

Re: Type-based decoration in C# doesn't scale...

If you need to move away from SRP, then yes, you're going to have a lot of methods/properties to implement on each decorating type and maybe a class hierarchy might be a better option. But I try to avoid reaching for Castle or any other reflection based interception approach because it's so easy for the code to become really difficult to debug and understand. I haven't run into any situations in the projects I work on (other folks use-cases could be completely different) where I need AOP via Castle and Type-based decoration doesn't work.

That said, the Castle project is really important to the .NET ecosystem and I use it every day (just not directly) for things like mocks in unit tests...

[tea_otomo]

Imho these kind of videos are so important. A lot of new C# devs have no idea of all the possibilities, just because they have no idea about NuGet.