Msbuild: Replace MSBuild Condition Attributes with Specific Elements

Created on 21 Nov 2016  路  6Comments  路  Source: dotnet/msbuild

from https://github.com/dotnet/cli/issues/4796 based on https://github.com/dotnet/cli/issues/4796#issuecomment-262077083.

I can see the below conditional properties inside my csproj file:

<ItemGroup Condition=" '$(TargetFramework)' == 'netcoreapp1.0' ">
   <PackageReference Include="Microsoft.NETCore.App">
     <Version>1.1.0</Version>
   </PackageReference>
</ItemGroup>

This is really hard to remember and hand-type. I am not going to get into how this was easy in project.json (opps, I did). At least it would be nice to simplify this like below:

<Framework name="netcoreapp1.0">
   <Dependencies>
      <PackageReference Include="Microsoft.NETCore.App">
          <Version>1.1.0</Version>
      </PackageReference>
   </Dependencies>
</Framework>

Environment data

dotnet --info output:

Z:\>dotnet --info
.NET Command Line Tools (1.0.0-preview3-004056)

Product Information:
 Version:            1.0.0-preview3-004056
 Commit SHA-1 hash:  ccc4968bc3

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.10240
 OS Platform: Windows
 RID:         win10-x64

Most helpful comment

Pulling the version up into an attribute would make it even more concise:

<Framework name="netcoreapp1.0">
   <Dependencies>
      <PackageReference Include="Microsoft.NETCore.App" Version="1.1.0" />
   </Dependencies>
</Framework>

I'm fine with adding less commonly used properties within the PackageReference node, but having the Version there just adds bloat to the file imho.

The difference between editing the project.json file and the new csproj file by hand is a difference of night and day, I'm not saying I want project.json back as I understand why the move is happening. I just think that this scenario worked way better in project.json, and I hope things improve before RTM (I already saw a tweet / image somewhere that there is already an ongoing effort to reduce the bloat of a minimal csproj).

Reducing the verbosity combined with IntelliSense support (like project.json had) for the packages and versions would be great!

All 6 comments

Pulling the version up into an attribute would make it even more concise:

<Framework name="netcoreapp1.0">
   <Dependencies>
      <PackageReference Include="Microsoft.NETCore.App" Version="1.1.0" />
   </Dependencies>
</Framework>

I'm fine with adding less commonly used properties within the PackageReference node, but having the Version there just adds bloat to the file imho.

The difference between editing the project.json file and the new csproj file by hand is a difference of night and day, I'm not saying I want project.json back as I understand why the move is happening. I just think that this scenario worked way better in project.json, and I hope things improve before RTM (I already saw a tweet / image somewhere that there is already an ongoing effort to reduce the bloat of a minimal csproj).

Reducing the verbosity combined with IntelliSense support (like project.json had) for the packages and versions would be great!

@jvandertil Package version as attribute is possible since #1093. It's not the default in VS2017 RC because some other pieces had to line up (VS needed to be able to edit a file represented that way, and the new-project templates must be updated to use it). But it's coming!

@rainersigwald Excellent news! I did indeed see something like that appear in a picture somewhere. This and #1372 are probably the things I miss the most from project.json. Can't wait to see what you guys come up with :).

this would be great 馃憤
Ideally the less verbose the better; after migrating my core project in vs17rc I ended up rolling back as this was just... terrible.

I've no idea what the plan is around tooling for this etc; also taking into account the poor sods in other environments who will have to deal with this.

If final MSBuild based project system for .NET Core has this, #1372 and #1392, I am pretty sure that it will get A LOT easier to edit the project file w/o any tooling help.

We cover some other proposals here: https://github.com/Microsoft/msbuild/issues/820

Was this page helpful?
0 / 5 - 0 ratings