Project System: Remove the cruft from project files and templates

From @davkean on May 11, 2016 1:35

Want to go from something like:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="15.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" />
  <PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
    <ProjectGuid>0a5fdbad-1d09-4833-a0b4-cf17a684fb2e</ProjectGuid>
    <OutputType>Library</OutputType>
    <AppDesignerFolder>Properties</AppDesignerFolder>
    <RootNamespace>ClassLibrary1</RootNamespace>
    <AssemblyName>ClassLibrary1</AssemblyName>
    <TargetFrameworkVersion>v4.5.2</TargetFrameworkVersion>
    <FileAlignment>512</FileAlignment>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
    <DebugSymbols>true</DebugSymbols>
    <DebugType>full</DebugType>
    <Optimize>false</Optimize>
    <OutputPath>bin\Debug\</OutputPath>
    <DefineConstants>DEBUG;TRACE</DefineConstants>
    <ErrorReport>prompt</ErrorReport>
    <WarningLevel>4</WarningLevel>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
    <DebugType>pdbonly</DebugType>
    <Optimize>true</Optimize>
    <OutputPath>bin\Release\</OutputPath>
    <DefineConstants>TRACE</DefineConstants>
    <ErrorReport>prompt</ErrorReport>
    <WarningLevel>4</WarningLevel>
  </PropertyGroup>
  <ItemGroup>
    <Reference Include="System"/>

    <Reference Include="System.Core"/>
    <Reference Include="System.Xml.Linq"/>
    <Reference Include="System.Data.DataSetExtensions"/>


    <Reference Include="Microsoft.CSharp"/>

    <Reference Include="System.Data"/>

    <Reference Include="System.Net.Http"/>

    <Reference Include="System.Xml"/>
  </ItemGroup>
  <ItemGroup>
    <Compile Include="Class1.cs" />
    <Compile Include="Properties\AssemblyInfo.cs" />
  </ItemGroup>
  <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
  <!-- To modify your build process, add your task inside one of the targets below and uncomment it. 
       Other similar extension points exist, see Microsoft.Common.targets.
  <Target Name="BeforeBuild">
  </Target>
  <Target Name="AfterBuild">
  </Target>
  -->

 </Project>

To something like:

<?xml version="1.0" encoding="utf-8"?>
<Project>

  <PropertyGroup>
    <OutputType>Library</OutputType>
    <RootNamespace>ClassLibrary22</RootNamespace>
    <AssemblyName>ClassLibrary22</AssemblyName>
    <TargetFrameworkVersion>v4.5.2</TargetFrameworkVersion>
  </PropertyGroup>

  <ItemGroup>
    <Reference Include="System"/>
    <Reference Include="System.Core"/>
    <Reference Include="System.Xml.Linq"/>
    <Reference Include="System.Net.Http"/>
    <Reference Include="System.Xml"/>
  </ItemGroup>

  <ItemGroup>
    <Compile Include="**\*.cs" />
  </ItemGroup>

  <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />

</Project>

Copied from original issue: dotnet/roslyn#11235

[NickCraver]

What is the scope of changes here? It seems like MSBuild is getting some changes…or I am misunderstanding what’s required on the consumption side of the new format? Can someone clarify what (if anything) is happening to MSBuild itself to consume this new format? @davkean?

The references I see in this thread are:

Just to set expectations, this issue isn’t tracking making sweeping changes to MSBuild

and

If you’re looking for us to move away Items, Properties, Targets and Tasks, and ultimately from XML - this issue is not the one to track that.

…does that mean there are zero changes, or are there some minor changes required for MSBuild to work correctly with the current proposed format? If that set of changes is non-zero and consuming this new format requires updates to MSBuild anyway, what’s the impact of a more modest proposal of simply aliasing ItemGroup or PropertyGroup with more intuitive names if we can come up with such? You could have simple aliases, e.g. <References>, <Files>, etc. (I’m sure people can make better names than me), all of which make the format far more approachable, intuitive, and hand editable. Of course maybe there’s a blocker there I’m unaware of that makes the suggestion moot.

I would imagine that if we’re doing a set of changes that require an updated MSBuild release to consume and breaking compatibility, it’s extremely unlikely for that to happen again (as it should be) and we need to pair any changes that require an updated MSBuild together in this one upgrade pain point. If we have to pay the cost of deploying a new MSBuild anyway, why not fix the issues we keep coming back to with these extremely unintuitive elements?

If I’m an idiot and the current proposal requires exactly zero changes to MSBuild itself…nevermind then. Not requiring an updated build tools deployment is, IMO, a marginally bigger win overall.

[davkean]

Okay folks, I’m ready to mark this as completed. For the new SDK-based templates, we’ve got them down to simply the following by default, starting in the next public release of Visual Studio:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netcoreapp1.0</TargetFramework>
  </PropertyGroup>

</Project>

This includes enough information to:

1. Pick up the right NuGet package for framework bits, or default set of framework assemblies if targeting .NET Framework

2. Pick up all the source files, content files, and resources inside the “project cone” (ie everything under the project directory recursively)

3. Pulls in the default set of tasks and targets that lets you build and publish

4. Setup a set of defaults for namespace, assembly name, output path, etc

These project types will be created by default when targeting .NET Core and .NET Standard projects (console, web and library). We’ll be enabling this types of projects for .NET Framework, and other project types in a future release of Visual Studio past VS 2017.

If you would like to see more changes, or you find issues in the current changes, I’ll ask that you create a new unique bug to for us to track the work.