FieldBuilder.SetValue for static init-only fields in .NET Core 3.0+

[n9]

The documentation says:

dotnet-api-docs/xml/System.Reflection.Emit/FieldBuilder.xml

Line 941 in eb7cd6e

> This method is currently not supported. As a workaround, retrieve the <xref:System.Reflection.FieldInfo> by reflecting on the finished type and call <xref:System.Reflection.FieldInfo.SetValue%2A> to set the value of the field.

For static init-only fields, this workaround was working in .NET Framework, however this is no longer supported in .NET Core 3.0+ (see dotnet/runtime#11571 (comment)).

So, how to initialize static init-only field of dynamic type in .NET Core 3.0+?
It would be great if the documentation will provide this hint:)

[mairaw]

@jkotas can you help with this feedback? Would this be a breaking change between Framework and Core? /cc @gewarren

[jkotas]

I have submitted #3869 with the doc update.

So, how to initialize static init-only field of dynamic type in .NET Core 3.0+?

The best way to initialize static init-only fields is by code in static constructor. This applies equally to both dynamic and non-dynamic types.

[n9]

@jkotas There is a use case of passing references to static initonly fields described here https://stackoverflow.com/q/60061066/121968 (see comments to this question). What is an "official" recommended solution for this particular use case in .NET Core 3.0+?

[jkotas]

Option 1: Remove FieldAttributes.InitOnly from the type field attributes. This is the easiest.
Option 2: Add static constructor to the type (ie call typeBuilder.DefineDefaultConstructor(MethodAttributes.Static)) and emit code to initialize the static field into this static constructor.

[gewarren]

Besides #3869, we also need to update the FieldBuilder.SetValue recommendation. I'll change "fixes" to "contributes to" in #3869.

[gewarren]

It's a breaking change between .NET Framework and .NET Core, but it's also a breaking change between .NET Core versions. So, I don't think it belongs in the .NET Framework -> .NET Core breaking changes article, but rather the 2.2-3.0 and 2.2-3.1 articles. Thoughts on this more generally? @PriyaPurkayastha

[PriyaPurkayastha]

Yes, on reading through #3869, this is a breaking change introduced in .NET Core 3.0, so 2.x to 3.x articles will feature this. It is a bit tricky - breaking changes introduced in .NET Core in any release would typically be between .NET Framework and .NET Core as well but I am not sure how we manage the documentation. Currently, .NET Framework to .NET Core article is primarily for WPF/Winforms introduced in 3.0 and any breaking changes introduced prior to .NET Core 2.x that have been observed by customers and are being retroactively documented on a case-by-case basis.