-2

Why is the code below using a string_1 instead of straight using FileName? And when would compiler generate code? What kind of source code or configuration of compiler (or anything else) would cause the [compiler generated] attribute?

[CompilerGenerated]
        private string string_1;

        public string FileName
        {
            [CompilerGenerated]
            get
            {
                return string_1;
            }
            [CompilerGenerated]
            private set
            {
                string_1 = value;
            }
        }
Alexei Levenkov
  • 98,904
  • 14
  • 127
  • 179
li yixiao
  • 59
  • 4
  • 4
    Where in your project are you seeing this? – Dai Nov 17 '22 at 04:03
  • It is impossible to figure out when such code will be generated (or even if this particular code was really generated rather than written by hand), but main part "why property code is written that way" is well explained in what I think is reasonable duplicate - https://stackoverflow.com/questions/367192/why-does-property-set-throw-stackoverflow-exception. – Alexei Levenkov Nov 17 '22 at 06:01
  • I've updated title to match answerable part of the question - please see if it aligns with what you wanted to know. For the rest of the questions you likely need to ask separately with significantly more details about origins of the code you are asking. – Alexei Levenkov Nov 17 '22 at 06:03
  • I'm wondering if this is something generated by Roslyn compile-time codegen: that would explain why the field's name is a valid C# identifier (whereas `k__BackingField` is not). – Dai Nov 17 '22 at 06:04
  • @AlexeiLevenkov How on earth is this question a dupe of [this](https://stackoverflow.com/q/367192/159145)? – Dai Nov 17 '22 at 06:25
  • @Dai because it explains why compiler did not generate `string FileName { get { return FileName;} }` which I think is what OP is asking ("Why is the code below using a string_1 instead of straight using FileName?")... Indeed they could be asking about something else, but there is not enoug information to guess other questions. – Alexei Levenkov Nov 17 '22 at 06:41

1 Answers1

0

When you decompile auto properties of C# classes, you simply see this kind of pattern. The actual name string_1 is chosen by the decompilation engine, and different engines choose different ways to pick up such names.

You can read this article to learn more about decompilation of different C# syntax elements.

Update:

As the comments under this answer illustrated, there are several important spots in this code snippet that reveal more information than themselves,

  • The name string_1 is a common indicator of decompilation result from an obfuscated assembly through de-obfuscation process. Obfuscation removes the original *__BackingField names, and de-obfuscation adds back such type name_index names.
  • The missing DebuggerBrowsableAttribute attribute is usually the result of obfuscation (as de-obfuscation usually don't add such back).

Luckily the obfuscation process didn't remove the whole auto property pattern, so you can still tell what it might look like originally.

Note that most obfuscation tools can remove properties and leave behind only fields and methods.

Lex Li
  • 60,503
  • 9
  • 116
  • 147
  • 3
    I don't think this is the case: the C# compiler has always had a consistent naming-scheme for properties' backing-fields: `TypeName.k__BackingField` - so in the OP's case this would be `TypeName.k__BackingField` and not `string_1` - also it adds `DebuggerBrowsableAttribute` which isn't in the OP's code. – Dai Nov 17 '22 at 04:38
  • @Dai you don't know the code came from, so don't assume it came directly from a C# compiler (while there are so many C# compilers). Decompilation often is performed on obfuscated assemblies, so this code snippet can naturally come from de-obfuscated source code, where obfuscation tool removes all valid names generated by C# compiler (so no more `BackingField`) and de-obfuscation tool generates names based on their data types and indexes. BTW, `DebuggerBrowsableAttribute` is often dropped by obfuscation. – Lex Li Nov 17 '22 at 05:23
  • 1
    _"you don't know the code came from"_ - I never claimed it came from anywhere - but conversely the OP never said they were using a decompiler either, but your answer assumes that they are... – Dai Nov 17 '22 at 05:28
  • As one of the obfuscation tool vendors, I think I have enough experience to make that assumption, while your claim of "the C# compiler has always had a consistent naming-scheme for properties' backing-fields" is irrelevant at all. The missing `DebuggerBrowsableAttribute` can also be well explained. So unless you can think something better than mine, there isn't much to discuss further. – Lex Li Nov 17 '22 at 08:11