Support proxies of classes with init properties

[gliljas]

Using "init" properties in mapped classes works really well, e.g by using the BackingField access strategy.

However, when creating proxies of these classes, it currently fails with

System.TypeLoadException : Signature of the body and declaration in a method implementation do not match.

This is because the proxy generator thinks that the init "setter" is proxiable, which of course it isn't.

The implementation adds an IsExternalInit class, which is needed when supporting <NET5.

[hazzik]

maca88/AsyncGenerator#168

[hazzik]

@gliljas I think this fix is not entirely correct. For this entity the following proxy will be generated:

[Serializable]
public class ClassWithInitProperties
{
	public virtual int Id { get; init; }
	public virtual string Name { get; init; }
}

[Serializable]
public class ClassWithInitPropertiesStaticProxy : ClassWithInitProperties
{
	// this is incorrect code because 
	// error CS8080: Auto-implemented properties must override all accessors of the overridden property.
	public override int Id { get; }
	public override string Name { get; } 
}

While overriding init properties does not make any sense because it is not possible to instantiate the proxy with new, the code above is still incorrect.

I think the more correct solution would be to copy modreq for overriden members

[hazzik]

@fredericDelaporte this is a bug, actually.

[hazzik]

Also, if we decide to go ahead with 5.3.15 I would like the fix to be included there.

[gliljas]

@hazzik

While your version is quite possibly better, I'm not sure I agree with your assessment. The proxy doesn't get any auto-implemented properties, and isn't affected by CS8080.

[hazzik]

@gliljas yeah, you are correct and I need to sleep more:)

[hazzik]

Ok. Maybe we can treat TypeLoadException on init properties as a bug and your implementation to skip proxy generation for init properties as an improvement. I'm not fussed as long as init properties will be fixed.

[gliljas]

Should I force push?

Maybe add an exception to AsyncGenerator.yml?

[hazzik]

Maybe add an exception to AsyncGenerator.yml?

Would it work?

Should I force push?

I think it is better to do as a separate PR with test cases specific to the improvement (eg check that method is not overriden). This way it would be easier to backport changes to 5.3.x should we wish it.

[fredericDelaporte]

I have classified it as New Feature because property init setter is a c# 9 new feature and the proxy code generation predates it. Fixing the support of a new feature of a coding language is from my view point adding a new feature.

But I do not mind if you rather see it as a bug fix.

[fredericDelaporte]

Also, if we decide to go ahead with 5.3.15 I would like the fix to be included there.

Why not.

[gliljas]

I'm somewhat at a loss as to what you want me to change, if anything. New PR with the same code? More tests?

[hazzik]

@gliljas if you want to not generate overrides for init properties then submit a new PR with the original code and add more tests checking that overrides to these properties are not generated.

When implementing, please consider this interface as entity:

public interface IPerson
{
    string Name { get; init; }
}

[bahusoid]

Also, if we decide to go ahead with 5.3.15 I would like the fix to be included there.

5.3 branch uses old AsyncGenerator - 0.18.4. So maca88/AsyncGenerator#168 fix needs to be backported to 0.18 version. Or to make things simpler - we can backport this PR without unit test.