Skip to content
This repository was archived by the owner on Jan 23, 2023. It is now read-only.

Lock Vectors reference assembly to 4.1.3.0 and don't OOB it on netcoreapp2.0#29183

Merged
ericstj merged 1 commit intodotnet:masterfrom
ericstj:lockVectors
Apr 20, 2018
Merged

Lock Vectors reference assembly to 4.1.3.0 and don't OOB it on netcoreapp2.0#29183
ericstj merged 1 commit intodotnet:masterfrom
ericstj:lockVectors

Conversation

@ericstj
Copy link
Copy Markdown
Member

@ericstj ericstj commented Apr 18, 2018

System.Numerics.Vectors was made inbox in netcoreapp2.0, we were still allowing distribution
in the package, however the package was applying the netstandard2.0 implementation to
netcoreapp2.0.

Now that we've disabled oobing the netcoreapp2.1 build (since many types were moved into
corelib) it no longer makes sense for us to mantain the ability to oob the netcoreapp2.0 build.

Doing so not only degrades the inbox version (by not using the framework's MathF
implementation) but also creates type-unfication issues on rollforward: app targets 2.0
carries OOB copy of Vectors with higher version than 2.1, rolls forward to 2.1 and host will
use the OOB copy, no longer unifying to the types in corelib.

Master branch version of #29182.

We should only merge in master if we're certain we're taking the release side of the fix.

…eapp2.0

System.Numerics.Vectors was made inbox in netcoreapp2.0, we were still allowing distribution
in the package, however the package was applying the netstandard2.0 implementation to
netcoreapp2.0.

Now that we've disabled oobing the netcoreapp2.1 build (since many types were moved into
corelib) it no longer makes sense for us to mantain the ability to oob the netcoreapp2.0 build.

Doing so not only degrades the inbox version (by not using the framework's MathF
implementation) but also creates type-unfication issues on rollforward: app targets 2.0
carries OOB copy of Vectors with higher version than 2.1, rolls forward to 2.1 and host will
use the OOB copy, no longer unifying to the types in corelib.
@ericstj ericstj added area-System.Numerics packaging Related to packaging labels Apr 18, 2018
@ericstj ericstj self-assigned this Apr 18, 2018
@ericstj ericstj requested a review from weshaggard April 18, 2018 16:51
@ericstj
Copy link
Copy Markdown
Member Author

ericstj commented Apr 18, 2018

Test Linux x64 Release Build

@ericstj ericstj added the * NO MERGE * The PR is not ready for merge yet (see discussion for detailed reasons) label Apr 18, 2018
@ericstj
Copy link
Copy Markdown
Member Author

ericstj commented Apr 18, 2018

Waiting on approval for release side of changes before merging.

<IsPartialFacadeAssembly Condition="'$(IsTargetingNetFx)'=='true'">true</IsPartialFacadeAssembly>
<DefineConstants Condition="'$(IsTargetingNetCoreApp)'=='true'">$(DefineConstants);netcoreapp</DefineConstants>
<IsPartialFacadeAssembly Condition="'$(TargetsNetFx)'=='true' AND '$(TargetGroup)' != 'net45'">true</IsPartialFacadeAssembly>
<DefineConstants Condition="'$(TargetsNetCoreApp)'=='true' OR '$(TargetsUap)' == 'true'">$(DefineConstants);HAS_SPAN</DefineConstants>
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why was this change to rename the constant necessary? Is keeping it netcoreapp semantically incorrect now?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, it was semantically incorrect before because it was set for both netcoreapp and uap.

@ericstj ericstj removed the * NO MERGE * The PR is not ready for merge yet (see discussion for detailed reasons) label Apr 20, 2018
@ericstj ericstj merged commit c3c2faa into dotnet:master Apr 20, 2018
@karelz karelz added this to the 2.2.0 milestone Apr 21, 2018
picenka21 pushed a commit to picenka21/runtime that referenced this pull request Feb 18, 2022
…eapp2.0 (dotnet/corefx#29183)

System.Numerics.Vectors was made inbox in netcoreapp2.0, we were still allowing distribution
in the package, however the package was applying the netstandard2.0 implementation to
netcoreapp2.0.

Now that we've disabled oobing the netcoreapp2.1 build (since many types were moved into
corelib) it no longer makes sense for us to mantain the ability to oob the netcoreapp2.0 build.

Doing so not only degrades the inbox version (by not using the framework's MathF
implementation) but also creates type-unfication issues on rollforward: app targets 2.0
carries OOB copy of Vectors with higher version than 2.1, rolls forward to 2.1 and host will
use the OOB copy, no longer unifying to the types in corelib.

Commit migrated from dotnet/corefx@c3c2faa
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants