search

3F / MvsSln

🧩 Customizable VisualStudio .sln parser with project support (.vcxproj, .csproj., …). Pluggable lightweight r/w handlers at runtime, and more …
MIT License
135 stars 27 forks source link

SDK-based project with new target platforms #21

Closed 3F closed 4 years ago

3F commented 4 years ago

Closes #11

Update 1

Target platforms

So, what we decided for today:

I already described process of using with new msbuild packages (contains logic with new Installation API that fixes all active third-software problems) via getnutool + vssbe scrips in issue on nuget project.

However, I still have thoughts about dynamically fixing this dependency. I mean some automation, or rather delegation of responsibilities to ~a configurable loader, accessible to end-users. Here mentioned: #5

Therefore, today's solving the problem of the new API (and more) we will still decide in the same manner like in our wiki: https://github.com/3F/MvsSln/wiki/Examples-override-MS-Project

And finally we'll make today's support for netcore very simple using their available platforms.

(Obsolete)

This adds at least netstandard2.0 and net40.

Planned

Key notes

NU1202. PackageReference vs Reference

<ItemGroup Condition=" '$(TargetFramework)' == 'net40' ">
  <Reference Include="Microsoft.CSharp" />
  <Reference Include="Microsoft.Build" />
</ItemGroup>

<ItemGroup Condition=" '$(TargetFramework)' == 'netstandard2.0' ">
  <PackageReference Include="Microsoft.CSharp" Version="4.6.0" />
  <PackageReference Include="Microsoft.Build" Version="15.9.20" />
</ItemGroup>

15.9.20 is last package with netstandard2.0 target support. 16.0.461 and 16.3.0 contains only .NETCoreApp2.1 and net472. That is, we can try to use Reference for net472 -> netstandard2.0.

NU1202 and netstandard1.1.

For netstandard1.1 I don't see any directly compatible packages. Thus, I'm not sure about PackageReference (any options to disable NU1202 ?) but we can also use at least Reference with some potential problems like MSB3277. For example:

<ItemGroup Condition=" '$(TargetFramework)' == 'net40' ">
  <Reference Include="Microsoft.Build" />
</ItemGroup>

<ItemGroup Condition=" '$(TargetFramework)' == 'netstandard1.1' ">
  <Reference Include="Microsoft.Build, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
    <HintPath>..\packages\microsoft.build.15.9.20\lib\net46\Microsoft.Build.dll</HintPath>
    <Private>True</Private>
  </Reference>

  <!-- Use this to avoid MSB3277 - conflicts between different versions of "System.IO.Compression" -->
  <Reference Include="System.IO.Compression, Version=4.1.2.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
    <HintPath>..\packages\system.io.compression.4.3.0\lib\net46\System.IO.Compression.dll</HintPath>
    <Private>True</Private>
  </Reference>

</ItemGroup>

Cc: @HamedFathi, @carstencodes

3F commented 4 years ago

Something wrong with tests. Different build for the same commit e9ab8b64:

Microsoft.Build.Exceptions.InvalidProjectFileException : The project file could not be loaded. Could not find a part of the path 'C:\snet\snet.csproj'. 
Microsoft.Build.Exceptions.InvalidProjectFileException : The project file could not be loaded. Could not find a part of the path 'C:\snet\snet.csproj'.

The same reason, that's good to isolate problem. But my pc can't reproduce even something -_- rdp is coming

3F commented 4 years ago

Finally this PR will not contain net46. And net472 will no longer reference modern MSBuild packages!

This is because of many additional steps with MSBuild Resolver and MSBuildLocator for trivial use.

However, user can still use custom MSBuild assemblies if needed.

I updated wiki info + added this: https://github.com/3F/MvsSln/wiki/Advanced-Features#how-to-use-modern-versions-of-msbuild-for-netfx

Summary, only netcoreapp2.1 (-> 16.3.0) & netstandard2.0 (-> 15.9.20) will reference packages.

Many, so many problems with modern MSBuild :(

I hope our wiki can help to solve all or most known problems! And I hope for 3.x when we will drop MSBuild dep.