Age | Commit message (Collapse) | Author |
|
(#17259)
* Only include symbols / src in transport packages, also fix pre-existing typo
* PR feedback
|
|
(#16838)
|
|
This turns the package build back on and fixes all packages so that
they build.
There is still work to do to fix dependencies.
|
|
|
|
This is consistent with the branding of the release.
|
|
|
|
Set up a separate destination for package contents for NETCoreApp since
it won't necessarily be everything that we build.
Libraries were determined as follows:
1. If its currently in NETStandard.Library its in.
2. If it was a ref in NETCoreApp before its in.
3. If its part of the reference closure for 1 or 2 its in.
4. If it was a lib only in NETCoreApp its in, but only lib.
5. If its part of the lib closure for 1-4 its in, but only lib.
|
|
Fixes #13934
The XAML designer needs to classify packages as safe to share and
avoid reload.
This is required to have reasonable performance in the designer, because
reloading the entire framework is currently quite expensive due to the
architecture of the designer and the fact that its running on Desktop.
The designer cannot reuse all NuGet assemblies since some may
register things in their static constructors (EG: dependency properties)
that need to be re-registered as the designer context is refreshed.
None of our assemblies do this so we're an easy target for optimization.
For now we'll add a marker that helps the designer identify our packages
for this optimization.
In the future the plan is to remove this once the designer can be
refactored to have a NETCore component that loads the user code
and is fast to restart/reload.
|
|
We were inferring NETStandard version supported from desktop versions
which caused us to think we needed a higher versioned NETStandard
implementation. Suppress this inferrence.
After suppressing this we triggered another check which said that we
should make the ref a higher NETStandard version since it didn't have
any implementations at that version (we excluded the desktop ones).
Supress this as well. These checks will soon be irrelevant after our
refactoring effort for ns2.0.
|
|
* Add version file to packages
* Remove SyncInfoFile entry, add comment, fix spacing -- PR feedback
* Fix spacing
* fix typo
|
|
PKGProj build depends on harvesting dlls from previously shipped
packages. Rather than force every package in the repo to declare the
version of the last-shipped package in project.json we have a central
copy listing everything. The problem here is that if this project isn't
restored we'll just silently drop assets from the package, which can
cause tests to fail or package build to fail validation. This also
causes a problem for folks that want to just sync the repo and build
a single project without doing a full restore.
To ensure that we'll always have the baseline restored I set this as the
ProjectJson for the pkgproj and ensure that we run restore during
package build.
|
|
|
|
|
|
|
|
|
|
|
|
This moves to a central versioning scheme for all packages that is tied
to the product release. 1.1 will include packages all with a common
version.
|
|
|
|
to support new Reflection refactoring (#10745)
* uap10.1: moving some APIs from system.io and system.reflection.primitives to corelib
* Revert "uap10.1: moving some APIs from system.io and system.reflection.primitives to corelib"
This reverts commit 0f285f009f4be35a2875bdd535032b14304469b4.
* Moving some types/APIs from S.IO and S.Reflection.Primitives to S.P.CoreLib, to support new Reflection refactoring
|
|
|
|
This needs to be updated since I bumped the version of the lineup
package with https://github.com/dotnet/corefx/commit/b2d61e78e904b574b2e7fde61d82b29a0ea6c767
|
|
NuGet has a limit of 20 characters maximum for the "special version part". In local builds this limit wasn't met because the version is "XXXXX-X", but in the build pipeline it's "XXXXX-XX". The extra digit brought it to 21 characters.
|
|
|
|
|
|
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.
|
|
|
|
This is a 1.1.0-beta specific link for relnotes.
|
|
The long term plan is to move our packages versions up and the
prerelease tag back down to something like -beta, but for now we just
need to pick something that isn't RC3 as that's what
the release/1.0.0 branches are using.
Doing this gives us time to do the right thing without having version
clashes on myget.
[tfs-changeset: 1606983]
|
|
This enables the package baseline to live in the repo that builds the
packages, avoiding a roundtrip to buildtools every time we update
package versions.
|
|
This change adds publish-packages scripts for publishing packages to the
specified location (currently all that's supported is Azure blob storage).
Removed BuildValues.props as it's no longer needed after commit d46ecb5.
Fixed up package output directory, placing built packages under a
configuration group subdirectory.
|
|
Packages with ref and lib list all their dependencies
in a single section for that target framework.
This creates a couple problems:
1. Folks end up taking a dependency on the fact that a package
happens to use another package in its implementation.
2. For packages that have multiple implementations for the
same TFM and different RID all dependencies appear in the
same section even though some may be RID specific.
Those RID speicific dependencies will compatibility
errors during restore since the packages won't be supported
on all RIDs.
In lieu of the NuGet feature to represent RID-specific
dependencies https://github.com/nuget/home/issues/1660
we can at least suppress the compatibility error by
excluding these implementation specific depdencies from
compile.
Further details are here:
https://github.com/dotnet/buildtools/commit/d40435b1c460416768cc53a27091e57d948be171#diff-abe065d40d7c72dbdc1ad1957148d23fR14
[tfs-changeset: 1581170]
|
|
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]
|
|
[tfs-changeset: 1569920]
|