Closed HamedFathi closed 4 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.
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?
@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:
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.
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.
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)
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.
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.
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!
Please support .NET Core beside .NET Framework 4+