| Age | Commit message (Collapse) | Author |
|---|
|
Fixes https://github.com/dotnet/runtime/issues/73463. Tested locally just now.
|
|
* Consume renamed ApiCompat.Task package
|
|
Based on the discussed in https://github.com/open-telemetry/opentelemetry-dotnet/issues/3448, we are now emitting a warning instead of an error on unsupported target frameworks. We still explicitly indicate that this is an unsupported scenario but don't actively block consumers anymore and also indicate how to suppress the warning.
|
|
* Fix typos
* Fix typo: seperate -> separate
* Rename ApplicationNameSetFromArgument
* Update src/coreclr/vm/methodtablebuilder.cpp
* Update docs/coding-guidelines/clr-code-guide.md
Co-authored-by: Dan Moseley <danmose@microsoft.com>
* Update src/mono/mono/tests/verifier/make_tests.sh
Co-authored-by: Dan Moseley <danmose@microsoft.com>
Co-authored-by: Jan Kotas <jkotas@microsoft.com>
|
|
* Define convention to include analyzers in ref pack
Fixes https://github.com/dotnet/runtime/issues/61321
Until now we required source libraries to define ProjectReferences when
an analyzer should be part of the shared framework. That strategy causes
analyzer projects to leak into the ProjectReference closure and by that
into a solution file.
As an example:
When another library references the source library that references the
analyzer, the analyzer is part of the dependency closure even though it
might not be required.
This change makes it possible to define the shared framework analyzer
projects in the NetCoreAppLibrary.props file for both the .NETCoreApp,
and the AspNetCoreApp shared framework.
Out-of-band projects which ship analyzers inside their produced package,
continue to reference the analyzers via the `AnalyzerProject` item.
* Use AnalyzerReference consistently
* Don't reference analyzer when its packaged
* Fix P2P reference
* Fix multi target roslyn component target condition
|
|
|
|
* Only add placeholder pkg file if folder is empty
Originally reported in https://github.com/dotnet/runtime/issues/63413,
placeholder files are added unconditionally by the .NETStandard compat
error packaging infrastructure, even if the
buildTransitive/$(SupportedTFM) folder isn't empty.
That hinders our libraries to package their own set of buildTransitive
props and targets files for the supported set of tfms.
This change makes sure that placeholder files are added only if no None
or Content items are declared that point to the same package folder.
Adding documentation that explains the .NETStandard compatibility
packaging infrasturcture and how to correctly package hand-authored
msbuild files next to the generated targets files.
* Fix NETStandardCompatError empty cases
* Update packaging.targets
|
|
|
|
* Don't use Targets* helper properties in libs projs
This change makes it possible to migrate 200+ (ref+src) projects to use
TargetFramework instead of TargetFrameworks which avoids the additional
outer build evaluation and invocation which ultimately makes the overall
build faster.
Targets* properties (i.e. TargetsWindows, TargetsAnyOS, TargetsUnix,
etc.) rely on the TargetFramework property which usually are set
inside a project. The TargetFramework property is only
available before a project specifies it if it's explicitly set in a props
file or if the project is cross-targeting and the outer-build dispatches
into the inner-build. During the dispatch, the TargetFramework property
is passed in as a global property.
Until now that behavior wasn't a problem because every libraries project
cross-targeted (by setting the TargetFrameworks property) even though
many only include a single TargetFramework (i.e. NetCoreAppCurrent).
To allow projects to use the TargetFramework property instead of
TargetFrameworks, the Targets* helper properties can't be calculated
anymore early in a props file as the TargetFramework property isn't set
at that time.
In general, the guidance by the SDK/msbuild team is to not read from the
TargetFramework property before the project sets it
(in a property group). That effectively means that the TargetFramework
property shouldn't be used in props files at all.
Therefore these helper properties can't be used anymore for property
conditions and I'm replacing their usage with TargetPlatformIdentifier
comparisons for both properties and items.
In nearly all cases, the Targets* helper properties can be replaced with
TargetPlatformIdentifier checks on items and in the few cases where
TargetsUnix or TargetsLinux marks multiple tfms as compatible, the exact
tfms must be used instead for the TargetPlatformIdentifier comparison.
Whenever a project needs to condition properties on the platform, I'm
first setting the TargetPlatformIdentifier the same way the SDK sets it
so that the SDK later doesn't need to set it again to avoid the
additional expensive msbuild function call.
* Use TargetFramework singular to avoid outer builds
Use TargetFramework instead of TargetFrameworks property whenever a
projects only targets a single target framework. This avoid unnecessary
outer builds and evaluations and makes the build faster.
|
|
* Clean-up DllImportGenerator packaging infra
Most of what DllImportGenerator was trying to achieve via targets or by setting common packaging properties is already handled by libraries common packaging infrastructure (packaging.props) which is imported when a project sets `IsPackable=true`.
|
|
* Remove .NETStandard runtime implementations
Remove the remaining ten .NETStandard runtime specific implementations.
For reasoning please see https://github.com/dotnet/runtime/issues/64536.
* Remove infra support for NS platform specific tfms
Also cleaning-up some logic and stop disabling AppendTargetFramework.
|
|
* Respond to feedback in GenerateMultiTargetRoslynComponentTargetsFile
Two small follow up changes from #58446
- Fix a type-o that breaks incremental build. Forgot to use MSBuild property syntax
- Instead of having the infrastructure hard-code removing 'Abstractions', packages can set their own Disable source gen property name.
* PR feedback
|
|
|
|
* Port changes from 6.0 for future servicing releases into main
* Include another change needed for servicing
* PR Feedback
|
|
doesnot match assembly version shipped in 6.0.0 (#59583)
* throw errow if assembly version in the ref pack doesnot match last released version
* Fix the condition
* Update eng/Versions.props
Co-authored-by: Viktor Hofer <viktor.hofer@microsoft.com>
Co-authored-by: Anirudh Agnihotry <anagniho@microsoft.com>
Co-authored-by: Anirudh Agnihotry <anirudhagnihotry098@gmail.com>
Co-authored-by: Viktor Hofer <viktor.hofer@microsoft.com>
|
|
(#59388)
* fix the package version for non-shipping package
* use version prefix
Co-authored-by: Anirudh Agnihotry <anagniho@microsoft.com>
|
|
(#58446)
* Multi-target LoggerMessageGenerator between Roslyn v3.11 and v4.0
* Include a .targets file in NuGet packages which will select the correct analyzer assembly depending on which Roslyn version will be used to compile.
* Multi-target JsonSourceGenerator between Roslyn v3.11 and v4.0
* Fix restore
* Update NuGet package MSBuild logic to detect when SupportsRoslynComponentVersioning is not available, and use the lowest analyzer available.
* Handle non-SDK projects by running after ResolveNuGetPackageAssets
* Respond to PR feedback
- Name .cs and .csproj files with Roslyn in the name
- Upgrade to Roslyn 3.11 so IsExplicitlyNamedTupleElement API is available
- Fix some references to the test projects
- Fix incremental pack of the analyzer targets
|
|
* Simplfy .NETFramework tfms
Libraries which target .NET Framework usually have rid agnostic tfms,
i.e. net461. If the library targets netstandard2.0-windows as well,
the .NET Framework tfm must be rid specific, as rid specific
.NET Framework apps would otherwise pick the .NETStandard asset over
the .NETFramework one (based on the RID compatibility rules)
There is yet another reason that requires .NETFramework tfms to be RID
specific, which is when a project P2Ps other projects which are
rid-specific. Without the RID specific .NETFramework tfm, a compatible
.NETStandard asset would be picked instead.
NuGet doesn't support setting a TargetPlatform in the TargetFramework
alias when targeting .NETFramework or .NETStandard. Any such tfms in
dotnet/runtime are currently leveraging a hack that strips the
TargetPlatform / TargetFrameworkSuffix away during restore and packaging
(as NuGet Pack uses the project.assets.json file).
As NuGet will likely never support RID specific .NETFramework tfm
aliases, the distinction between a RID specific and a RID agnostic
.NETFramework tfm is unnecessary.
Remove all "TargetFrameworkSuffixes" / TargetPlatforms / RIDs
(whatever you would like to call them) from .NETFramework tfms and let
the packaging targets handle the cases where a RID specific asset is
required in the package.
Explictly don't set TargetsWindows to true for .NETFramework builds as
the Targets* properties are infered from the platform / suffix and
many projects make the assumption that net461
(without the "-windows" part) doesn't set TargetsWindows=true.
Fixes https://github.com/dotnet/runtime/issues/58495
* Warn on .NETFramework duplicate runtime assets
* Ignore .NEtFramework non Windows and non empty RIDs
Also cleaning up the packaging.targets file and removing
the ExcludeFromPackage option which isn't needed anymore as
target frameworks aren't excluded from packages produced in
dotnet/runtime anymore.
|
|
* Remove EOL tfms and upgrade to net7.0
* Make linker tests net7 aware
Make installer tests run on net7.0
Don't attempt to use live apphost
Fix payloads
Regenerate test files
Fix package testing
|
|
|
|
|
|
|
|
Also make sure that the documentation file is placed next to the
reference assembly if such is included as part of a ProjectReference.
Also move the IsAspNetCore property into packaging.targets as it's not
needed by the binplacing system anymore.
|
|
Use ProjectReferences to compose the aspnetcore tranport package.
Avoid binplacing and with that unnecessary copies which overall
simplifies the infrastructure and allows to add additional transport
packages without creating a binplace configuration for each.
This also makes sure that the dependencies are compatible with the
package's tfm.
|
|
* automatically update the assembly version
* address feedback
* move IsAspNetCoreApp to packaging.targets
* make assemblyintef pack private, update header and instructions on building the package in servicing
* fixes the allconfig leg
* update the docs
* Update docs/project/library-servicing.md
Co-authored-by: Viktor Hofer <viktor.hofer@microsoft.com>
Co-authored-by: Viktor Hofer <viktor.hofer@microsoft.com>
|
|
* Make sure rid specific libs projs get packaged
RID specific runtime.*.runtime.native.System.IO.Ports projects weren't
packaged because the GeneratePackageOnBuild property wasn't set to true
for them. The property was only true during an allconfigurations build.
As these projects are only built outside of an allconfigurations build,
the GeneratePackageOnBuild property needs to account for such as well.
Also updating the NoTargets Sdk to clean the rid specific package up.
Moving the GeneratePackageOnBuild logic into a props file and set it to
false during servicing (or runtimelab) so that devs can set the property
during servicing directly in the project file if a project should be
packaged.
* Remove the GeneratePackage property
That property was intended to enabled incremental servicing but with
now using the NuGet Pack task we can just make use of the publicl
available GeneratePackageOnBuild property.
* Fix IsPackable setting
|
|
IO.Ports packages. (#57118)
* Fix analyzer and docs file packaging
This commit fixes analyzers which were dropped from the package during
the clean-up of pkgprojs and missing documentation files.
1. Analyzers were dropped from the package because the BeforePack
hook wasn't respected. This happens when the NuGet Pack nuget package
is referenced which then gets imported before the packaging.targets
file. The BeforePack property needs to be set in a props file if
NuGet's targets file isn't used from the SDK but from its package.
2. Documentation files were dropped as the
DefaultAllowedOutputExtensionsInPackageBuildOutputFolder property
didn't include the .xml extension.
* Don't overbuild runtime native IO packages
|
|
* Automatically generate .NETStandard compat errors
Before this change, a project had to explicitly add a
NETStandardCompatError item to declare that a given tfm range
shouldn't be supported when packaging.
Automate this logic so that projects don't need to specify the item
themselves anymore. Instead condition the NETStandardCompatError target
calcuation logic on the existence of both a .NETStandard and a
.NETCoreApp tfm.
* Update Directory.Build.targets
* Update packaging.targets
* Update eng/packaging.targets
Co-authored-by: Santiago Fernandez Madero <safern@microsoft.com>
Co-authored-by: Santiago Fernandez Madero <safern@microsoft.com>
|
|
* Clean-up pkgproj leftovers in libs and apply fixes
Remove any pkgproj infrastructure that was only used by src/libraries
(which is the majority). Delete the packageindex *YAY*.
Update the documentation that covered the packageindex and the pkgprojs.
Avoid any incremental builds during packaging by removing
libraries-packages.proj and use src.proj for packaging instead. Make use
of the `GeneratePackageOnBuild` property to build package during the
allconfigurations without requiring a different entry target.
Fix the addition of the DocumentationFile during packaging when
`GeneratePackageOnBuid` is used by hooking onto the
`DocumentationProjectOutputGroup` that NuGet uses and replacing the
generated documentation file with the one that comes via the
intellisense package.
Also introduce a property to choose the generated documentation file
over the one from the intellisense package:
<UseIntellisenseDocumentationFile>false</UseIntellisenseDocumentationFile>
Removing a few leftover PackageDescription properties from the projects'
Directory.Build.props file.
Cleaning up properties in Directory.Build.props & Directory.Build.targets
files.
* Actually run packaging during the allconfigurations build
* Update docs
* make runtime specific pkgs non packable
* io.ports native pkg fixes
|
|
* Runtime specific and doc file packaging fixes
* Replace all remaining pkgprojs with NuGet Pack task
* Avoid NuGet/Home/issues/10368
* Update PackageValidation package to latest
|
|
* Fix build error when building some packages
* Actually move declaration to Directory.Build.targets as they should be used in other scenarios
|
|
* Convert AspNetCore transport pkgproj to Pack task
Converting the Microsoft.AspNetCore.Internal.Transport package to a proj
file which uses the NuGet Pack task.
Also moving some more packaging related targets into packaging.targets.
* Update Microsoft.AspNetCore.Internal.Transport.proj
|
|
symbols. (#54250)
* add infra for adding ref and runtime assemblies
delete the project
add a comment
move the warning disable to cenral location
moving props/targets to packaging.props and packaging.targets
use intellisense package for ref and runtime xml files
add comments, flag for ref assemblies, remove xml from runtimes, use outputItem to get the reference assembly
addressing some more feedback
remove ref assemblies
add suppression file and update package validatio
* move PackageValidationBaselineVersion to packaging.targets
* update the package validation version
|
|
(#46447)
* More packaging cleanup
* Add incremental package servicing throughout the repo
* Update dependencies to 6.0.0-beta.20630.3
|
|
* Set IsPackable and validate PackageDescription
|
|
Replace them with the current URL after the redirect.
Similar to https://github.com/dotnet/runtime/pull/2063.
Co-authored-by: Steve Pfister <steve.pfister@microsoft.com>
|
|
* Support dotnet pack on libs src project
* Update eng/packaging.targets
Co-authored-by: Santiago Fernandez Madero <safern@microsoft.com>
|
|
|
|
|
|
* Update dependencies from https://github.com/microsoft/vstest build 20191202-02
- Microsoft.NET.Test.Sdk - 16.5.0-preview-20191202-02
* Update dependencies from https://github.com/dotnet/arcade build 20191203.17
- Microsoft.DotNet.XUnitExtensions - 5.0.0-beta.19603.17
- Microsoft.DotNet.XUnitConsoleRunner - 2.5.1-beta.19603.17
- Microsoft.DotNet.VersionTools.Tasks - 5.0.0-beta.19603.17
- Microsoft.DotNet.ApiCompat - 5.0.0-beta.19603.17
- Microsoft.DotNet.Arcade.Sdk - 5.0.0-beta.19603.17
- Microsoft.DotNet.Build.Tasks.Configuration - 5.0.0-beta.19603.17
- Microsoft.DotNet.Build.Tasks.Feed - 5.0.0-beta.19603.17
- Microsoft.DotNet.Build.Tasks.Packaging - 5.0.0-beta.19603.17
- Microsoft.DotNet.Build.Tasks.SharedFramework.Sdk - 5.0.0-beta.19603.17
- Microsoft.DotNet.CodeAnalysis - 5.0.0-beta.19603.17
- Microsoft.DotNet.GenAPI - 5.0.0-beta.19603.17
- Microsoft.DotNet.GenFacades - 5.0.0-beta.19603.17
- Microsoft.DotNet.Helix.Sdk - 5.0.0-beta.19603.17
- Microsoft.DotNet.RemoteExecutor - 5.0.0-beta.19603.17
* Remove manually specified package test TFMs
|
|
(dotnet/corefx#42491)
Commit migrated from https://github.com/dotnet/corefx/commit/ab01852685e659a685af2ace33af5b3cefdf8430
|
|
* Prepare corefx for repo consolidation into runtime
Commit migrated from https://github.com/dotnet/corefx/commit/e160dd972d958fbe9594dc1001da4d1b94bba949
|
