-
-
Notifications
You must be signed in to change notification settings - Fork 27
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
Comments
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 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 I would be really excited to use this package for .NET core based applications. |
Here's my latest Choose/When complete example together with vssbe scripts: 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:
|
Actual PR #21 still is in progress and depends on this issue: 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 ) |
Everybody please note the following. In fact,
In our wiki I added a short article about Custom MSBuild Resolver. PR is ready to merge. Let me just check something before it. And please feedback! |
* 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
* 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
Please support .NET Core beside .NET Framework 4+
The text was updated successfully, but these errors were encountered: