List constructs EF uses that require non-public code access

[ajcvickers]

Put together a list of everything we do that operates on non-public code when we would not normally have permission to do so.

[ajcvickers]

Code that compiles expression trees:

• RelationalPropertyExtensions.GetReaderFieldValue
  • Reads a value from a DbDataReader
  • Does not need non-public access
• SqlServerGeometryTypeMapping.CreateSqlDbTypeAccessor
• SqlServerGeometryTypeMapping.CreateSqlDbTypeAccessor
• SqlServerUdtTypeMapping.CreateUdtTypeNameAccessor
  • Sets the SqlDbType or UdtTypeName of a parameter
  • Does not need non-public access
  • Not clear to me why this is a compiled delegate? Maybe to avoid hard reference to SqlParameter?
• SnapshotFactoryFactory
  • Reads values from entity properties or fields
  • Needs non-publc access
• DbContextFactorySource
• DbContextPool.CreateActivator
  • Calls constructor for DbContext type with single parameter for DbContextOptions<TContext>
  • Does not need non-public access; only calls public constructors
• ClrCollectionAccessorFactory
  • Creates instances of HashSet, List, etc. or of a custome ICollection type
  • Does not need non-public access; collection must have public, parameterless constuctor
• ClrPropertyGetterFactory
  • Reads value of property or field
  • Needs non-publc access
• ClrPropertySetterFactory
  • Sets valuye of property or field
  • Needs non-publc access
• DependencyInjectionMethodParameterBinding
• ServiceParameterBinding
  • Gets a value from a service provider
  • Does not need non-public access direcyly, but value may be assigned to private field by materializer
• EntityMaterializerSource
  • Creates entity instances
  • Writes property and field values
  • Calls entity constructors, including parameterized constructors
  • Integrates and compiles arbitary expressions from user code
  • Needs non-publc access
• ValueComparer
  • Compares values of two objects
  • May call non-public methods, such as typed Equals
  • User can supply arbitary expression that may need non-public access
  • Read values of fields or properties
• RelationalSqlTranslatingExpressionVisitor.GetConstantOrNotTranslated
  • Also other similar code in other providers
  • Evaluates an arbitary expression
  • May need non-public access depending on what is in the arbitary expression
• ValueConverter
  • Converts a value from one type to a value of (usually) another type
  • User can supply arbitary expression that may need non-public access

[ajcvickers]

Based on the code above, we need to be able to:

• Read and write from properties and fields with any visibility
  • Highest priority
• Call constructors, both parameterless and with parameters with any visibility
  • Medium priority--needed for relatively common scenarios, but can be worked around with application code changes
• Call methods with any visibility
  • Low priority--not used in common scenarios
• These operations may be done on both reference and value types, which themselves may have any visibility
• Fields may be compiler-generated and so not have valid C# identifiers
• Fields may be marked as readonly

Beyond this, applications and database providers can inject their own expressions in various places, and these may contain arbitrary code. However, I believe we can limit this code to the cases above and throw (or use Reflection) if injected code does anything else.

[AndriySvyryd]

As for the shape of the API we'd prefer to be able to use just the name string and declaring type to access properties and fields instead of PropertyInfo/FieldInfo

[roji]

Fields may be compiler-generated and so not have valid C# identifiers

As discussed offline, let's ask for a way to access backing fields of auto-properties. This isn't critical: we can use the regular API for accessing private fields, passing it the compiler-generated name (as today). But it would be good to remove knowledge of compiled-generated names from EF.

The two API options for this would be:

1. A dedicated API returning the name of the backing field, given a property. The slight disadvantage for us would be to embed the compiler-generated name obtained from this API in our generated C# code.
2. APIs accepting the property and directly reading/writing its backing field (assuming its an auto-property). The consumer would have to know they're accessing an auto-property (via another API? Or this API would be some sort of TryReadXXX, returning false for non-auto-properties?). This would also require us to generate different access code for auto-properties and other things.

So option 1 seems to be the preferred way for us, in any case.

[ajcvickers]

See dotnet/runtime#81741