This is a performance optimization: we dramatically reduce the amount of ILVariables created;
and thus need to spend less time in the first ILInlining run.
DecodeArrayInitializer - Instead of relying on the Add method of a list to expand the underlying array when necessary, the code now allocates a big enough array to fit all the elements removing the need for the Add method to expand the array several times.
BlockFromInitializer now reuses a single instance of List<ILInstruction> instead of reallocating a new one every time and clears it when necessary. The same pre-allocation approach mentioned above has been implemented here too.
- Never introduce casts for ldobj-address-chains
- Add special-case to TransformExpressionTrees: transform addressof(ldloc) to ldloca
- Classify foreach and using variables as readonly lvalues
With the built-in support for long paths in .NET 6.0, we no longer need to check for the registry key. The only limitation that remains is maxSegmentLength, which seems to be 255 on all commonly used file systems/all platforms. Also there is no need to differentiate between Windows and other platforms.
- Windows Explorer in Windows 10 seems to be fine with files generated by ILSpy that have names longer than 260 characters.
- Notepad++ and other applications seem to use 8.3 path syntax to access the file.
- Visual Studio 2022 does not like the long path names, affected users should raise an issue with MS. ILSpy generates proper paths.
When C++/CLI project produce assembly it generates target attribute like this
```
[assembly: TargetFramework(".NETCoreApp,Version=7.0", FrameworkDisplayName = "")]
```
when C# generates `TargetFrameworkAttribute` it produce slightly different format
```
[assembly: TargetFramework(".NETCoreApp,Version=v7.0", FrameworkDisplayName = "")]
```
This fails in culture-invariant mode (ilspycmd) when trying to work with satellite assemblies, because System.Reflection.AssemblyName tries to retrieve CultureInfo of the assembly culture.