Access private members without reflection (For source generators)

[lskyum]

Many reflection based tasks can be replaced by source generators, which can provide performance enhancements and also have other benefits for AOT runtimes and code trimming. For example I'm using a source generator to generate custom serialization...

But a missing feature is being able to access private and protected members, which is currently only possible with reflection.
This means that a generated serializer isn't able to instantiate a private class or call a private constructor.
The attribute InternalsVisibleTo can be used to some extend, but it only works for "internal" members and not private/protected.

So I propose an attribute called [AllowAllAccess] that can be applied to a class or a method, which then allowed them to use anything without restrictions. This should not be a security problem, because access is possible with reflection anyway, but the resulting code is much cleaner and not as likely to break because of changes to the code it's calling.

The proposed attribute will be beneficial for source generators, but also for testing, where InternalsVisibleTo is commonly used.
(And thereby forcing members to be internal instead of private.)

Illustration of the usecase:

public class MyOuterClass
{
	[GenerateSerializerPlease]
	private class MyNestedClass
	{
	
	}

	void Foo()
	{
		// Use the class and serializer internally in MyOuterClass
		MySerializer.SerializeAnything(new MyNestedClass());
	}
}

// Source generated class
public static class MySerializer
{
	public static byte[] SerializeAnything(object value)
	{
		if(value is MyOuterClass.MyNestedClass)	// <-- can't access private here
		{
			// ...
		}
	}
}

[HaloFour]

So I propose an attribute called [AllowAllAccess] that can be applied to a class or a method

If you're going to explicitly mark the member as allowing all access why would you make it private to begin with? Just make everything public.

[svick]

@HaloFour

If you're going to explicitly mark the member as allowing all access why would you make it private to begin with? Just make everything public.

As I understand it, this request says that the accessing code should be marked with the attribute, not the accessed code.

[lskyum]

@svick Yes, exactly! The accessing code should be marked to allow access.

[HaloFour]

You must be aware of how often reflection is used for exactly that purpose... so making a "compilation safe" solution for such use-cases doesn't make sense?

IMO, no. I think that approach should be discouraged by the language. I make it a point to avoid serializers or other framework code that relies on reflection of private state.

As I understand it, this request says that the accessing code should be marked with the attribute, not the accessed code.

I see, that does make more sense. But that's also tantamount to allowing anyone to disable private accessibility by sticking an attribute on their class/method.

[lskyum]

I can partly agree about private state, but the issue is also with "public members of private nested classes", because the generated source can't serialize, auto-map, INotifyPropertyChanged, log or whatever it's purpose, because it can't access it at all...

[CyrusNajmabadi]

How would you do INPC here if you were writing it by hand?

[svick]

Note that this is already possible today using IgnoresAccessChecksToGenerator. Though doing this is unsupported and I haven't tried to use it from a source generator.

Making this approach official was rejected in the past (see dotnet/roslyn#20870). I don't know if source generators changed things.

[lskyum]

Thanks for finding this... I was unable to find anything that remotely did this.
I hope it will be reconsidered now we have source generators, because it will make many reflection based use cases possible with source generators.

[CyrusNajmabadi]

I believe the last time we discussed this, we felt it was a very bad/smelly thing. I don't see this as having really changed in the interim. If you need access to privates, you should go through reflection, because you're bypassing the language. I don't see why SGs change that. Indeed, the purpose of them is not compile time reflection. It's to silly make it easier to write the code you could already do by hand, but which would a burden.

If we don't give you the ability to bypass this, I'm not sure why we'd want to give another party this access.

[lskyum]

Using reflection (or IL Emitting or Expression.Compile) is a problem for AOT and code trimming (like Blazor AOT) so anything that can be done with source generators instead will potentially fix that. That's the main reason I'm advocating this feature...

[lskyum]

I'm happy to see that this is now possible in .NET 8 with the UnsafeAccessor attribute. Guess I'm not the only one that found this useful ;-)