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

Comments

Projects
None yet
@davkean
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

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean May 13, 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 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

This comment has been minimized.

Show comment
Hide comment
@davkean
Member

davkean commented May 13, 2016

image

@davkean

This comment has been minimized.

Show comment
Hide comment
@davkean
Member

davkean commented May 13, 2016

@davkean

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean May 13, 2016

Member

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?

Member

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

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean May 13, 2016

Member

Yep, good question.

Member

davkean commented May 13, 2016

Yep, good question.

@davkean

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean May 13, 2016

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean May 13, 2016

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean May 13, 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 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

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean May 13, 2016

Member

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?

Member

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

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean May 13, 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 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

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean May 13, 2016

Member

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

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

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean May 13, 2016

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean May 13, 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 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

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean May 13, 2016

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean May 13, 2016

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean May 13, 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 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

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean May 13, 2016

Member

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

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

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean May 13, 2016

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean May 13, 2016

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean May 13, 2016

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean May 13, 2016

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean May 13, 2016

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean May 13, 2016

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean May 13, 2016

Member

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?

Member

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

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean May 13, 2016

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@VanCoding

VanCoding Sep 30, 2016

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.

VanCoding commented Sep 30, 2016

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

This comment has been minimized.

Show comment
Hide comment
@gulbanana

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

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

This comment has been minimized.

Show comment
Hide comment
@VanCoding

VanCoding Sep 30, 2016

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

VanCoding commented Sep 30, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean Sep 30, 2016

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@benaadams

benaadams Sep 30, 2016

Contributor

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

Contributor

benaadams commented Sep 30, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@VanCoding

VanCoding 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!

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

This comment has been minimized.

Show comment
Hide comment
@chrisaut

chrisaut 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?

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

This comment has been minimized.

Show comment
Hide comment
@gulbanana

gulbanana Oct 1, 2016

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

gulbanana commented Oct 1, 2016

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

@chrisaut

This comment has been minimized.

Show comment
Hide comment
@chrisaut

chrisaut Oct 1, 2016

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

chrisaut commented Oct 1, 2016

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

@Mike-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE 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!

Mike-EEE 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

This comment has been minimized.

Show comment
Hide comment
@chrisaut

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

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

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE Oct 1, 2016

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

Mike-EEE commented Oct 1, 2016

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

This comment has been minimized.

Show comment
Hide comment
@vbfox

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

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

This comment has been minimized.

Show comment
Hide comment
@gulbanana

gulbanana Oct 2, 2016

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 commented Oct 2, 2016

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

This comment has been minimized.

Show comment
Hide comment
@gulbanana

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

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

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE Oct 2, 2016

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 :) ).

Mike-EEE commented Oct 2, 2016

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

This comment has been minimized.

Show comment
Hide comment
@gulbanana

gulbanana Oct 2, 2016

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

gulbanana commented Oct 2, 2016

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

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE Oct 2, 2016

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

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

Mike-EEE commented Oct 2, 2016

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

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

@NickCraver

This comment has been minimized.

Show comment
Hide comment
@NickCraver

NickCraver Oct 2, 2016

Member

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.

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

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean Oct 3, 2016

Member

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 Microsoft/msbuild#820.

Member

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 Microsoft/msbuild#820.

@eyalsk

This comment has been minimized.

Show comment
Hide comment
@eyalsk

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

eyalsk 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

This comment has been minimized.

Show comment
Hide comment
@eyalsk

This comment has been minimized.

Show comment
Hide comment
@eyalsk

eyalsk commented Nov 3, 2016

@rainersigwald Thank you. :)

@davkean

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean Jan 19, 2017

Member

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.

Member

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 Jan 19, 2017

@NickCraver

This comment has been minimized.

Show comment
Hide comment
@NickCraver

NickCraver Jan 19, 2017

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:

  • Intellisense issue is here: #1249
  • Making .csproj more readable (e.g. <References> being an alias for <PropertyGroup>) is here: Microsoft/msbuild#820
Member

NickCraver commented Jan 19, 2017

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

  • Intellisense issue is here: #1249
  • Making .csproj more readable (e.g. <References> being an alias for <PropertyGroup>) is here: Microsoft/msbuild#820
@Mike-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE 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. 👍

Mike-EEE 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

This comment has been minimized.

Show comment
Hide comment
@mateuszlewko

mateuszlewko Mar 18, 2017

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?

mateuszlewko commented Mar 18, 2017

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

This comment has been minimized.

Show comment
Hide comment
@alrz

alrz May 23, 2017

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

Is there an issue for tracking that work?

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

This comment has been minimized.

Show comment
Hide comment
@davkean
Member

davkean commented May 23, 2017

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