Age | Commit message (Collapse) | Author |
|
|
|
|
|
These are now redundant to the property defined in src\<lib>\dir.props.
|
|
|
|
Now that we have stable packages for our current versions we need to
bump the 3rd portion (bugfix) to represent code-changes without API
additions.
|
|
Fixes https://github.com/dotnet/corefx/issues/5707
We are changing the .NET packages to no longer use the ‘dotnet’, ‘dotnet5.x’, and ‘dnxcore50’ monikers. This is thee first stage of the change for dotnet->netstandard.
The replacements are as follows
Old moniker | New moniker
----------------- | ------------------
dotnet5.x | netstandard1.y (where y = x -1)
DNXCore50 | netstandardapp1.5
dotnet | netstandard1.3
To prepare for this change you can do the following to your project.json. This change will require a recent build of NuGet or dotnet.exe and can be done prior to consuming the packages with the breaking change. These packages will not work with DNX.
For a project targeting dotnet5.6
```
"frameworks": {
"netstandard1.5": {
"imports": [ "dotnet5.6" ]
}
},
```
For a project targeting dnxcore50
```
"frameworks": {
"netstandardapp1.5": {
"imports": [ "dnxcore50", "portable-net45+win8" ]
}
},
```
[tfs-changeset: 1578321]
|
|
|
|
|
|
control and add to gitignore.
A few new references to pick up changes that happened over time.
|
|
We don't want reference assemblies to have an interop dependency.
This is because we don't like the shape of the interop contract and
plan to split it up such that future platforms might not have to
implement the entire set of API (eg: COM related APIs).
Both of these contracts were referencing Interop just for SafeHandle.
Since that's already been pushed down we'll move these to use
System.Runtime.Handles instead.
@BartonJS already fixed a crypto refefrence dependency on interop
(thanks) which leaves us with two remaining dependencies in refs:
System.IO.MemoryMappedFiles
System.IO.UnmanagedMemoryStream
Both of those dependencies exist due to SafeBuffer. @yizhang82
is looking into refactoring interop in order to split some of these
types out.
|
|
Previously generations were strictly calculated. We had a set
of seed assemblies which defined generation boundaries based
on where they were supported. Eg: System.Runtime 4.0.0.0 was
supported inbox in Net45, 4.0.10.0 was supported inbox in
Net451, we could not OOB 4.0.0.0 to Net451 due to unification
so that defined a generation boundary.
All non-seed assemblies got the maximum generation
of all their transitive dependencies.
This worked fine, but created a confusing picture when
looking at the packages. New contracts that were only
implemented in DNXCore50 and Net46 had a reference assembly
that claimed to be dotnet5.1 even though they weren't
supported by any framework that was exclusive to 5.1-5.3.
It also meant that targeting a generation required that
someone use guardrails to ensure that they'd actually have
an implementation on any framework targeting that generation.
Without guardrails they might produce an assembly that would
not run on any framework of the generation it claimed.
This change raises the generation of all the reference assemblies
to a minimum that supports any implementation. This makes it
clear which generation of frameworks support the package,
it also lets someone target that generation without using guardrails
and guarantees that they'll at least run somewhere.
[tfs-changeset: 1543192]
|
|
We need a new DNX to understand the latest packages.
We also need to move all "dotnet" projects to use dotnetX.X (generations)
now that the packages no longer have "dotnet" assets.
The new version of DNX dropped support for the aspnetcore
so I needed to update a few projects/packages that depended
on old package versions that had this moniker.
[tfs-changeset: 1540388]
|
|
All projects that previously used dotnet have been updated to specify the appropriate generation of the surface area they depend on or in the case of desktop inbox contracts, the generation that includes the set of platforms they can support.
Now all packages contain all generations of API that they have ever shipped.
In doing this I needed to change how we determine package version. Before we ensured all assemblies would have the same version and used that. Now we choose the max.
Additionally I needed to change how we chose which asset to use for netcore50 when the dotnet asset was obscured by a placeholder for a previous netcore release (eg System.Runtime will have placeholders for Win8 since it was inbox there). To do this I wrote a task that uses nuget to evaluate the package assets with and without the placeholders. In this way it chooses the "best" dotnet implementation and reference assembly to use for netcore50.
This new model made my old MSBuild-based validation impossible to carry forward, so I wrote better validation in a task that actually uses Nuget's asset resolution algorithm. This uncovered many existing issues in packages that I have cleaned up. The validation algorithm could use some polish but its working now. Perf is not great, package build went from 15s to ~2 minutes. I'll work on this some more by making it incremental (input: nuspec, output: marker created on success). Profiling shows that most of the time is spent in calling the nuget APIs. I'll see if I can reduce some of this with caching for things that don't change (eg: RID graph). Ultimately I think its a reasonable tradeoff for the types of bugs I can find this way.
[tfs-changeset: 1539216]
|
|
The corefx build used an older beta5 version of DNX which hardcoded the path to bash in dnu, breaking the build on FreeBSD.
Updating DNX to the latest "stable" beta7 release fixes this.
After updating I noticed a few test projects didn't build anymore as they were missing some dependencies in project.json, added those.
Fixes #3173
|
|
This change updates the assembly versions of all of the corefx assemblies
as needed after we shipped stable versions. Assemblies with API differences
get a minor version bump. Assemblies with only bugfixes get a build version
bump.
In order to facilitate this I had to update the reference assemblies, so I took
the opportunity to port them all to the open.
[tfs-changeset: 1514419]
|