Remove csproj.md file (#22277)

Author: gewarren

.openpublishing.redirection.json

@@ -647,6 +647,10 @@
             "redirect_url": "/dotnet/core/testing/unit-testing-with-mstest",
             "redirect_document_id": true
         },
+        {
+            "source_path": "docs/core/tools/csproj.md",
+            "redirect_url": "/dotnet/core/project-sdk/msbuild-props"
+        },
         {
             "source_path": "docs/core/tools/extensibility.md",
             "redirect_url": "/dotnet/core/project-sdk/overview"

docs/architecture/modernize-desktop/example-migration-core.md

@@ -60,7 +60,7 @@ An interesting aspect of this tool is that it only surfaces the differences from
 
 In most of the cases, you'll want to update your existing project to the new .NET Core format. However, you can also create a new project while maintaining the old one. The main drawback from updating the old project is that you lose designer support, which may be important for you. If you want to keep using the designer, you must create a new .NET Core project in parallel with the old one and share assets. If you need to modify UI elements in the designer, you can switch to the old project to do that. And since assets are linked, they'll be updated in the .NET Core project as well.
 
-The [SDK-style project](../../core/project-sdk/msbuild-props.md) for .NET Core is a lot simpler than .NET Framework's project format. And apart from the previously mentioned `PackageReference` entries, you won't need to do much more. The new project format includes certain file extensions [by default](../../core/tools/csproj.md#default-compilation-includes-in-net-core-projects), such as `.cs` and `.xaml` files, without the need to explicitly include them in the project file.
+The [SDK-style project](../../core/project-sdk/msbuild-props.md) for .NET Core is a lot simpler than .NET Framework's project format. Apart from the previously mentioned `PackageReference` entries, you won't need to do much more. The new project format [includes files with certain extensions by default](../../core/project-sdk/overview.md#default-includes-and-excludes), such as `.cs` and `.xaml` files, without the need to explicitly include them in the project file.
 
 #### Assembly.info considerations
 

docs/core/migration/assembly-info.md

@@ -0,0 +1,42 @@
+---
+title: AssemblyInfo properties
+description: Learn about assembly attributes and how they correspond to MSBuild properties in .NET Core 2.1 and later versions.
+ms.topic: reference
+ms.date: 01/08/2021
+---
+# Map AssemblyInfo attributes to properties
+
+[Assembly attributes](../../standard/assembly/set-attributes.md) that were typically present in an *AssemblyInfo* file in .NET Core 2.0 and earlier versions are automatically generated from MSBuild properties, starting in .NET Core 2.1.
+
+## Properties per attribute
+
+As shown in the following table, each attribute has a corresponding property that controls its content and another that disables its generation:
+
+| Attribute                                                      | Property               | Property to disable                             |
+|----------------------------------------------------------------|------------------------|-------------------------------------------------|
+| <xref:System.Reflection.AssemblyCompanyAttribute>              | `Company`              | `GenerateAssemblyCompanyAttribute`              |
+| <xref:System.Reflection.AssemblyConfigurationAttribute>        | `Configuration`        | `GenerateAssemblyConfigurationAttribute`        |
+| <xref:System.Reflection.AssemblyCopyrightAttribute>            | `Copyright`            | `GenerateAssemblyCopyrightAttribute`            |
+| <xref:System.Reflection.AssemblyDescriptionAttribute>          | `Description`          | `GenerateAssemblyDescriptionAttribute`          |
+| <xref:System.Reflection.AssemblyFileVersionAttribute>          | `FileVersion`          | `GenerateAssemblyFileVersionAttribute`          |
+| <xref:System.Reflection.AssemblyInformationalVersionAttribute> | `InformationalVersion` | `GenerateAssemblyInformationalVersionAttribute` |
+| <xref:System.Reflection.AssemblyProductAttribute>              | `Product`              | `GenerateAssemblyProductAttribute`              |
+| <xref:System.Reflection.AssemblyTitleAttribute>                | `AssemblyTitle`        | `GenerateAssemblyTitleAttribute`                |
+| <xref:System.Reflection.AssemblyVersionAttribute>              | `AssemblyVersion`      | `GenerateAssemblyVersionAttribute`              |
+| <xref:System.Resources.NeutralResourcesLanguageAttribute>      | `NeutralLanguage`      | `GenerateNeutralResourcesLanguageAttribute`     |
+
+Notes:
+
+- `AssemblyVersion` and `FileVersion` default to the value of `$(Version)` without the suffix. For example, if `$(Version)` is `1.2.3-beta.4`, then the value would be `1.2.3`.
+- `InformationalVersion` defaults to the value of `$(Version)`.
+- If the `$(SourceRevisionId)` property is present, it's appended to `InformationalVersion`. You can disable this behavior using `IncludeSourceRevisionInInformationalVersion`.
+- `Copyright` and `Description` properties are also used for NuGet metadata.
+- `Configuration`, which defaults to `Debug`, is shared with all MSBuild targets. You can set it via the `--configuration` option of `dotnet` commands, for example, [dotnet pack](../tools/dotnet-pack.md).
+
+## GenerateAssemblyInfo
+
+A Boolean that enables or disables the AssemblyInfo generation. The default value is `true`.
+
+## GeneratedAssemblyInfoFile
+
+The relative or absolute path of the generated assembly info file. Defaults to a file named *[project-name].AssemblyInfo.[cs|vb]* in the `$(IntermediateOutputPath)` (*obj*) directory.

docs/core/migration/index.md

@@ -72,7 +72,7 @@ The .NET Core csproj format has been changing and evolving with each new pre-rel
 - Remove the XML namespace (`xmlns`) from the `<Project>` element.
 - If it doesn't exist, add the `Sdk` attribute to the `<Project>` element and set it to `Microsoft.NET.Sdk` or `Microsoft.NET.Sdk.Web`. This attribute specifies that the project uses the SDK to be used. `Microsoft.NET.Sdk.Web` is used for web apps.
 - Remove the `<Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" />` and `<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />` statements from the top and bottom of the project. These import statements are implied by the SDK, so there is no need for them to be in the project.
-- If you have `Microsoft.NETCore.App` or `NETStandard.Library` `<PackageReference>` items in your project, you should remove them. These package references are [implied by the SDK](../tools/csproj.md).
+- If you have `Microsoft.NETCore.App` or `NETStandard.Library` `<PackageReference>` items in your project, you should remove them. These package references are [implied by the SDK](../project-sdk/overview.md).
 - Remove the `Microsoft.NET.Sdk` `<PackageReference>` element, if it exists. The SDK reference comes through the `Sdk` attribute on the `<Project>` element.
 - Remove the [globs](https://en.wikipedia.org/wiki/Glob_(programming)) that are [implied by the SDK](../project-sdk/overview.md#default-includes-and-excludes). Leaving these globs in your project will cause an error on build because compile items will be duplicated.
 

docs/core/porting/index.md

@@ -47,7 +47,7 @@ We recommend you use the following process when porting your project to .NET Cor
 
 1. Convert your project file to the new SDK-style files structure. You can create new projects for .NET Core and copy over source files, or attempt to convert your existing project file with a tool.
 
-   .NET Core uses a simplified (and different) [project file format](../tools/csproj.md) than .NET Framework. You'll need to convert your project files into this format to continue. This project style allows you to also target .NET Framework, which at this point you'll still want to target.
+   .NET Core uses a simplified (and different) [project file format](../project-sdk/overview.md) than .NET Framework. You'll need to convert your project files into this format to continue. This project style allows you to also target .NET Framework, which at this point you'll still want to target.
 
    You can attempt to port smaller solutions or individual projects in one operation to the .NET Core project file format with the [dotnet try-convert](https://github.com/dotnet/try-convert) tool. `dotnet try-convert` is not guaranteed to work for all your projects, and it may cause subtle changes in behavior that you depended on. Use it as a _starting point_ that automates the basic things that can be automated. It isn't a guaranteed solution to migrating a project, as there are many differences in the targets used by the SDK style projects compared to the old-style project files.
 

docs/core/porting/libraries.md

@@ -24,8 +24,8 @@ This article describes the formal specification of .NET APIs that are intended t
 [Developing Libraries with Cross Platform Tools](../tutorials/libraries.md)\
 This article explains how to write libraries using the .NET Core CLI.
 
-[Additions to the *csproj* format for .NET Core](../tools/csproj.md)\
-This article outlines the changes that were added to the project file as part of the move to *csproj* and MSBuild.
+[.NET project SDKs](../project-sdk/overview.md)\
+This article describes the SDK-style project file format.
 
 [Porting to .NET Core - Analyzing your Third-Party Party Dependencies](third-party-deps.md)\
 This article discusses the portability of third-party dependencies and what to do when a NuGet package dependency doesn't run on .NET Core.

docs/core/project-sdk/msbuild-props.md

@@ -500,7 +500,7 @@ The `TieredCompilationQuickJitForLoops` property configures whether the JIT comp
 
 ### AssetTargetFallback
 
-The `AssetTargetFallback` property lets you specify additional compatible framework versions for project references and NuGet packages. For example, if you specify a package dependency using `PackageReference` but that package doesn't contain assets that are compatible with your projects's `TargetFramework`, the `AssetTargetFallback` property comes into play. The compatibility of the referenced package is rechecked using each target framework that's specified in `AssetTargetFallback`.
+The `AssetTargetFallback` property lets you specify additional compatible framework versions for project references and NuGet packages. For example, if you specify a package dependency using `PackageReference` but that package doesn't contain assets that are compatible with your projects's `TargetFramework`, the `AssetTargetFallback` property comes into play. The compatibility of the referenced package is rechecked using each target framework that's specified in `AssetTargetFallback`. This property replaces the deprecated property `PackageTargetFallback`.
 
 You can set the `AssetTargetFallback` property to one or more [target framework versions](../../standard/frameworks.md#supported-target-frameworks).
 
@@ -526,7 +526,7 @@ Set this property to `true` to disable implicit `FrameworkReference` or [Package
 
 The `PackageReference` item defines a reference to a NuGet package.
 
-The `Include` attribute specifies the package ID. The `Version` attribute specifies the version or version range. For information about how to specify a minimum version, maximum version, range, or exact match, see [Version ranges](/nuget/concepts/package-versioning#version-ranges). You can also add the following metadata to a project reference: `IncludeAssets`, `ExcludeAssets`, and `PrivateAssets`.
+The `Include` attribute specifies the package ID. The `Version` attribute specifies the version or version range. For information about how to specify a minimum version, maximum version, range, or exact match, see [Version ranges](/nuget/concepts/package-versioning#version-ranges). You can also add [asset attributes](#asset-attributes) to a package reference.
 
 The project file snippet in the following example references the [System.Runtime](https://www.nuget.org/packages/System.Runtime/) package.
 
@@ -538,6 +538,31 @@ The project file snippet in the following example references the [System.Runtime
 
 For more information, see [Package references in project files](/nuget/consume-packages/package-references-in-project-files).
 
+#### Asset attributes
+
+The `IncludeAssets`, `ExcludeAssets`, and `PrivateAssets` metadata can be added to a package reference.
+
+| Attribute | Description |
+| - | - |
+| `IncludeAssets` | Specifies which assets belonging to the package specified by `<PackageReference>` should be consumed. By default, all package assets are included. |
+| `ExcludeAssets`| Specifies which assets belonging to the package specified by `<PackageReference>` should not be consumed. |
+| `PrivateAssets` | Specifies which assets belonging to the package specified by `<PackageReference>` should be consumed but not flow to the next project. The `Analyzers`, `Build`, and `ContentFiles` assets are private by default when this attribute is not present. |
+
+These attributes can contain one or more of the following items, separated by a semicolon `;` if more than
+one is listed:
+
+- `Compile` – the contents of the *lib* folder are available to compile against.
+- `Runtime` – the contents of the *runtime* folder are distributed.
+- `ContentFiles` – the contents of the *contentfiles* folder are used.
+- `Build` – the props/targets in the *build* folder are used.
+- `Native` – the contents from native assets are copied to the *output* folder for runtime.
+- `Analyzers` – the analyzers are used.
+
+Alternatively, the attribute can contain:
+
+- `None` – none of the assets are used.
+- `All` – all assets are used.
+
 ### ProjectReference
 
 The `ProjectReference` item defines a reference to another project. The referenced project is added as a NuGet package dependency, that is, it's treated the same as a `PackageReference`.

docs/core/project-sdk/overview.md

@@ -77,7 +77,7 @@ If the project has multiple target frameworks, focus the results of the command
 
 `dotnet msbuild -property:TargetFramework=netcoreapp2.0 -preprocess:output.xml`
 
-### Default includes and excludes
+## Default includes and excludes
 
 The default includes and excludes for [`Compile` items](/visualstudio/msbuild/common-msbuild-project-items#compile), [embedded resources](/visualstudio/msbuild/common-msbuild-project-items#embeddedresource), and [`None` items](/visualstudio/msbuild/common-msbuild-project-items#none) are defined in the SDK. Unlike non-SDK .NET Framework projects, you don't need to specify these items in your project file, because the defaults cover most common use cases. This behavior makes the project file smaller and easier to understand and edit by hand, if needed.
 
@@ -92,7 +92,7 @@ The following table shows which elements and which [globs](https://en.wikipedia.
 > [!NOTE]
 > The `./bin` and `./obj` folders, which are represented by the `$(BaseOutputPath)` and `$(BaseIntermediateOutputPath)` MSBuild properties, are excluded from the globs by default. Excludes are represented by the [DefaultItemExcludes property](msbuild-props.md#defaultitemexcludes).
 
-#### Build errors
+### Build errors
 
 If you explicitly define any of these items in your project file, you're likely to get a "NETSDK1022" build error similar to the following:
 
@@ -126,6 +126,31 @@ To resolve the errors, do one of the following:
 
   If you only disable `Compile` globs, Solution Explorer in Visual Studio still shows \*.cs items as part of the project, included as `None` items. To disable the implicit `None` glob, set `EnableDefaultNoneItems` to `false` too.
 
+## Build events
+
+In SDK-style projects, use an MSBuild target named `PreBuild` or `PostBuild` and set the `BeforeTargets` property for `PreBuild` or the `AfterTargets` property for `PostBuild`.
+
+```xml
+<Target Name="PreBuild" BeforeTargets="PreBuildEvent">
+    <Exec Command="&quot;$(ProjectDir)PreBuildEvent.bat&quot; &quot;$(ProjectDir)..\&quot; &quot;$(ProjectDir)&quot; &quot;$(TargetDir)&quot;" />
+</Target>
+
+<Target Name="PostBuild" AfterTargets="PostBuildEvent">
+   <Exec Command="echo Output written to $(TargetDir)" />
+</Target>
+```
+
+> [!NOTE]
+>
+> - You can use any name for the MSBuild targets. However, the Visual Studio IDE recognizes `PreBuild` and `PostBuild` targets, so by using those names, you can edit the commands in the IDE.
+> - The properties `PreBuildEvent` and `PostBuildEvent` are not recommended in SDK-style projects, because macros such as `$(ProjectDir)` aren't resolved. For example, the following code is not supported:
+>
+> ```xml
+> <PropertyGroup>
+>   <PreBuildEvent>"$(ProjectDir)PreBuildEvent.bat" "$(ProjectDir)..\" "$(ProjectDir)" "$(TargetDir)"</PreBuildEvent>
+> </PropertyGroup>
+> ```
+
 ## Customize the build
 
 There are various ways to [customize a build](/visualstudio/msbuild/customize-your-build). You may want to override a property by passing it as an argument to an [msbuild](/visualstudio/msbuild/msbuild-command-line-reference) or [dotnet](../tools/index.md) command. You can also add the property to the project file or to a *Directory.Build.props* file. For a list of useful properties for .NET projects, see [MSBuild reference for .NET SDK projects](msbuild-props.md).
@@ -162,7 +187,7 @@ The following XML is a snippet from a *.csproj* file that instructs the [`dotnet
     </ItemGroup>
   </Target>
   ...
-  
+
 </Project>
 ```