-
-
Notifications
You must be signed in to change notification settings - Fork 3.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Low priority: Unwanted compiler-internal generated types in output #1784
Comments
See #829: This is C# 7.3 Custom |
I'm not sure if I explained the core issue. |
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:
|
Would you be able to provide us with an assembly and reproduction steps? (preferably open a new issue) thanks! |
@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 22c9801 (Nov 6, 2021).
|
src
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
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.The text was updated successfully, but these errors were encountered: