Skip to content
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

Please support .NET Core #11

Closed
HamedFathi opened this issue May 14, 2019 · 9 comments · Fixed by #21
Closed

Please support .NET Core #11

HamedFathi opened this issue May 14, 2019 · 9 comments · Fixed by #21
Milestone

Comments

@HamedFathi
Copy link

Please support .NET Core beside .NET Framework 4+

@3F
Copy link
Owner

3F commented May 14, 2019

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.

@HamedFathi
Copy link
Author

HamedFathi commented May 15, 2019

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
Copy link
Owner

3F commented May 15, 2019

@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
Copy link

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
Copy link
Owner

3F commented Jul 17, 2019

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
Copy link
Owner

3F commented Sep 26, 2019

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 3F added this to the 2.5 milestone Sep 26, 2019
3F added a commit that referenced this issue Sep 29, 2019
@3F
Copy link
Owner

3F commented Oct 5, 2019

Actual PR #21 still is in progress and depends on this issue:
NuGet/Home#8644

Join discussion or follow the news.

@3F
Copy link
Owner

3F commented Oct 11, 2019

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
Copy link
Owner

3F commented Oct 15, 2019

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!

@3F 3F closed this as completed in #21 Oct 17, 2019
3F added a commit that referenced this issue Oct 17, 2019
* New SDK-based project file and build scripts.

+netstandard2.0. Issue #11

* fixed build

* net40, net46, net472, netstandard2.0, netcoreapp2.1

* Unit-tests have been ported to xUnit from old MSTest

* EnvDTE is obsolete now

* DocumentationFile as $(OutputPath)$(AssemblyName).xml

* net472 will no longer reference modern MSBuild package!

Also removed net46 due to net472 changes.

Details in #21
3F added a commit that referenced this issue Oct 17, 2019
* FIXED: Fixed parallelism problems when using Sln wrapper.

* FIXED: Incorrect initialization for ProjectReferences class.

* NEW: Added .net core based target platforms: netcoreapp2.1. + netstandard2.0. Issue #11.

* NEW: Added netfx based target platforms: net472. PR #21.

* NEW: IXProject methods:
    ```
    +bool AddPackageReference(string id, string version, IEnumerable<KeyValuePair<string, string>> meta = null);
    +Item GetFirstPackageReference(string id);
    +bool RemovePackageReference(string id);
    ```

* CHANGED: EnvDTE features are obsolete now. Scheduled for removal in future major releases. Issue #22.

* CHANGED: MathExtension.CalculateHashCode now encapsulates GetHashCode() with null checking.

* CHANGED: Compatible signature changes for the following extension method:
    ```
    AddOrUpdate(this IDictionary<string, string> source, IEnumerable<KeyValuePair<string, string>> items)
    ```

* KNOWN: Various [ possible ] problems when using modern MSBuild assemblies.

        ! Solution and details in our wiki:
        https://github.com/3F/MvsSln/wiki/Advanced-Features

        Do not hesitate to contact: https://github.com/3F/MvsSln/issues

* NOTE: Discuss the planned v3.0 and its major changes:
        https://github.com/3F/MvsSln/milestone/4
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants