- 
                Notifications
    You must be signed in to change notification settings 
- Fork 6.1k
Csharp 73 autoproperty field attributes #5157
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
Csharp 73 autoproperty field attributes #5157
Conversation
So much inline code...
Also, run acrolinx and update where needed.
| closing and re-opening to force a new build | 
One will require a samples PR
These are needed for the build to pass in dotnet/docs#5157
| PR dotnet/samples#39 fixes the build errors, and related snippet include alignment (some snippets display the wrong code.) | 
| Since the samples have merged, closing and reopening to begin new build. | 
| @rpetrusha I think it will still fail. A few of the errors were in the snippet files. I opened dotnet/samples#39 to fix those. Once you review those changes, then this one should build. | 
| @BillWagner, sorry, in reviewing your source code PR I didn't notice that MultiUseAttribute.cs has an opening <Snippet1> tag but a closing <Snippet2> tag. Because of that, the build is continuing to fail even though the samples have been merged. | 
These are needed for the build to pass in dotnet/docs#5157
| Closing and reopening to resume build after code examples were merged. | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've left a number of small nits and grammatical corrections, @BillWagner, along with some suggestions for further revision that are really unrelated to your PR but would help improve the overall topic. You might not want to address them now and instead open an issue to address them later.
|  | ||
| ## See Also | ||
|  | ||
| Determines how a custom attribute class can be used. <xref:System.AttributeUsageAttribute> is an attribute you apply to custom attribute definitions. It controls how the new attribute can be applied. The default settings look like the following example when applied explicitly: | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"It controls how the new attribute can be applied." is a rather vague sentence, and it's only a bit later that it becomes clear what this means. I think that I'd some variation of this sentence with a bulleted list of what it controls -- the program element to which the attribute can be applied, whether the same attribute can be applied multiple times, and inheritance.
|  | ||
| [!code-csharp[Define a new attribute](../../../../../samples/snippets/csharp/attributes/NewAttribute.cs#1)] | ||
|  | ||
| In this example, the `NewAttribute` class can be applied to any attribute-able code entity. But it can be applied only once to each entity. The attribute is inherited by derived classes when applied to a base class. | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not quite sure about attribute-able, and I'm not sure anyone will know what it means. I think I would phrase this as "supported code element" or "supported program element" and perhaps provide a list.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I put the list of supported program elements above. That seemed more clear.
|  | ||
| ## Using attributes | ||
|  | ||
| Attributes can be placed on most any declaration, though a specific attribute might restrict the types of declarations on which it is valid. In C#, you specify an attribute by placing the name of the attribute, enclosed in square brackets ([]), above the declaration of the entity to which it applies. | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the commas around "enclosed in square brackets..." aren't necessary
| int Method3() { return 0; } | ||
| ``` | ||
|  | ||
| > By convention, all attribute names end with the word "Attribute" to distinguish them from other items in the .NET Framework. However, you do not need to specify the attribute suffix when using attributes in code. For example, `[DllImport]` is equivalent to `[DllImportAttribute]`, but `DllImportAttribute` is the attribute's actual name in the .NET Framework. | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
perhaps in the .NET Framework -> in the .NET Framework Class Library, or "of the .NET Framework type"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we rephrase it, then Framework might be omitted at all?
| [DllImport("user32.dll", ExactSpelling=false, SetLastError=false)] | ||
| ``` | ||
|  | ||
| The first parameter, the DLL name, is positional and always comes first; the others are named. In this case, both named parameters default to false, so they can be omitted. Refer to the individual attribute's documentation for information on default parameter values. | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In terms of "Refer to...", the problem is that you have to know that the positional parameters correspond to an attribute constructor, and named/optional parameters to either properties or fields. That should probably be specified here.
| > [!IMPORTANT] | ||
| > This example creates a new file if the file does not already exist. If an application must create a file, that application must `Create` permission for the folder. Permissions are set by using access control lists. If the file already exists, the application needs only `Write` permission, a lesser permission. Where possible, it is more secure to create the file during deployment, and only grant `Read` permissions to a single file (instead of Create permissions for a folder). Also, it is more secure to write data to user folders than to the root folder or the Program Files folder. | ||
| > This example creates a new file if the file does not already exist. If an application must create a file, that application must have `Create` permission for the folder. Permissions are set by using access control lists. If the file already exists, the application needs only `Write` permission, a lesser permission. Where possible, it's more secure to create the file during deployment, and only grant `Read` permissions to a single file (instead of Create permissions for a folder). Also, it's more secure to write data to user folders than to the root folder or the Program Files folder. | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no comma between "deployment" and "and only grant"
|  | ||
| [!code-csharp[Disable serialization for an auto-implemented property](../../../../../samples/csharp/serialization/Loan.cs#4)] | ||
|  | ||
| The next step is to add the serialization code to the LoanApp application. In order to serialize the class and write it to a file, you use the <xref:System.IO> and <xref:System.Runtime.Serialization.Formatters.Binary> namespaces. To avoid typing the fully qualified names, you can add references to the necessary class libraries as shown in the following code: | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the references aren't to the necessary class libraries, but to namespaces.
|  | ||
| ### Attaching attributes to auto-implemented properties | ||
|  | ||
| Beginning with C# 7.3, field attributes can be attached to the compiler | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
compiler generate --> compiler-generated
|  | ||
| For more information, see: | ||
|  | ||
| - [Creating Custom Attributes (C#)](creating-custom-attributes.md) | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is the tutorial on attributes. I think it's worth to be mentioned in this list.
By the way, should this tutorial be updated as well for the scope of this PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added that link. When I read that tutorial, I didn't see where it should reference the new field: syntax for auto implemented properties.
These are needed for the build to pass in dotnet/docs#5157
Fixes #3962
Update articles where attaching attributes to the backing field of an auto-implemented property should be mentioned.
Also, update the Serialization walkthrough to remove the Windows Forms dependency, and make it run on .NET Core.
Dependent on dotnet/samples#38 (Build will fail until that is merged.)