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 #11235

Closed
davkean opened this Issue May 11, 2016 · 52 comments

Comments

Projects
None yet
@davkean
Member

davkean commented May 11, 2016

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>
@davkean

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean May 11, 2016

Member

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

Member

davkean commented May 11, 2016

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

@davkean davkean changed the title from Project System: Clean up default templates, etc to Project System: Remove the cruft from project files and templates May 11, 2016

@davkean

This comment has been minimized.

Show comment
Hide comment
@davkean
Member

davkean commented May 11, 2016

image

@davkean

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean May 11, 2016

Member

See also #10065

Member

davkean commented May 11, 2016

See also #10065

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny May 11, 2016

Member

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

Member

onovotny commented May 11, 2016

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

@davkean

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean May 11, 2016

Member

Yep, good question.

Member

davkean commented May 11, 2016

Yep, good question.

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny May 11, 2016

Member

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

Member

onovotny commented May 11, 2016

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

@NickCraver

This comment has been minimized.

Show comment
Hide comment
@NickCraver

NickCraver May 11, 2016

Member

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.

Member

NickCraver commented May 11, 2016

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

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean May 11, 2016

Member

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.

Member

davkean commented May 11, 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.

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny May 11, 2016

Member

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?

Member

onovotny commented May 11, 2016

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

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean May 11, 2016

Member

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.

Member

davkean commented May 11, 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.

@vbfox

This comment has been minimized.

Show comment
Hide comment
@vbfox

vbfox May 11, 2016

Contributor

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>
Contributor

vbfox commented May 11, 2016

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>
@isaacabraham

This comment has been minimized.

Show comment
Hide comment
@isaacabraham

isaacabraham May 11, 2016

@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 commented May 11, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean May 11, 2016

Member

@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.

Member

davkean commented May 11, 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.

@opinionmachine

This comment has been minimized.

Show comment
Hide comment
@opinionmachine

opinionmachine May 11, 2016

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.

opinionmachine commented May 11, 2016

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.

@pebezo

This comment has been minimized.

Show comment
Hide comment
@pebezo

pebezo May 11, 2016

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.

pebezo commented May 11, 2016

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

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean May 11, 2016

Member

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.

Member

davkean commented May 11, 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.

@benaadams

This comment has been minimized.

Show comment
Hide comment
@benaadams

benaadams May 11, 2016

Contributor

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>
Contributor

benaadams commented May 11, 2016

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>
@aelij

This comment has been minimized.

Show comment
Hide comment
@aelij

aelij May 11, 2016

Contributor

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.

Contributor

aelij commented May 11, 2016

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.

@benaadams

This comment has been minimized.

Show comment
Hide comment
@benaadams

benaadams May 11, 2016

Contributor

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

Contributor

benaadams commented May 11, 2016

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

@pbolduc

This comment has been minimized.

Show comment
Hide comment
@pbolduc

pbolduc May 11, 2016

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

pbolduc commented May 11, 2016

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

@blowdart

This comment has been minimized.

Show comment
Hide comment
@blowdart

blowdart May 11, 2016

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.

blowdart commented May 11, 2016

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.

@MarkPflug

This comment has been minimized.

Show comment
Hide comment
@MarkPflug

MarkPflug May 11, 2016

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".

MarkPflug commented May 11, 2016

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".

@fearthecowboy

This comment has been minimized.

Show comment
Hide comment
@fearthecowboy

fearthecowboy May 11, 2016

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.

fearthecowboy commented May 11, 2016

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.

@luisrudge

This comment has been minimized.

Show comment
Hide comment
@luisrudge

luisrudge May 11, 2016

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

luisrudge commented May 11, 2016

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

@terrajobst

This comment has been minimized.

Show comment
Hide comment
@terrajobst

terrajobst May 11, 2016

Member

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.

Member

terrajobst commented May 11, 2016

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.

@davkean

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean May 11, 2016

Member

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".

A little trick - it already does, via the new project system and it "works" in VS 2015. Create a C# project, rename to .msbuildproj, remove a bunch of targets - you've got a naked project. The experience isn't awesome right now - but its something I'm thinking about as I'm bringing up C#/VB on it.

@luisrudge Can you expand on on what you mean by that?

@terrajobst: We're going to add conditional support for items inside VS - so something like that would work.

Member

davkean commented May 11, 2016

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".

A little trick - it already does, via the new project system and it "works" in VS 2015. Create a C# project, rename to .msbuildproj, remove a bunch of targets - you've got a naked project. The experience isn't awesome right now - but its something I'm thinking about as I'm bringing up C#/VB on it.

@luisrudge Can you expand on on what you mean by that?

@terrajobst: We're going to add conditional support for items inside VS - so something like that would work.

@CoreyKaylor

This comment has been minimized.

Show comment
Hide comment
@CoreyKaylor

CoreyKaylor May 11, 2016

I think it would help to see what a proposed sample would look like for a project producing a nuget targeting net45, sl5, UWP, etc. That was one of the major benefits to using project.json. I don't ever want to open up a solution like Caliburn.Micro and see see this kind of craziness again.

https://github.com/Caliburn-Micro/Caliburn.Micro/blob/master/src/Caliburn.Micro.sln

CoreyKaylor commented May 11, 2016

I think it would help to see what a proposed sample would look like for a project producing a nuget targeting net45, sl5, UWP, etc. That was one of the major benefits to using project.json. I don't ever want to open up a solution like Caliburn.Micro and see see this kind of craziness again.

https://github.com/Caliburn-Micro/Caliburn.Micro/blob/master/src/Caliburn.Micro.sln

@MarkPflug

This comment has been minimized.

Show comment
Hide comment
@MarkPflug

MarkPflug May 11, 2016

Thanks for the tip @davkean. In previous versions I had to use a somewhat hacky csproj file to achieve that, and it needed to contain some oddities to prevent the Configuration/Platform for the solution from getting confused. Looks much better now!

MarkPflug commented May 11, 2016

Thanks for the tip @davkean. In previous versions I had to use a somewhat hacky csproj file to achieve that, and it needed to contain some oddities to prevent the Configuration/Platform for the solution from getting confused. Looks much better now!

@MarkPflug

This comment has been minimized.

Show comment
Hide comment
@MarkPflug

MarkPflug May 11, 2016

@terrajobst Your example would exclude all files with an "_", which would probably lead to some confusion.

I think you would want something more like this:


<Project 
    DefaultTargets="Build"
    xmlns="http://schemas.microsoft.com/developer/msbuild/2003"
>

<PropertyGroup>
    <Platform>Win32</Platform>
</PropertyGroup>

<ItemGroup>
    <CompileLinux Include="**/*_Linux.cs"/>
    <CompileWin Include="**/*_Win.cs"/>
    <CompileOsx Include="**/*_OSX.cs"/>
    <Compile Include="**/*.cs" Exclude="@(CompileLinux);@(CompileWin);@(CompileOsx)"/>

    <Compile Condition="'$(Platform)' == 'Linux'" Include="@(CompileLinux)"/>
    <Compile Condition="'$(Platform)' == 'Win32'" Include="@(CompileWin)"/>
    <Compile Condition="'$(Platform)' == 'Osx'" Include="@(CompileOsx)"/>
</ItemGroup>

<Target Name="Build">
    <Message Text="@(Compile)"/>
</Target>


</Project>

MarkPflug commented May 11, 2016

@terrajobst Your example would exclude all files with an "_", which would probably lead to some confusion.

I think you would want something more like this:


<Project 
    DefaultTargets="Build"
    xmlns="http://schemas.microsoft.com/developer/msbuild/2003"
>

<PropertyGroup>
    <Platform>Win32</Platform>
</PropertyGroup>

<ItemGroup>
    <CompileLinux Include="**/*_Linux.cs"/>
    <CompileWin Include="**/*_Win.cs"/>
    <CompileOsx Include="**/*_OSX.cs"/>
    <Compile Include="**/*.cs" Exclude="@(CompileLinux);@(CompileWin);@(CompileOsx)"/>

    <Compile Condition="'$(Platform)' == 'Linux'" Include="@(CompileLinux)"/>
    <Compile Condition="'$(Platform)' == 'Win32'" Include="@(CompileWin)"/>
    <Compile Condition="'$(Platform)' == 'Osx'" Include="@(CompileOsx)"/>
</ItemGroup>

<Target Name="Build">
    <Message Text="@(Compile)"/>
</Target>


</Project>
@davkean

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean May 11, 2016

Member

Just to set expectations again - above is not a design of what project.json in csproj looks like. I wrote this 6 months ago based on a tweet someone said to me, and just wanted to get a bug started for conversations.

Member

davkean commented May 11, 2016

Just to set expectations again - above is not a design of what project.json in csproj looks like. I wrote this 6 months ago based on a tweet someone said to me, and just wanted to get a bug started for conversations.

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny May 11, 2016

Member

@davkean Is there a place (shared one note, wherever) where interested external parties can participate in the feature design, including some meetings?

Member

onovotny commented May 11, 2016

@davkean Is there a place (shared one note, wherever) where interested external parties can participate in the feature design, including some meetings?

@luisrudge

This comment has been minimized.

Show comment
Hide comment
@luisrudge

luisrudge May 11, 2016

@davkean I could edit the project.json file by hand using VS. But, today, I can't edit the .csproj file by hand, only using VS GUI, correct? So, my question is: Can I edit the .csproj file by hand with this new system?

luisrudge commented May 11, 2016

@davkean I could edit the project.json file by hand using VS. But, today, I can't edit the .csproj file by hand, only using VS GUI, correct? So, my question is: Can I edit the .csproj file by hand with this new system?

@bbarry

This comment has been minimized.

Show comment
Hide comment
@bbarry

bbarry May 11, 2016

You can edit the csproj by hand today, you have to unload the project first. The intellisense in project.json is nicer though.

bbarry commented May 11, 2016

You can edit the csproj by hand today, you have to unload the project first. The intellisense in project.json is nicer though.

@luisrudge

This comment has been minimized.

Show comment
Hide comment
@luisrudge

luisrudge May 11, 2016

@bbarry yeah.. that's a shitty experience though

luisrudge commented May 11, 2016

@bbarry yeah.. that's a shitty experience though

@davkean

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean May 11, 2016

Member

@luisrudge We're tracking that somewhat via: #10065. Currently we use the "XML language service" to edit the project - but you could image that we'll probably end up creating a real language service for MSBuild for IntelliSense, etc. Combined with the debugger - I think we could make it much nicer to work with than today.

Member

davkean commented May 11, 2016

@luisrudge We're tracking that somewhat via: #10065. Currently we use the "XML language service" to edit the project - but you could image that we'll probably end up creating a real language service for MSBuild for IntelliSense, etc. Combined with the debugger - I think we could make it much nicer to work with than today.

@davkean

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean May 11, 2016

Member

@onovotny Right now that place (for the project system) is Roslyn. We're going to fire up issues over on the project system repo - but too be honest, we're trying to lock down RC2, and haven't started any design yet.

Member

davkean commented May 11, 2016

@onovotny Right now that place (for the project system) is Roslyn. We're going to fire up issues over on the project system repo - but too be honest, we're trying to lock down RC2, and haven't started any design yet.

@MarkPflug

This comment has been minimized.

Show comment
Hide comment
@MarkPflug

MarkPflug May 11, 2016

With the goal of simplifying things, why not have **\*.cs defaulted in by the Microsoft.CSharp.targets. This way a "default" csproj file wouldn't even need to specify what files it wants to compile, that would be defined by the imported targets file. The default would only be defined if the csproj didn't override it by attaching a Condition to the ItemGroup.

<ItemGroup Condition="'@(Compile)' ==''">
    <Compile Include="$(MSBuildProjectDirectory)\**\*.cs"/>
</ItemGroup>

If almost all csproj files are going to use this, it should just be the default behavior.

This same concept could be applied to References, and common properties. If all you wanted was a simple class library, the csproj could be made as simple as:

<Project
    xmlns="http://schemas.microsoft.com/developer/msbuild/2003"
>
  <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
</Project>

The default assembly/namespace name could be derived from the csproj filename. The platform could be defaulted. A standard set of references could be defaulted.

MarkPflug commented May 11, 2016

With the goal of simplifying things, why not have **\*.cs defaulted in by the Microsoft.CSharp.targets. This way a "default" csproj file wouldn't even need to specify what files it wants to compile, that would be defined by the imported targets file. The default would only be defined if the csproj didn't override it by attaching a Condition to the ItemGroup.

<ItemGroup Condition="'@(Compile)' ==''">
    <Compile Include="$(MSBuildProjectDirectory)\**\*.cs"/>
</ItemGroup>

If almost all csproj files are going to use this, it should just be the default behavior.

This same concept could be applied to References, and common properties. If all you wanted was a simple class library, the csproj could be made as simple as:

<Project
    xmlns="http://schemas.microsoft.com/developer/msbuild/2003"
>
  <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
</Project>

The default assembly/namespace name could be derived from the csproj filename. The platform could be defaulted. A standard set of references could be defaulted.

@SLaks

This comment has been minimized.

Show comment
Hide comment
@SLaks

SLaks May 11, 2016

Contributor

@terrajobst Or, better yet,

    <Compile Include="**\*_$(Platform).cs" />
Contributor

SLaks commented May 11, 2016

@terrajobst Or, better yet,

    <Compile Include="**\*_$(Platform).cs" />
@Mike-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE May 11, 2016

👍 to @bbarry and @luisrudge. My primary concern here is: what is a <Project /> tag? Where can I go to see its properties and definition? Or an <ItemGroup /> tag? Or a <PropertyGroup /> tag? To this day I have yet to have been able to find the POCOs that these tags represent. ALL THE CONFUSE!

JSON did better with tooling, but what is that file actually describing? Here I go again to Xaml, as in a Xaml file, you see precisely where the namespace, assembly, and the name of the file is -- right in the file. Using ReSharper, I can hit CTRL-B on any property within the file and be taken straight into (decompiled) source for more information -- no guesswork or schema-hunting. As I am working with a file that is based on a class definition, this helps out with not only building the file, but also building tooling around building the file itself, as well.

(FWIW I am indeed promoting/suggesting/endorsing a Xaml-based project file format, but I am open to any format as long as the key qualities I list here are met.. :) )

Going back to the JSON design, while it was better than the XML format, it still did not at any point (that I know of -- please correct me if I am wrong!) point to an actual POCO, and its schema was "yet another JSON file/artifact" that you had to chase down somewhere (ala .NET configuration).

Whatever format or design decisions we land on, please please please make the file format represent an actual POCO with an actual .NET namespace location where we can actually go and get more information around it, instead of having to scratch our head over what the heck sort of arbitrarily-defined object we're working with. 😛

There should be a 1:1 mapping between the file we're describing and the object that ultimately gets deserialized into memory. That is, the class definition should be the schema of the file. This approach reduces complexity, number of required artifacts, and helps with designers/tooling in building around it.

In any case, I am glad to see this revisited and asking for the community's input. You've made the right call, and have done the right thing here. 😄

Mike-EEE commented May 11, 2016

👍 to @bbarry and @luisrudge. My primary concern here is: what is a <Project /> tag? Where can I go to see its properties and definition? Or an <ItemGroup /> tag? Or a <PropertyGroup /> tag? To this day I have yet to have been able to find the POCOs that these tags represent. ALL THE CONFUSE!

JSON did better with tooling, but what is that file actually describing? Here I go again to Xaml, as in a Xaml file, you see precisely where the namespace, assembly, and the name of the file is -- right in the file. Using ReSharper, I can hit CTRL-B on any property within the file and be taken straight into (decompiled) source for more information -- no guesswork or schema-hunting. As I am working with a file that is based on a class definition, this helps out with not only building the file, but also building tooling around building the file itself, as well.

(FWIW I am indeed promoting/suggesting/endorsing a Xaml-based project file format, but I am open to any format as long as the key qualities I list here are met.. :) )

Going back to the JSON design, while it was better than the XML format, it still did not at any point (that I know of -- please correct me if I am wrong!) point to an actual POCO, and its schema was "yet another JSON file/artifact" that you had to chase down somewhere (ala .NET configuration).

Whatever format or design decisions we land on, please please please make the file format represent an actual POCO with an actual .NET namespace location where we can actually go and get more information around it, instead of having to scratch our head over what the heck sort of arbitrarily-defined object we're working with. 😛

There should be a 1:1 mapping between the file we're describing and the object that ultimately gets deserialized into memory. That is, the class definition should be the schema of the file. This approach reduces complexity, number of required artifacts, and helps with designers/tooling in building around it.

In any case, I am glad to see this revisited and asking for the community's input. You've made the right call, and have done the right thing here. 😄

@Mike-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE May 11, 2016

BTW/FWIW @davkean project format/improvement was brought up w/ MSBuild's repo a while ago and was shot down and dismissed.

Mike-EEE commented May 11, 2016

BTW/FWIW @davkean project format/improvement was brought up w/ MSBuild's repo a while ago and was shot down and dismissed.

@davkean

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean May 11, 2016

Member

To set expectations up-front and clear for future replies to this issue - this isn't tracking a complete "redesign" of the project format. The reason xproj is moving to MSBuild is to unify existing assets, projects, infrastructure across the entire .NET stack, not for us to come up with something new.

What this issue is tracking, is the simplification of the project format and default templates - can we do things that enable developers to feel comfortable and understand what the project file does and contains, and remove things that only exist for VS purposes? We also have other issues that are tracking other ways we could change the tooling to get of your way. 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.

Member

davkean commented May 11, 2016

To set expectations up-front and clear for future replies to this issue - this isn't tracking a complete "redesign" of the project format. The reason xproj is moving to MSBuild is to unify existing assets, projects, infrastructure across the entire .NET stack, not for us to come up with something new.

What this issue is tracking, is the simplification of the project format and default templates - can we do things that enable developers to feel comfortable and understand what the project file does and contains, and remove things that only exist for VS purposes? We also have other issues that are tracking other ways we could change the tooling to get of your way. 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.

@terrajobst

This comment has been minimized.

Show comment
Hide comment
@terrajobst

terrajobst May 11, 2016

Member

@SLaks

Not sure why this didn't occur to me 😄. Not enough ☕️ maybe?

Member

terrajobst commented May 11, 2016

@SLaks

Not sure why this didn't occur to me 😄. Not enough ☕️ maybe?

@bbarry

This comment has been minimized.

Show comment
Hide comment
@bbarry

bbarry May 12, 2016

I think including Microsoft.CSharp by default is good. And if supporting multiple frameworks is expected to become a common practice it would be nice to have a defaulted compilation symbol or two per standard framework to drive common #ifdef patterns.

bbarry commented May 12, 2016

I think including Microsoft.CSharp by default is good. And if supporting multiple frameworks is expected to become a common practice it would be nice to have a defaulted compilation symbol or two per standard framework to drive common #ifdef patterns.

@shederman

This comment has been minimized.

Show comment
Hide comment
@shederman

shederman May 12, 2016

Sorry, how can we trust anyone talking about the improvements that are going to be made to MSBuild/project system? How do we know the decisions won't just be undone without consultation? How do we know we won't get royally stuffed around at the last minute? Just like we are now?

shederman commented May 12, 2016

Sorry, how can we trust anyone talking about the improvements that are going to be made to MSBuild/project system? How do we know the decisions won't just be undone without consultation? How do we know we won't get royally stuffed around at the last minute? Just like we are now?

@shederman

This comment has been minimized.

Show comment
Hide comment
@shederman

shederman May 12, 2016

Please take the survey at https://www.surveymonkey.com/r/H6Q88PP to weigh in.

shederman commented May 12, 2016

Please take the survey at https://www.surveymonkey.com/r/H6Q88PP to weigh in.

@isaacabraham

This comment has been minimized.

Show comment
Hide comment
@isaacabraham

isaacabraham May 12, 2016

@Mike-EEE Hmm. That issue seems to be talking about a JSON or YAML version of the project file; this is about simply trimming down what's already there rather than reformatting it.

isaacabraham commented May 12, 2016

@Mike-EEE Hmm. That issue seems to be talking about a JSON or YAML version of the project file; this is about simply trimming down what's already there rather than reformatting it.

@Mike-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE May 12, 2016

@isaacabraham correct. My intent was to show @davkean after my rant (oops, sorry! 😄 ) that previous efforts have been made over @ the MSBuild group to improve its format and they fell on deaf ears. This was in reply to:

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.

So, I guess we aren't better off, in any case. 😛 Anyways, thank you for your patience (I hope?) with me. I've created an issue from my post here: #11263

Mike-EEE commented May 12, 2016

@isaacabraham correct. My intent was to show @davkean after my rant (oops, sorry! 😄 ) that previous efforts have been made over @ the MSBuild group to improve its format and they fell on deaf ears. This was in reply to:

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.

So, I guess we aren't better off, in any case. 😛 Anyways, thank you for your patience (I hope?) with me. I've created an issue from my post here: #11263

@Mike-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE May 12, 2016

Thanks for your patience all. After a little thought, I took @davkean's suggestion and have created a new issue on MSBuild's board to discuss project file/model changes: Microsoft/msbuild#613 Hopefully with the current climate of all the changes it will get a little more reception/dialogue. Please feel free to add your comments/feedback and votes/reactions.

Now @davkean has a location to direct angry/bombastic/impulsive developers such as myself to visit, rather than constantly posting on this thread to keep everyone on task/topic. 😄

Mike-EEE commented May 12, 2016

Thanks for your patience all. After a little thought, I took @davkean's suggestion and have created a new issue on MSBuild's board to discuss project file/model changes: Microsoft/msbuild#613 Hopefully with the current climate of all the changes it will get a little more reception/dialogue. Please feel free to add your comments/feedback and votes/reactions.

Now @davkean has a location to direct angry/bombastic/impulsive developers such as myself to visit, rather than constantly posting on this thread to keep everyone on task/topic. 😄

@shederman

This comment has been minimized.

Show comment
Hide comment
@shederman

shederman May 13, 2016

If you read the comments in that link you will see precisely why we need to move away from MSBuild. The developers on that thread do not even grasp the concept that MSBuild isn't the perfect solution to all build issues. Every suggested solution and link is about using MSBuild in different ways. They have one multi configurable hammer, and everything is a nail.

The basic feeling appears to be that if you don't want to use MSBuild then either:
a) You don't know MSBuild well enough
b) You're not a "Good Developer"

There's zero understanding that a great many people have used it, fought with it, hated it, and don't want it anymore.

shederman commented May 13, 2016

If you read the comments in that link you will see precisely why we need to move away from MSBuild. The developers on that thread do not even grasp the concept that MSBuild isn't the perfect solution to all build issues. Every suggested solution and link is about using MSBuild in different ways. They have one multi configurable hammer, and everything is a nail.

The basic feeling appears to be that if you don't want to use MSBuild then either:
a) You don't know MSBuild well enough
b) You're not a "Good Developer"

There's zero understanding that a great many people have used it, fought with it, hated it, and don't want it anymore.

@Mike-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE May 13, 2016

Haha yeah I have to agree with @shederman ... not a whole lot of luv in the msbuild camp/repo it seems at the moment, but hopefully we can get to a place where everyone is happy. :)

Mike-EEE commented May 13, 2016

Haha yeah I have to agree with @shederman ... not a whole lot of luv in the msbuild camp/repo it seems at the moment, but hopefully we can get to a place where everyone is happy. :)

@shederman

This comment has been minimized.

Show comment
Hide comment
@shederman

shederman May 13, 2016

From aspnet/Home#1433:

@shederman
PS. If you are going to carry on ignoring opposition, can you please provide the following:

How we'd gain access to the build tools developer slack channels
A high level view of the current architecture and code, and where the changes to move to MSBuild/xproj are going to be made so we can plan our approach to keep the bits we want and integrate well.
Assurance that pull requests baking in project.json based tooling will be accepted if meet the quality criteria
Assurance that if quality criteria are met, we can include "dotnet build" support for full project.json, as well as ASP.NET Simple templates, and potentially some templates for more standard project types as well.
"Be constructive", "don't contribute, don't get a voice". Well, you get what you ask for...

@Mike-EEE, wanna do Xaml serializations for SimpleUseCaseBuild?

shederman commented May 13, 2016

From aspnet/Home#1433:

@shederman
PS. If you are going to carry on ignoring opposition, can you please provide the following:

How we'd gain access to the build tools developer slack channels
A high level view of the current architecture and code, and where the changes to move to MSBuild/xproj are going to be made so we can plan our approach to keep the bits we want and integrate well.
Assurance that pull requests baking in project.json based tooling will be accepted if meet the quality criteria
Assurance that if quality criteria are met, we can include "dotnet build" support for full project.json, as well as ASP.NET Simple templates, and potentially some templates for more standard project types as well.
"Be constructive", "don't contribute, don't get a voice". Well, you get what you ask for...

@Mike-EEE, wanna do Xaml serializations for SimpleUseCaseBuild?

@davkean

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean May 13, 2016

Member

This issue has been moved dotnet/project-system#40. Apologies for the spam.

Member

davkean commented May 13, 2016

This issue has been moved dotnet/project-system#40. Apologies for the spam.

@davkean davkean closed this May 13, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment