* Target NetFrameworkCurrent in tests and remove old mentions
... of previous .NET Framework versions in docs / tests.
NetFrameworkMinimum (net462) -> NetFrameworkCurrent (net481) so that we can
start consuming xunit v3 which requires at least net472. Use
NetFrameworkCurrent as the actual runtime that is then used is
.NET Framework 4.8.1 anyway (innerloop & CI).
* Revert source-generator ref assembly change
* Try to fix VoidMainWithExitCodeApp test
* Fix typo
---------
Co-authored-by: Alexander Köplinger <alex.koeplinger@outlook.com>
* Update dotnet10 feeds
* Update hardcoded old TFM values
* More hardcode updates and TFM checks
* Updates and delete duplicate file in Bcl.Numerics
* Linker stays on net9.0
* Fix .NET SDK max supported version
* Update apicompat sfx apicompat baseline file
* Update Microsoft.NET.WebAssembly.Threading APICompat settings
* Fix DiagnosticSource build
* Update SDK to RC1 for needed GetAlternateLookup API
to be able to build System.Text.Json on net9.0.
* Fix APICompat runtime regex pattern
* Suppress Bcl.Memory compatibility error for dropped framework
* Fix BinaryFormatter tests regex pattern for version subsitution
* Update BinaryFormatterTests.cs
* Pin SdkVersionForWorkloadTesting to the version in global.json
* Treat net9 and net10 as current for now
* Bump MicrosoftDotNetILCompilerVersion
* Update BinaryFormatterTests.cs
* Update System.Resources.Extensions
* Update AutoImports as well
* Fix ImporterTests.cs
* Block failing SignalRClientTests
* Update XmlSerialzation Schema Import tests.
* Update Versions.props
* Update CompatibilitySuppressions.xml for System.Numerics.Tensors
* Don't set EnableDefaultCompileItems, it doesn't work since we set EnableDefaultItems=false higher up
* Update regex in legacy BinaryFormatterTests.cs too
* Hardcode BinaryFormatter test assembly version to 9.0
This allows us to not change the majority of the tests
* Fix typo
* Fix issue in Microsoft.NET.Workload.Mono.Toolchain.Current.Manifest.pkgproj
* Replace ForceNet8Current in a few more places
* Fix wasi workload
* Fix TreatAsCurrent for 10.0
* Add net9 workload manifests
* Update PackageId in icrosoft.NET.Runtime.WebAssembly.Templates.csproj
* Update ApiCompatBaseline.NetCoreAppLatestStable.xml
Changes from https://github.com/dotnet/runtime/pull/107758
* Remove duplicate dotnet10 feeds from nuget.config
* Update Versions.props
* Fake SDK band version for now
* Update Versions.props
* Update the SDK band versions for real
* Update the dotnet/sdk dependencies
* Update emsdk to net10 workloads
* Install a 9.0 runtime for workload tests too
* Update the compat tasks
* Merge in changes from net10-manifests
* Tmp: Trying out @am11's branch.
* Tmp2: Trying out @am11's branch.
* Tmp3: Replace the last usage of main in clone action.
* Update eng/pipelines/coreclr/templates/build-perf-bdn-app.yml
Co-authored-by: Adeel Mujahid <3840695+am11@users.noreply.github.com>
* Update eng/pipelines/coreclr/templates/perf-job.yml
Co-authored-by: Adeel Mujahid <3840695+am11@users.noreply.github.com>
* Update eng/pipelines/runtime-wasm-perf.yml
Co-authored-by: Adeel Mujahid <3840695+am11@users.noreply.github.com>
---------
Co-authored-by: Larry Ewing <lewing@microsoft.com>
Co-authored-by: Jackson Schuster <36744439+jtschuster@users.noreply.github.com>
Co-authored-by: Alexander Köplinger <alex.koeplinger@outlook.com>
Co-authored-by: Ilona Tomkowicz <itomkowicz@microsoft.com>
Co-authored-by: Steve Molloy <smolloy@microsoft.com>
Co-authored-by: Adeel Mujahid <3840695+am11@users.noreply.github.com>
* Avoid package dependencies on libraries in the shared framework
We can avoid these dependencies since we can count on the library being
part of the shared framework. Fewer dependencies means less packages
downloaded, less for customers to service, less copied into the output
directory when serviced.
* Add warning code.
* Address feedback
* Do not separate header comments from function definitions
Separating them with a space defeats a VS feature that shows
the header comments when you hover over a function in code.
* Remove // static as well
* Update link to dotnet-format tool
* It now lives in dotnet/sdk
* Link to official docs instead
Co-authored-by: Jan Kotas <jkotas@microsoft.com>
---------
Co-authored-by: Jan Kotas <jkotas@microsoft.com>
We're no longer using the separate dotnet-format tool since it is integrated into the dotnet SDK now.
With the move to the SDK the options changed a bit so we now need to use the `whitespace` format command so we can continue using the `--folder` option: https://github.com/dotnet/format/issues/1385
To run not just whitespace but code style formatters as well we'd need a workspace context (i.e. pass the .csproj to dotnet format), but inferring that from just the changed file list is hard.
Change the mono build to require C11 (with gnu extensions on gcc/clang platforms).
* Change `g_static_assert` to be `_Static_assert` or `static_assert` as apropriate.
* Change `_DN_STATIC_ASSERT` to be `static_assert`
* Add static asserts in `jiterp.c` when it casts between `T*` and `atomic_T*`
* Add C11 guidance to the mono coding guide doc
Contributes to #90404
---
* Bump mono to -std=gnu99; use static_assert
* don't fall back to runtime checks for g_static_assert
* fix static assert that wasn't a constant expression
* use static_assert in shared containers
* bump C standard in offsets-tool.py
* use _Static_assert before C23
Dont' include assert.h in glib.h because some of our older 3P code includes assert.h on its own and there are conflicts
* use CMAKE_C_STANDARD and related properties
* jiterp: static_assert that atomic ops are (less likely) to go wrong
Not every C implementation guarantees that atomic operations on arbitrary types are lock free. So for example, casting between atomic_ushort* and uint16_t* might not actually be ok to do. We can't assert that they're inter-castable, but at least assert that they're the same size and that atomic_ushort is always lock-free. There might still be restrictions (for example atomic_ushort might have to be aligned differently) but this should at least catch obvious data corruption.
* Add C11 guidance to the Mono coding guide
* jiterp: long is 32-bits on wasm; use llong
* Use analyzers from targeting pack for NetCoreAppCurrent
Fixes that analyzer failures didn't show-up in #74897
Add analyzers to the frameworklist that OOB projects in src/libraries
use, and only auto ProjectReference the analyzers in generators.targets
when not using the analyzers from the targeting pack.
Also move the generator projects related code into a separate file.
Continuation of https://github.com/dotnet/runtime/pull/75093
* Fix project build
* Add missing reference to Regex tests
* Add missing generators for netfx build
* Fix paht in test project
* Fix typo
* Disable runtime marshalling for SharedTypes.csproj
* Disable runtime marshalling for NativeExports.csproj
* Try to untangle the rid calculation.
* Ignore __portableOS.
* Add back musl detection.
* Try fix AnyOS tests.
* Try fix coreclr linux_musl_arm64 job.
* src/tests/build.proj: use PackageRID for restore.
* Use RuntimeOS as an override for _packageOS.
* Remove (probably) out-dated override for non-portable ToolsRID.
* CI cross-builds for linux-musl use linux.
* Add missing arch to rid.
* Try simplified ToolsRID.
* Update comments.
* Rename OutputRid to OutputRID.
* Tweak comment.
* Move TargetsLinux{Bionic,Musl} with the other Targets properties.
* Don't use RuntimeOS for PackageRID for CrossBuilds.
* Move RuntimeOS condition to ToolsRID assignment.
* Clean up a few things.
* Fix broken Condition.
* Try fix the linux-bionic build.
* Try fix the linux-bionic build, part II.
* Try fix the linux-bionic build, part III.
* Fix PackageRID.
* Use RuntimeOS as _packageOS override.
* Remove RuntimeOS.
* Fix '-os linux-musl' mapping.
* Clean up .
* Rename __PortableOS to __PortableTargetOS.
* Extend comments.
* Extend OutputRID comment too.
* build.sh: include linux-bionic, linux-musl in usage.
* SourceBuild.props: no need to pass RuntimeOS. Only set ToolsOS, PackageOS when RuntimeOS is not empty.
* Fix comment.
* linux-bionic doesn't get built on linux-bionic.
* Unconditionally assign TargetsLinuxBionic/TargetsLinuxMusl.
* Remove SkipInferTargetOSName.
Follow-up on #32451
Follow-up on #80074
In #43651, the "Windows" OS name was lowercased to achieve target frameworks with RIDs in them. At that time, the original plan was to lowercase all TargetOS values but that had to be cut because of resources. This PR finishes that and updates build systems, YML, markdowns and managed components.
To not break existing developer workflows, the passed-in -os value is automatically lower-cased in the script entry points and validated in the msbuild entry point.
* Use shipping runtime.json for RID targeting
- Use the shipping runtime.json file to target RIDs when building
instead of the custom OSGroups.json which only contained a subset of
the available rids.
- To facilitate that, lower-case the existing platforms in the target
frameworks strings which is the expected format anyway by the SDK and
msbuild. This will eventually make it possible to bring some of the
custom build infrastructure back into the SDK.
- Remove a few outdated code pieces and update docs.
d3af4921f3 made it possible to reference
and package an analyzer via the same msbuild item by setting custom
metadata.
While reviewing other places that could use the AnalyzerReference item,
I realized that using this custom item doesn't provide much value and
creates an artificial difference to the rest of the stack and our customers
[as we don't adhere to our own documentation](https://devblogs.microsoft.com/dotnet/introducing-c-source-generators/#hello-world-source-generator-edition).
Instead, IMHO it makes much more sense to keep using a
`ProjectReference` item with the documented set of required metadata, to
reference an analyzer and just define an additional custom metadata to
support packaging the analyzer: `PackAsAnalyzer`.
The reason for that is that the additional metadata explains how the
reference works (no assembly output reference, added as an Analyzer
output item) vs. the `AnalyzerReference` which is a repo custom item
that doesn't tell you that behind the scenes it actually gets converted
to a `ProjectReference` with the same metadata as if you would declare
that yourself as a P2P.
To summarize the change:
1. Consume an analyzer
```xml
<!-- Before -->
<AnalyzerReference Include="..." />
<!-- After -->
<ProjectReference Include="..." ReferenceOutputAssembly="false" OutputItemType="Analyzer" />
```
2. Pack an analyzer and consume it
```xml
<!-- Before -->
<AnalyzerReference Include="..." Pack="true" />
<!-- After -->
<ProjectReference Include="..." ReferenceOutputAssembly="false" OutputItemType="Analyzer" PackAsAnalyzer="true" />
```
3. Pack an analyzer without consuming it
```xml
<!-- Before -->
<AnalyzerReference Include="..." Pack="true" ReferenceAnalyzer="false" />
<!-- After -->
<ProjectReference Include="..." ReferenceOutputAssembly="false" PackAsAnalyzer="true" />
```
We now compile against the reference assembly in all places where we were compiling against the mono/coreclr System.Private.CoreLib.dll implementation assembly before.
The new reference assembly consumes sources from the existing contracts to avoid checking in a generated version of SPC.dll (this would add ~20k lines of .cs which is mostly duplicated with System.Runtime.cs)
Since a few contracts have only partially moved types to SPC we wrap contract types with `#if !BUILDING_CORELIB_REFERENCE` so we can hide them when compiling the SPC reference assembly. This needed a few GenAPI changes which are implemented here: https://github.com/dotnet/arcade/pull/10003.
Note that this means that the types which live in CoreLib are moved to the end of the ref .cs file which causes a GitHub diff to show up, but it is actually a no-op.
Regenerating the ref .cs files works the same way as before, by running the `GenerateReferenceAssemblySource` target in the contract's src\ folder.
Fixes https://github.com/dotnet/runtime/issues/67660
Co-authored-by: Viktor Hofer <viktor.hofer@microsoft.com>
* Fix typos
* Cleanup trailing whitespaces in committed files
* Revert a macro for win32 compat
* Disambiguate test data method
* Revert XMLPath test which rely on external assets
* Revert whitespace change in Xml tests
* Revert ClrEtwAl and ILLink.Shared
* Revert crossgen2 props/targets and *.wxl
* 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
* Update coding-style to include target-typed new guideline
Similar to `var` usage, `new()` usage is only allowed when the Type can be understood from the same line.
Fix#53369
* Fix coding style violations
Split the build of shared framework and out-of-band projects so that
it's possible to just build the shard framework projects, which was
requested by the CLR teams. In the next infrastructure rollout, the
current "libs.ref+libs.src" subsets should be removed. Generate the
targeting pack with an incomplete (without shims) frameworklist as part
of the "libs.sfx" subset.
Build the shim projects after the shared framework and oob projects and
re-generate the targeting pack's frameworklist to include the shims.
Refactor the shims so that they aren't grouped anymore by generated &
manual. Instead group them by "ref" and "src" same as other libraries
in the tree which allows to reference the source project shims and read
from the ReferenceAssembly metadata.
Use ProjectReferences in traversal projects and shim projects instead
of named references that point to binplace directories (see graph below)
This allows to build parts of the product dynamically, i.e. the shim
projects, apicompat.proj, sfx.proj and oob.proj.
Aaron Robinson