Project System: Remove the cruft from project files and templates #40
Comments
davkean
added
Area-Project System
Needs-CPS-work
|
Or even better, not even need the references - just reference everything by default, similar to what we did in UWP, Portable, etc |
|
|
|
See also dotnet/roslyn#10065 |
|
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? |
|
Yep, good question. |
|
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 |
|
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. |
|
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. |
|
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? |
|
Two schools of thoughts, leave it today with just package refs, or replace it with "MSBuild equivalents" a la |
|
From @vbfox on May 11, 2016 7:59
Both references, and 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> |
|
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. |
|
@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. |
|
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. |
|
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. |
|
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. |
|
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> |
|
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. |
|
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 |
|
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. |
|
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. |
|
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 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". |
|
From @fearthecowboy on May 11, 2016 17:4
This. A million times. THIS. |
|
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? |
|
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. |
|
some of those questions have already been answered in other places. some answers i've picked up from spectating:
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. |
|
@gulbanana Thank you. This leads to a few more questions:
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? 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. |
|
@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.
That's exactly what happens today. |
|
@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. |
|
@davkean cool! That explains a lot. Thank you guys, btw! |
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. |
|
those groupings are actually arbitrary - you can rearrange them or put everything in a big group if you like. |
|
Really? So what's the difference between PropertyGroup and ItemGroup? Are they interchangeable? |
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! |
|
@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. |
|
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. 😄 |
|
@chrisaut You can't interchange because they essentially point to 2 different collection of variables. But that's the current design, Microsoft could well allow property and items under |
|
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. |
|
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. |
|
Are you sure @gulbanana ? Last we checked the entire API was/is entrenched in XML. Example: 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 :) ). |
|
that is more xml-tied than i expected - i've used this api still, since the whole thing's declarative it'd be pretty trivial to have a frontend that converts from (other serialisation format) to xml.. |
Sounds like someone is volunteering for a quick PR to prove it. 😉 |
|
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:
and
...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. 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. |
|
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. |
|
@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. |
|
@eyalsk https://blogs.msdn.microsoft.com/dotnet/2016/10/19/net-core-tooling-in-visual-studio-15/ discusses many of the changes. |
|
@rainersigwald Thank you. :) |
|
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:
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 Thanks for all the progress! It really is far, far better - and I've been using this daily. Some links for others following along:
|
|
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. 👍 |
|
Would that also work for F#? In F# there is a need to list the order of all the .fs files. |
Is there an issue for tracking that work? |
|
@alrz We have a milestone representing it; https://github.com/dotnet/project-system/blob/master/docs/repo/roadmap.md. |
From @davkean on May 11, 2016 1:35
Want to go from something like:
To something like:
Copied from original issue: dotnet/roslyn#11235
The text was updated successfully, but these errors were encountered: