Skip to content
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

Project System: Remove the cruft from project files and templates #40

Closed
davkean opened this issue May 13, 2016 · 107 comments
Closed

Project System: Remove the cruft from project files and templates #40

davkean opened this issue May 13, 2016 · 107 comments
Labels
Feature Request Request for a new feature, or new scenario to be handled. Feature-Project-File-Simplification Related to cleaning up and simplification of the project format. Needs-CPS-work Changes are needed in the closed-source Common Project System (CPS) repo.
Milestone

Comments

@davkean
Copy link
Member

davkean commented May 13, 2016

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

@davkean davkean added Area-Project System Feature Request Request for a new feature, or new scenario to be handled. Needs-CPS-work Changes are needed in the closed-source Common Project System (CPS) repo. labels May 13, 2016
@davkean
Copy link
Member Author

davkean commented May 13, 2016

Or even better, not even need the references - just reference everything by default, similar to what we did in UWP, Portable, etc

@davkean
Copy link
Member Author

davkean commented May 13, 2016

image

@davkean
Copy link
Member Author

davkean commented May 13, 2016

See also dotnet/roslyn#10065

@davkean
Copy link
Member Author

davkean commented May 13, 2016

From @onovotny on May 11, 2016 1:46

Why does the import targets need to be there, can a before targets be auto-included in the build system externally?

@davkean
Copy link
Member Author

davkean commented May 13, 2016

Yep, good question.

@davkean
Copy link
Member Author

davkean commented May 13, 2016

From @onovotny on May 11, 2016 1:50

How about the target framework version? What if I want to cross compile. That has to be a first-class scenario as that was a major benefit to project.json

@davkean
Copy link
Member Author

davkean commented May 13, 2016

From @NickCraver on May 11, 2016 2:7

Cross-compile is a huge use case here too - I think an honest example here has to include that much more complicated scenario.

Also: what about all the package metadata? Another major benefit or project.json was one place for all of this. Either it's included here, or we'll be maintaining 2 files for the information (at a minimum, will we have the project name duplicated?). If we're talking about the first class experience that project.json offered being replicated here (e.g. very nice Intellisense on packages, dependencies, etc.).

Regardless, editing should be in one spot. Not in two spots across 2 file formats, that would be a terrible regression in usability. Everything in XML is better than half in XML and half in JSON.

@davkean
Copy link
Member Author

davkean commented May 13, 2016

Just to set expectations, I quickly wrote this up internally September last year, and only got around to creating an issue on it. It's not factoring in cross-compile or anything from xproj yet. We're still discussing how best to bring those things across.

@davkean
Copy link
Member Author

davkean commented May 13, 2016

From @onovotny on May 11, 2016 2:10

Is the goal to remove project.json as used in csproj today (as a packages.config replacement) or just that one's "big brother" as used in xproj?

@davkean
Copy link
Member Author

davkean commented May 13, 2016

Two schools of thoughts, leave it today with just package refs, or replace it with "MSBuild equivalents" a la <PackageReference Include="FooBar" />, still completely up in the air.

@davkean
Copy link
Member Author

davkean commented May 13, 2016

From @vbfox on May 11, 2016 7:59

Or even better, not even need the references - just reference everything by default.

Both references, and <Compile Include="**\*.cs" /> can have good defaults done by a "simplified" target, if anyone want them back, they can reference the normal target file.

Mixed with package references it might look 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>
    <PackageReference Include="Newtonsoft.Json"/>
  </ItemGroup>
  <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.Simple.targets" />
</Project>

@davkean
Copy link
Member Author

davkean commented May 13, 2016

From @isaacabraham on May 11, 2016 8:4

@davkean This is looking nice. Please can you also keep in mind (if this issue is appropriate for it) the .fsproj story which is very, very similar AFAIK but the main difference is the need to (somehow) specify file ordering / dependencies e.g. file1.fs comes "before" file2.fs in compilation order. @KevinRansom maybe has some thoughts on this.

@davkean
Copy link
Member Author

davkean commented May 13, 2016

@isaacabraham Yep, we've got F# in mind when we start looking at these things, including sitting it on top of the new project system.

@davkean
Copy link
Member Author

davkean commented May 13, 2016

From @opinionmachine on May 11, 2016 9:23

Keep it clean, if you need bizarre special cases, all those elements need to be optional and not present by default, and it doesn't harm anybody if you have to google, with bing, to find them that one time in your career you need them. 99% never do anything weird, all the cruft needs to go. If you insist on this XML way of doing things, despite no tangible upsite and so, so many downsides, at least be inspired by the millions of better solutions that are actually used in the world.

@davkean
Copy link
Member Author

davkean commented May 13, 2016

From @pebezo on May 11, 2016 15:3

Coming from someone who rarely had to edit csproj: consider meaningful names for nodes. ItemGroup it's too abstract (group of what? items?...) "dependencies" like in project.json makes a lot more sense. Same with "PropertyGroup"... properties for what?

Also, aim for single words rather than compound words. If a compound word is the only thing that would fit then it's too abstract.

@davkean
Copy link
Member Author

davkean commented May 13, 2016

Just to set expectations, this issue isn't tracking making sweeping changes to MSBuild itself, the MSBuild format or moving to a new build model. For those, you are better off starting threads over on https://github.com/microsoft/msbuild.

@davkean
Copy link
Member Author

davkean commented May 13, 2016

From @benaadams on May 11, 2016 15:50

Without know too much about what MSBuild allows, would a x-compile for something like Microsoft.AspNetCore.Server.Kestrel/project.json look something like:

<?xml version="1.0" encoding="utf-8"?>
<Project>
  <PropertyGroup>
    <OutputType>Library</OutputType>
    <RootNamespace>Microsoft.AspNetCore.Server.Kestrel</RootNamespace>
    <AssemblyName>Microsoft.AspNetCore.Server.Kestrel</AssemblyName>
  </PropertyGroup>

  <PropertyGroup>
    <TargetFrameworkVersion>v4.5.2</TargetFrameworkVersion>
    <TargetFrameworkVersion>netstandard1.3</TargetFrameworkVersion>
  </PropertyGroup>

  <ItemGroup>
    <Reference Include="System.Buffers" Version="4.0.0-*" />
    <Reference Include="System.Numerics.Vectors" Version="4.1.1-*" />
    <Reference Include="System.Threading.Tasks.Extensions" Version="4.0.0-*" />
    <Reference Include="Libuv" Version="1.9.0-*" />
    <Reference Include="Microsoft.AspNetCore.Hosting" Version="1.0.0-*" />
    <Reference Include="Microsoft.Extensions.Logging.Abstractions" Version="1.0.0-*" />
    <Reference Include="Microsoft.Extensions.PlatformAbstractions" Version="1.0.0-*" />
  </ItemGroup>

  <ItemGroup TargetFrameworkVersion="v4.5.2">
    <Reference Include="System"/>
    <Reference Include="System.Runtime"/>
    <Reference Include="System.Threading.Tasks"/>
  </ItemGroup>

  <ItemGroup TargetFrameworkVersion="netstandard1.3">
    <Reference Include="System.Collections" Version="4.0.11-*" />
    <Reference Include="System.Diagnostics.Debug" Version="4.0.11-*" />
    <Reference Include="System.Globalization" Version="4.0.11-*" />
    <Reference Include="System.IO" Version="4.1.0-*" />
    <Reference Include="System.Linq" Version="4.1.0-*" />
    <Reference Include="System.Net.Primitives" Version="4.0.11-*" />
    <Reference Include="System.Runtime.Extensions" Version="4.1.0-*" />
    <Reference Include="System.Runtime.InteropServices" Version="4.1.0-*" />
    <Reference Include="System.Text.Encoding" Version="4.0.11-*" />
    <Reference Include="System.Threading" Version="4.0.11-*" />
    <Reference Include="System.Threading.Tasks" Version="4.0.11-*" />
    <Reference Include="System.Threading.Thread" Version="4.0.0-*" />
    <Reference Include="System.Threading.ThreadPool" Version="4.0.10-*" />
    <Reference Include="System.Threading.Timer" Version="4.0.1-*" />
  </ItemGroup>

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

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

@davkean
Copy link
Member Author

davkean commented May 13, 2016

From @aelij on May 11, 2016 16:11

If package references are added to the .csproj, we should be able to easily edit the file without VS asking to reload the project. Plus the package IntelliSense from project.json.

@davkean
Copy link
Member Author

davkean commented May 13, 2016

From @benaadams on May 11, 2016 16:14

@aelij shouldn't be beyond the realm of possibility as you can add references via ide without a reload

@davkean
Copy link
Member Author

davkean commented May 13, 2016

From @pbolduc on May 11, 2016 16:28

It would be good if <Reference Include="" /> items were sorted alphabetically by name. This helps to avoid merge conflicts.

@davkean
Copy link
Member Author

davkean commented May 13, 2016

From @blowdart on May 11, 2016 16:49

Not sure about referencing all the things by default, unless you mean everything that's part of that framework version. Even then I'd still want a way to exclude things I don't ever need that are slapped in by default.

@davkean
Copy link
Member Author

davkean commented May 13, 2016

From @MarkPflug on May 11, 2016 17:0

I notice that the xmlns is removed in the proposed "clean" version. Is that really intentional? I know the first (maybe beta) version of MSBuild actually supported this, but if you try it now with MSBuild it is will tell you to add the xmlns back. Otherwise, that is already a valid project file. The only reason all that other cruft is needed is to satisfy Visual Studio project system. Specifically, the <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' "> sections are required so that the VS tooling doesn't lose its mind.

I'm actually delighted that things are going back to MSBuild and the project.json is being abandoned. MSBuild is very powerful and supported so many things that just didn't seem possible (or at least not straight forward) in the .json. Also, not being able to have commented out sections in json drove me nuts.

It would be really nice if Visual Studio would support naked .proj files too. A custom, hand-edited .proj file that I could right click on and "Build".

@davkean
Copy link
Member Author

davkean commented May 13, 2016

From @fearthecowboy on May 11, 2016 17:4

It would be really nice if Visual Studio would support naked .proj files too. A custom, hand-edited .proj file that I could right click on and "Build".

This. A million times. THIS.

@davkean
Copy link
Member Author

davkean commented May 13, 2016

From @luisrudge on May 11, 2016 17:6

I should be able to edit the file from VS without using vs tooling as well.. Will this be possible?

@davkean
Copy link
Member Author

davkean commented May 13, 2016

From @terrajobst on May 11, 2016 18:0

Would something like this work as well?

  <ItemGroup>
    <Compile Include="**\*.cs"
             Exclude="**\*_*.cs" />
    <Compile Include="**\*_Linux.cs"
             Condition="'$(Platform)' == 'Linux'" />
    <Compile Include="**\*_OSX.cs"
             Condition="'$(Platform)' == 'OSX'" />
    <Compile Include="**\*_Win32.cs"
             Condition="'$(Platform)' == 'Win32'" />
  </ItemGroup>

This would allow me to come up with my own naming convention for shared projects that are compiled for multiple platforms.

@VanCoding
Copy link

Okay, from the video, it already looks much better.

2 questions remain, though:

  1. do you consider getting rid of "ItemGroup" and "PropertyGroup" as well?
  2. will MSBuild be needed to compile a .NETCore project, or will the dotnet CLI be able to read .csproj files?
    2.1) If dotnet CLI will be able to read .csproj files, will it also be able to read csproj files in the old format? Wouldn't that mean a LOT of code, because .csproj files can be very dynamic?
    2.2) If it won't be able to read .csproj files, doesn't that mean, that the format is still way too complex and we should maybe remove all the dynamic parts from it completely and create some sort of non-dynamic subset of the format. And as long as you only use that subset only, all tools (including MSBuild & Visual Studio) will be able to read it. And if you need more, you can use all features, but limit yourself to MSBuild and Visual Studio.

@gulbanana
Copy link

gulbanana commented Sep 30, 2016

some of those questions have already been answered in other places. some answers i've picked up from spectating:

  1. ItemGroup and PropertyGroup are a core part of how msbuild works and will not go away. some other parts of the file will though. and item/property groups might become smaller, for example, by turning property sub-elements into attributes

  2. msbuild, as a nuget package, will be a dependency of the dotnet cli. you will continue to run "dotnet compile" and so on but internally it will be using msbuild

2.1) see above - it will be able to read csproj files with old/extra bits, yes. this won't be extra code in the CLI itself because it just uses the msbuild APIs.

@VanCoding
Copy link

@gulbanana Thank you.

This leads to a few more questions:

  • Wasn't dotnet cli able to compile c# without MsBuild?
  • Where can I find the C#-compiler itself? Is it built into MsBuild?

What I don't get is, why do you want to force a build system upon us? To me MsBuild seems to be extactly that, only a build system. I mean, it can also be used to build C++ projects, so it cant be just a compiler.

Why don't you decouple MsBuild (the build system) from the compilers? Wouldn't it be cool, if I could use MsBuild to compile a C++ project with GCC, or C# using the Mono compiler?
And of course, wouldn't it be cool if I could use your C# compiler without MsBuild?

I have so many questions and am not sure if they really fit here or should be answered here. So, I'm sorry if they don't.

@davkean
Copy link
Member Author

davkean commented Sep 30, 2016

@VanCoding Compilers and MSBuild are not tightly coupled. MSBuild effectively calls "csc.exe" to compile C# code. You can call it directly if you would like.

C# using the Mono compiler?

That's exactly what happens today.

@benaadams
Copy link
Member

@VanCoding the Roslyn C# compiler is over here: https://github.com/dotnet/roslyn though there are other compilers.

The dotnet cli uses MsBuild to build the project as it tells it how it fits together.

You can use the C# compiler by itself https://msdn.microsoft.com/en-us/library/78f4aasd.aspx but then you'd need to add your own build system around it.

@VanCoding
Copy link

VanCoding commented Sep 30, 2016

@davkean cool! That explains a lot.
So that should allow us to compile our C# projects without MsBuild.
If so, I think I'll no longer disturb you here, because I'll be able use my own solution in the case that the slimmed down .csproj files don't make me happy :)

Thank you guys, btw!

@chrisaut
Copy link

chrisaut commented Oct 1, 2016

do you consider getting rid of "ItemGroup" and "PropertyGroup" as well?

I have to agree with others here. These are horrible names and I always hate seeing them in proj files. Why can these grouping tags not have some proper name, eg. <References> for the "Itemgroup containing the references?

@gulbanana
Copy link

those groupings are actually arbitrary - you can rearrange them or put everything in a big group if you like.

@chrisaut
Copy link

chrisaut commented Oct 1, 2016

Really? So what's the difference between PropertyGroup and ItemGroup? Are they interchangeable?

@Mike-E-angelo
Copy link

Mike-E-angelo commented Oct 1, 2016

I have to agree with others here. These are horrible names and I always hate seeing them in proj files.

Really? So what's the difference between PropertyGroup and ItemGroup?

Time for me to be the squeaky wheel here and kindly remind everyone that the ask/request for a POCO-based model and system would remedy these sorts of ambiguous dilemmas and frustrations ("and much much more!").

Please take a second to upvote for this issue if you haven't already. It is currently the highest voted item in this repo: #37

Thank you for your past and continued support!

@chrisaut
Copy link

chrisaut commented Oct 1, 2016

@Mike-EEE I agree with you, but I don't think its realistic at this point that they'll do something like that. Maybe in the long run. I'm trying to get them to make it less painful in the meantime. And I have to admit I didn't know property/itemgroup don't really do anything. I still think they are horrible names.

@Mike-E-angelo
Copy link

Haha sounds good, @chrisaut. I have been suffering through this mire for over a decade now, and am in total agreement with your assessment, hence the ideas. You can cover the short/medium-term of all the angst, and I will cover the longer-term. 😄

@vbfox
Copy link

vbfox commented Oct 1, 2016

@chrisaut PropertyGroup contains assignation (a = b) and ItemGroup are for appending (a += b).

You can't interchange because they essentially point to 2 different collection of variables.
You can have just one of each if you wish. Except that visual studio will force his own structure upon you each time you save the project :)

But that's the current design, Microsoft could well allow property and items under Project if they wanted, at the price of msbuild debugging (Misnaming a task is currently an error but could silently be considered a property or item if they were allowed to be mixed) that would make simple projects a lot more readable.

@gulbanana
Copy link

this stuff is all documented at https://msdn.microsoft.com/en-us/library/ms171453.aspx# - it's actually not that complicated - certainly not compared to maven or ant. historically it's seemed like this arcane obtuse thing because visual studio hides it away from you, but my hope is that if we're all hand-editing csproj files for .net core 1.1 or whatever then it will stop scaring people.

@gulbanana
Copy link

gulbanana commented Oct 2, 2016

fwiw, @Mike-EEE, msbuild IS just an object model. you could totally have a project file that looked like this

{
    'ItemGroup': [
        { 'Item': 'Compile', 'Include': 'dir1/*.cs' }
        { 'Item': 'Compile', 'Include': 'specialfile.cs' }
    ],
    'DefaultTarget': {
        'Task': 'Exec',
        'Command': 'csc %(Compile.Identity)'
    }
}

and load it into the api with a basic wrapper frontend. however, nobody bothers to do this because there is no particular value in typing a different kind of bracket.

@Mike-E-angelo
Copy link

Are you sure @gulbanana ? Last we checked the entire API was/is entrenched in XML. Example:
https://github.com/Microsoft/msbuild/tree/master/src/XMakeBuildEngine/Construction

I would be really interested in hearing what you mean here.

Additionally, to be sure, the goal here is to have full POCO objects, not representations/DTO/mapper entities like what ItemGroup/PropertyGroup certainly are. Would you be able to define those objects in a Xaml file? No, as they aren't CLR objects, with a namespace, etc. Once you are in POCO land you gain instant tooling support as well (sort of the biggest motivator here :) ).

@gulbanana
Copy link

that is more xml-tied than i expected - i've used this api
https://github.com/Microsoft/msbuild/blob/master/src/XMakeBuildEngine/Definition/ProjectItem.cs
and didn't realise it was stored internally as backing XML rather than anything more abstract.

still, since the whole thing's declarative it'd be pretty trivial to have a frontend that converts from (other serialisation format) to xml..

@Mike-E-angelo
Copy link

... it'd be pretty trivial ...

Sounds like someone is volunteering for a quick PR to prove it. 😉

@NickCraver
Copy link
Member

NickCraver commented Oct 2, 2016

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
Copy link
Member Author

davkean commented Oct 3, 2016

This issue represents changes that we are making to the project template/format itself. There are some MSBuild changes that we're making to simplify the project file - however, they are being tracked by separate issues.

My comment was not push back on aliasing PropertyGroup/ItemGroup - it was about the fact that we're sticking with existing MSBuild concepts (there will always be properties, items, tasks and targets). The aliasing suggestion is a great one, and should add your thoughts to dotnet/msbuild#820.

@iam3yal
Copy link

iam3yal commented Nov 3, 2016

@davkean I haven't seen any blog post about the changes that comes to MsBuild and to the project files is there any plans for it? I'm watching the repo but it's nice to have a detailed post about it or least a summary about it.

@rainersigwald
Copy link
Member

@eyalsk https://blogs.msdn.microsoft.com/dotnet/2016/10/19/net-core-tooling-in-visual-studio-15/ discusses many of the changes.

@iam3yal
Copy link

iam3yal commented Nov 3, 2016

@rainersigwald Thank you. :)

@davkean
Copy link
Member Author

davkean commented Jan 19, 2017

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.

@davkean davkean closed this as completed Jan 19, 2017
@NickCraver
Copy link
Member

@davkean Thanks for all the progress! It really is far, far better - and I've been using this daily.

Some links for others following along:

@Mike-E-angelo
Copy link

Mike-E-angelo commented Jan 19, 2017

Wow, that is really impressive, actually. I for one would have a bit different impression of MSBuild/VS/developer experience if that was the type of file that we were introduced to work with when creating a new project.

Granted, all the advanced spelunking would probably still result in the sourpuss around the MSBuild development experience that I am now. ;) But first impressions are important and still matter. Really great to see all the work to make this happen. 👍

@mateuszlewko
Copy link

Would that also work for F#? In F# there is a need to list the order of all the .fs files.
Btw, is there any date when it will be published in VS17?

@alrz
Copy link
Member

alrz commented May 23, 2017

other project types in a future release of Visual Studio past VS 2017.

Is there an issue for tracking that work?

@davkean
Copy link
Member Author

davkean commented May 23, 2017

@alrz We have a milestone representing it; https://github.com/dotnet/project-system/blob/master/docs/repo/roadmap.md.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature Request Request for a new feature, or new scenario to be handled. Feature-Project-File-Simplification Related to cleaning up and simplification of the project format. Needs-CPS-work Changes are needed in the closed-source Common Project System (CPS) repo.
Projects
None yet
Development

No branches or pull requests