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

Please support .NET Core #11

Closed HamedFathi closed 4 years ago

HamedFathi commented 5 years ago

Please support .NET Core beside .NET Framework 4+

3F commented 5 years ago

Sure. I can't say specific dates, but plans for this are already voiced earlier here: https://github.com/3F/MvsSln/issues/5#issuecomment-480867917

Of course anyone else can speed up the process via PR. Or please wait for my time.

HamedFathi commented 5 years ago

Sure. I can't say specific dates, but plans for this are already voiced earlier here: #5 (comment)

Of course anyone else can speed up the process via PR. Or please wait for my time.

I am not sure this can be a PR, because you should change your .NET Framework target and it would be a breaking change for your users. (They should update .NET Framework 4 to .NET Framework 4.7.2)

I checked your library, it works great with these configs.

<TargetFrameworks>netcoreapp2.1;net472</TargetFrameworks>
<ItemGroup>
    <PackageReference Include="Microsoft.Build" Version="16.0.461" />
</ItemGroup>

I compiled it successfully but this should be for vNext (MvsSln 3.0).

What do you think?

3F commented 5 years ago

@HamedFathi No. We need to provide both because we have no plans to drop support .netfx 4.0 at least this year.

That is, I can accept only changes to build separate platforms at the same time. This can be achieved via vssbe-scripts (this project already controlled by this) and/or additional msbuild targets.

about minimal .netfx 4.6 see here:

carstencodes commented 4 years ago

I think it is possible to support both variants. It is a little tricky:

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

and for the packages

  <ItemGroup Condition="'$(TargetFramework)' != 'net40'">
    <PackageReference Include="Microsoft.Build" Version="16.0.461" />
    <PackageReference Include="Microsoft.CSharp" Version="4.5.0" />
  </ItemGroup>

This way, you can address multiple target frameworks (just replace net472 by net40) in @HamedFathi 's comment and hence can create a nuget package for both frameworks.

I would be really excited to use this package for .NET core based applications.

3F commented 4 years ago

I think it is possible to support both variants.

Here's my latest Choose/When complete example together with vssbe scripts: https://github.com/3F/vsSolutionBuildEvent/blob/master/vsSolutionBuildEvent/vsSolutionBuildEvent.csproj#L166

That allows more complex separate distribution even for vsix and nuget packages, like this:

But again, please use PR or wait for my time. I have other priority tasks at this moment, and just 2 hands.

Thanks for using.

3F commented 4 years ago

Good news! I just released related vsSolutionBuildEvent project. And now I've plan to review current issue this or next week.

Also, I think about the same scheme like in https://www.nuget.org/packages/E-MSBuild/ where package dependencies:

.NETFramework 4.0          <<<<<<<<<
    Varhead (>= 1.14.0)

.NETStandard 2.0
    Microsoft.Build (>= 15.9.20)     <<<<<<<<<<<
    Microsoft.Build.Framework (>= 16.0.461)
    Varhead (>= 1.14.0)
3F commented 4 years ago

Actual PR https://github.com/3F/MvsSln/pull/21 still is in progress and depends on this issue: https://github.com/NuGet/Home/issues/8644

Join discussion or follow the news.

3F commented 4 years ago

After a brief discussion with the team where this project is actively used with old platforms, I decided to do the following: #21 ( 'Update 1' section ) I'll update this PR very soon.

3F commented 4 years ago

Everybody please note the following.

In fact,

modern Microsoft.Build assemblies are much more closely integrated with Visual Studio and much more difficult to maintain independently.

In our wiki I added a short article about Custom MSBuild Resolver. Let me know if you have some misunderstanding. Here or in new issue.

PR is ready to merge. Let me just check something before it. And please feedback!