The New Way of Calling Your Code in .NET 8 Is INSANE 

This is probably a crime in +50 countries.

I'm guessing this is part of getting rid of reflection for AOT...

Finally, I can change the value of a static private read only field of a class in some other person’s code so that when another person use my library they will learn to read through all code before actually believing something is read only and private.

For this feature I must say "With greater power comes greater responsibility". Excellent demonstration. Thank you Nick.

"The value is Nick" - You are the value mate appreciate your work

Great video, but I think one additional way of doing it should have been in the benchmark. That is, getting the MethodInfo object through reflection, then build a Func (or similar) delegate of it and then cache that delegate and call that instead of using the dynamic Invoke() method each time. Many years ago I changed that in lots of places in a code base that had a lot of reflection and improved performance a lot. The question now is how that compares to this new way of doing it!

Who would win: ten years of SOLID principles vs one unsafe boi?

With great power comes great responsibility. Don't use your power to change static readonly fields :D

I had a very good use case for this recently. We use private constructors for some of our objects because we want to tightly control how new things are made. But that inadvertently effected serialization. System.Text.Json cannot serialize with private constructors. Newtonsoft can. Thats an example of when something is private. but you may still need to access it externally in some situations. I dont want to open up something thats private in the code base but i still want to be able to serialize/deserialize it properly.

This seems really handy for unit testing, but I have concerns about using it in other contexts. As someone who writes a lot of infrastructure code, I find it crucial to restrict developers from accessing certain parts of the code.

Compile time performance is the best part of this ❤

"It's a pain ... where you don't want to be painful" is hilarious. I'm gonna steal that. Regarding the main topic ... I've used reflection to access private members before, but only when it was an abstraction designed to handle cases where you don't know the member names at design-time. This new feature doesn't help with that, so it's just ignoring the original developer's intentions. I suppose if you absolutely need to do it, having it be declarative with "Unsafe" in the keyword is better than hiding it behind reflection. Also much faster, of course, as you observed.

Will we get a dedicated in-depth video about the volatile keyword at some point? It's been 2 years already since you covered it briefly the last time.

This is fantastic! I think it will allow for me to make more things private, and still have them testable. I’ve had so many cases where I couldn’t make something private because I needed to expose to my testing framework.

My experience with code using refection is it is either doing something really powerful and useful or something stupid. It is usually always the second one.

I'm wondering if this is safer, for example if the method doesn't exist or the signature is incompatible would this fail at compile-time? Because in that case this seems like a massive win, especially for those who are committing these types of sins on code they don't have access to.

Personally, I think a valid use case is when you are using a nuget package that doesn't expose the functionality or configuration required for functioning properly in your app.

The first place I will use it is to grab the array under List

I’m so mixed on this I can definitely see value from a unit testing perspective because there are codebases that have private methods that really have too much going to be private. Which really just needed to be rewritten. I strongly dislike accessing things that should be private purposefully but I also love the performance boost

My mind was blown once, when my colleague showed me how to make a self-updating const in JavaScript. Now you're showing me that private properties can be changed from outside classes 🤯 I need to sit down

I love nothing more than ways to break guarantees in a runtime (but readonly fields were modifiable before using... ways). Anyway I feel your performance benchmark is missing the case when you call the method via a delegate, as that is the "proper" way of binding to it (as opposed as Invoke having to perform argument unboxing and whatnot before getting to the method). Perhaps throw a function pointer into the mix as well.

This is gonna be used in source generators so much, and I'm 99% sure that was the main reason the feature got introduced to the runtime. In pre .NET 8, to extend a class with source generator you have to make the class partial, and then have the generator create the extension in the class' partial. With this feature we will be able to extend non partial classes, just as if they were, without bloating said class with the generated methods, you might NOT need outside of what the generated code was for. This is an amazing, though very dangerous, thing indeed.

If all the reflection based methods on the BLC gets to use this feature under the hood, then most reflection code can be AOT compatible

5:50 Yes, I want to easily access private members that I shouldn't be using, and, oh, 11:00 so much for readonly, ... this will be fun (especially if it is performant, lol). I wish the Law worked like this: "Yes, Officer, I broke this law, but I said a special word when I was doing the bad act, so that makes it ok and it's all good."

Did you know that if you cache an open instance delegate instead of the MethodInfo you can get the same performance with "reflection" (actually with a delegate) that you see with the UnsafeAccessor? All you have to do is call CreateDelegate with a type argument that accepts the target type as a parameter, in this case Func. var testInstance = new Example(); var openDelegate = typeof(Example) .GetMethod("Method", System.Reflection.BindingFlags.Instance | System.Reflection.BindingFlags.NonPublic) .CreateDelegate(null); var name = openDelegate(testInstance);

Surprisingly often I find myself needing to call a method that isn't in the public API of a library. It's usually a method that should be public, but the creator of the library thought otherwise or just accidentally wrote the wrong keyword. Using this will be a lot easier than using reflection, so I consider it a bonus. Plus, I imagine it works with AOT too (since it links at compile time) to make reflection-like things possible for anyone using AOT.

.NET developers before: C++ is unsafe, so we invented delegates in C# .NET developers now: Now we can call functions in unsafe manner as C++ Great job!🤣🤣🤣

Maybe it's just for use in highly optimized libraries

Regarding the code mess of the reflection solution, I had an extension method for the reflection calls in a project. Worked for any property of any class.

Nick's on a mission to one up each .Net 8 video with something having even more terrifying possibilities.

I saw Zoran Horvat do something like this for field mapping with Entity Framework. It being private makes it clear that it's not part of the model API was his reasoning.

This can help to fit or fix problems in 3rd party components when you have access to the source code, but you don't want to build your own version just to change that one read only value to activate tls or something like that.

This will be really useful for mocking libraries and testing 😊

Thank you for this, Nick. Concise and helpful as always. I can see the use - as you demonstrated - clean and fast running, if potentially dangerous code.

I got ill just by hearing your voice, get well soon Nick

This is gonna result in some fun code bases to maintain in 3-5 years from now... (I do see a case for debugging, learning and fiddling around with stuff, but never for production code)

This looks like one of those features where you may only need it once a year. But you'll *really* need it.

4:17 “It doesn’t take a genius to understand that having to write something like this *every single time* is very very tedious” You make it sound like this is the first thing we do every morning before standup.

This is an amazing feature, only a shame that you haven't included a benchmark for a compiled lambda as well.

I think this is a good approach to access private things if there is no other way. But I'm glad we have code reviews and hope tampering with private things never gets through...

Nice! it is something that I probably only use in my unit tests!

Have had to access internal methods from external APIs previously, this would have made that experience easier. Looks a lot like calling external APIs in the.net 3.5 days, so its at least consistent with how interop code was written to get access to hardware drivers etc.

Sometimes you gotta do what you gotta do

Could be useful for certain testing situations as well.

WoW this is God-sent. I've been writing a state-machine/workflow library kind of thing, and the fastest I managed to access properties etc was with compiled expressions, which still was a lot slower than direct access. Too bad it does not support Generics yet... it would simplify many things

I've read various comments that essentially say that this kind of mechanism defeats the purpose of access modifiers so I hope my explanation is going to help and clarify some of that confusion or misconception, as strange as it might sound to some people access modifiers were never designed as a permission system but as an encapsulation mechanism to control the visibility of different parts of the system not to prevent it, this concept exists in programming mainly for maintainability and usability, e.g., the engine of a car is hidden within the engine compartment whereas the hood is restricted. Point is this mechanism of .NET 8 to access members (and soon types) changes nothing people that wanted/needed to access your code before could always do it through reflection or more hacky alternatives depends on the language/platform so if people are using access modifiers to restrict developers from code that is actually sensitive data then they are using the wrong tool for the job.

How does this interact with string.Empty? I remember reading that it used to be changeable but they fixed that. Does this reintroduce the possibility of changing it? It's a static readonly after all

Probably going to be eons before Unity updates to .NET 8 (if its even around then given their current dramas), but when it does, this will really change editor scripting for the better. So many useful methods and classes are needlessly internal or private, resulting in tons of required (cached) reflection or even IL emission to do anything even remotely advanced.

I see a use case. I used that use case many times. I have a method that I need to unit test. I also do not want developpers to directly use that method so I make it private or protected. This allows to do that without complicated code. Another Use Case: I have created an abstract class that keeps track of field changes. This is done with backing field not visible to the end class. This allows me to access these hidden fields without permitting a developper to use it directly.

This isn't the worst thing you can do in C#; most of a dev's job is finding that balance between terribleness and efficiency. Always nice to have more tools in the kit

1 year from now nick will go like "now Im become death, the destroyer of clean codes"

Is this a good use case for private members that are made public for no other reason but to make unit testing easier?

I wouldnt use this for private, but the performance boost, often we use reflection on a "object" where we knnow that object has a property/method, that doesnt have a common interface to expose it, that this could then be used to call that public property/method to get/set that value.

This is awesome! I had some cases in the past, where i had to use reflection to get a private value out - and it was very slow. Great that there is now a tool for doing the same thing - and more, for compile time performance. I like it ;-) Thanks for sharing.

Kinda OK with having this. Just yesterday I had to use some internal setters for tests involving types of the blobstorage lib. But allowing this to break promises like static readonly seems to me *absolutely bonkers*. Really.

It's really helpful feature in some rare cases. Thanks for the sharing.

Thanks I will use it in all my code now

I kinda prefer C++ approach to this, defining friend classes that can just access the private implementation.

Very interesting but something I would need a very good reason to use.

I dunno, since I've never seen a case where I had to actually do this and not be okay with lower performance maybe my opinion is irrelevant. But, making it easier and more powerful is like removing the safety from a gun because it's quicker to shoot.

I dig it. I think this makes a lot of sense for them to iterate and improve all aspects of the ecosystem, instead of just neglecting the unsightly parts.

Seems useful for unit testing your private methods.

Can this be done with extensions as well?

I see it very usefull for testing in some scenarios.

if you are not supposed to use something - it makes sense to make it more difficult to do. but to make it easier is an invitation to use. is this reasonable ?

Sometimes you need to access private stuff for whatever reason. Thanks for sharing.

Nick: *extern* you probably haven't seen this keyword before. Me, who interops C/C++ to C# for a living: Yeah Nick, I wish. I really wish.

In "powerful" you mean "I've done mistakes in the design so I have to break encapsulation, but I want some syntactic sugar on it so my boss will think I'm doing a good job" You'd be better shooting your own foot.

Thinking ahead to use cases I might encounter, I'd probably add an "Unsafe" suffix to all my "Caller" method names just to add a reminder to any users about what's potentially happening behind the code

I would say it opens more ways of unit testing, and especially performance testing (since it no longer has to be slower than public calls) of your own projects. Generally I also really like the better philosophy that in the end a compiler should not actually limit you to do things, but can give you full control if you really demand so. In the end it's up to YOU as a developer to make good coding decisions. A compiler should not be needlessly childish, but help you by making make guidelines clear. By disabling private access with the normal way of calling, the message is already clear, you should normally not want to do it, since it defeats purpose.

every time he said "the name is" I filled "Primogean" in my head. Please help

Oh man, once you said the word "extern," I knew I was in for a wild ride. But then I was like, "alright, well, good thing I try to make stuff read-only whenever I can," but then you edited the static read-only field. Well, RIP to that idea. This was all pretty crazy, but that put it over the top.

I have an actual use case for this that I'm dealing with right now, but unfortunately its on Net Framework, so this wouldn't really apply. Its on an old MS library for OIDC support on OWIN, so its a good use case in the sense that the code is very mature and very unlikely to change, and also the implementation is not extension-friendly (its all private/internal, not protected and/or virtual). So, I guess I'm stuck with the reflection code (or copying their implementation verbatim from github).

As a developer and an engineering manager, I can say that as helpful as this maybe it wreaks of code smell!

Love the captioning of your opening line at 0:00 "hello everybody I'm naked in this video.." 😇

this is what you need for writing unit test when you don't want to expose everything as public

With great power comes great responsibility! 🕷

Thanks for introducing this new feature. I am wondering what is the motivation behind it. If authors of classes want people to have access to protected/private methods/fields, would they have not marked the functions or fields public instead?

Ooof.. I sense a major rewrite in my future. How is the compatibility with older .NET7 or 4.8, can you multitarget to those and compile or do you have to #if NET8_0_OR_GREATER and write the reflection version anyway?

This is Assembly Publicizer which has been available for a long time in modding community

I think it can help write more robust and cleaner code when you have to use reflection anyway (assuming type safety is enforced for the extern methods of the caller class). However I would be warry of accessing, let alone setting (especially if read only), private members. I guess there might be edge cases I'm not thinking about that justify it, but unless it's for the purpose of diagnostic it feels antithetical to encapsulation and the safety it provides and looks like looking for trouble to me.

The automatic youtube captioning is hilarious: "Hello everybody, I'm naked in this video ... "

This breaks encapsulation. What use cases does this have?

Nice, another footgun! It's almost C++ now :D

11:55 Yeah, but you can do it with unsafe (in fact, something very much more unsafer than to change a readonly field, but to change the string contents itself) Reflection was not able to do it before? I have an impression that it could

Great power comes with great responsibility, hope devs don't start doing stupid things with this feature

I wonder if it can be used with generic methods/interfaces as well? It's always pain when some libraries only expose generic methods, so you have to live without polimorthism and specify concrete generic interfaces, or create some non-generic decorators with lots of delegate generation / caching / casting. For example: Kafka producers in MassTransit

Unlimited POWER!!

The only thing I can think of, where it makes sense to access private members would be in tests. Microsoft has/had an way for this in their own test framework using a class I think called PrivateObject.

So first they added multi-inheritance, and now they removed encapsulation... Great, just great. Can we just rebrand to JavaScript# and be done with it? This won't simplify bad code - this IS a bad code.

0:00 "Hello everybody, I'm naked in this video" - RU-vid Captions, 2023

Could you give examples of when we MIGHT need to access a private method ?

I actually think that UnsafeAccessor is safer than the previous example using reflection. Using the attribute; the class name, method name and kind needs to be known at compile time. Using reflection you can traverse and call unknown code, which I think is way more unsafe.

Wonderful insights, thanks!

The fact that this is promoted as an improvement just shows that Microsoft is not understanding what other languages and editors are doing with meta programming and treesitter. While C# has things like "nameof" that might help avoid the use magic strings, they release this feature that further propagates their use. Don Syme understood this with Type Providers. Ultimately, C# is becoming such an utter mess it's disappointing.

I see a problem with this, the fact that we can access unused private methods, while it is technically being used. It still says the private method is not used and it is safe to remove. Doing an auto cleanup or removing some unused code can be dangerous now no? Thoughts?

I would have preferred an Attribute to this. Though it is still a step in the right direction. Roslyn has/had something similar with the [assembly: IgnoresAccessChecksTo("assemblyName")] Attribute. Wonder if the boilerplate can be source-genned away or some notification can be shown if the member you're trying to target no longer exists.

I am totally opposed to the thinking that "too much power" or "is too unsafe" in a language. C# suffered from this thinking for a very long time until recent years when they begin adding some more powerful features and better management over arbitrary memory. A "safe" language should have all the guardrails in place, but completely removing the ability for the programmer to explicitly bypass them can be frustrating where there is something non-standard that needs done. Building and emitting IL at runtime was previously the next best thing to do other than just using a different language, so I am glad to see MS putting some more power and trust in programmers.

That is awesome! But how does it work underneath? How do UnsafeAccessor attribute know what type I am using? And what happens if I have two instances of the same class, but with different values? And what happens if there is multiple functions with the same name?

This is a great tool in combination with source generators