ILSpy
ILSpy copied to clipboard
Low priority: Unwanted compiler-internal generated types in output
src
class C {
unsafe static void tst<T>(System.Span<T> s) where T: unmanaged
{ fixed (T* p = &s.GetPinnableReference()) {} }
}
It seems you can't just use the csc compiler to generate a core3.0 library from a single file (at least I didn't find a way), and I was unable to find a standalone exe suggesting it was a compiler. Easiest workaround I found (which is still a mess) was the following
-
dotnet new classlib -f netcoreapp3.0 -n foo
- Copy src to foo\Class1.cs
-
dotnet build -p:AllowUnsafeBlocks=True foo\foo.csproj
That should generate foo\bin\Debug\netcoreapp3.0\foo.dll
.
This displays a few compiler-embedded types ILSpy should become aware of, and probably not include when producing a project:
-
Microsoft.CodeAnalysis.EmbeddedAttribute
-
System.Runtime.CompilerServices.IsUnmanagedAttribute
Since they are (one would hope) carved in stone, typenames can be hard-coded in ILSpy.
I've also come across System.Runtime.CompilerServices.IsReadOnlyAttribute
generated like this, that not only should not be included in the output, its references in decompiled code should also not be included. I've only seen it applied to specific parameters. It could be for to the "ref readonly" construct, but I have been unable to get any tested compiler to accept such a construct so I can't say for certain.
See #829: This is C# 7.3 Custom fixed
statement: Types that implement a suitable GetPinnableReference
can be used in a fixed statement. Currently not supported by the decompiler.
I'm not sure if I explained the core issue. GetPinnable
in the body was just to display one use of it.
The core issue is the : unmanaged
(and the other mentioned) tags making the compiler generate the mentioned attribute classes in the target assembly, classes that should not be included in decompiled output.
https://docs.microsoft.com/en-us/dotnet/api/system.runtime.compilerservices.isreadonlyattribute?view=net-5.0 is certainly something I am also affected by, decompiled classes just have that annotation on some private structs especially, which causes issues when trying to recompile because:
[CS8335] Do not use 'System.Runtime.CompilerServices.IsReadOnlyAttribute'. This is reserved for compiler usage.
https://docs.microsoft.com/en-us/dotnet/api/system.runtime.compilerservices.isreadonlyattribute?view=net-5.0 is certainly something I am also affected by, decompiled classes just have that annotation on some private structs especially, which causes issues when trying to recompile because:
[CS8335] Do not use 'System.Runtime.CompilerServices.IsReadOnlyAttribute'. This is reserved for compiler usage.
Would you be able to provide us with an assembly and reproduction steps? (preferably open a new issue) thanks!
I've also come across System.Runtime.CompilerServices.IsReadOnlyAttribute generated like this, that not only should not be included in the output, its references in decompiled code should also not be included. I've only seen it applied to specific parameters. It could be for to the "ref readonly" construct, but I have been unable to get any tested compiler to accept such a construct so I can't say for certain.
@tamlin-mike are the uses of these attributes still not removed from the decompiled output? The decompiler should already support (ref) readonly structs and "in" parameters.
We'll have to think about adding a transform that removes the declaration of these attributes when producing a project.
Quick test using ILSpy 22c98016 (Nov 6, 2021).
dotnet new classlib -o Tst1
cd Tst1
Place into Class1.cs: public class C1{public void foo<T>(in T t) where T:unmanaged{}}
dotnet build
ilspy bin\Debug\net5.0\Tst1.dll
decompiles C1 properly, but saving to project still includes
Microsoft\CodeAnalysis\EmbeddedAttribute.cs
System\Runtime\CompilerServices\IsUnmanagedAttribute.cs