Why property does not use the same name for backing field in this compiler generated code?

Question

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;
            }
        }

Answer 1

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.