* Updated pipeline to install .NET 8 Preview 3

* Added programFiles variables to the pipeline

* Changed net 8 version

* Updated install .net core task

* Updated dotnet core installation task

* Changed .NET Core runtime install version

* Changed windowsdesktop version in pipeline

Regressed with https://github.com/dotnet/wpf/pull/7610. The CopyFiles, PublishPipelineArtifact and PublishTestResults steps should only be executed when running in the public team project as internal builds don't run tests. This change just mimics the condition that was already on the "Run Tests" powershell step.

* publish test artifacts and show test results

* Fix build error due to same artifact pushes

* fix pipeline errors

* Not running DRTs on arm64

* Fix the brackets

* update and operator brackets.

* Fix variables in the template

* update variable usage

* change to template variables

* update variable usage

* diable builds temporarily

* disable unwanted runs

* uncomment build and replace step

* use block conditional

* check with conditional

* Fix arm64 running drts

* reinstantiate running of drts

* remove unnecessary step

* download latest build from pipeline

* use artifacts from specific run arcade builds nothing

[main] Update dependencies from dotnet/arcade


 - Use DownloadBuildArtifacts@0

 - Fix specific build ID

 - Update pipeline.yml

 - Update pipeline.yml

 - Update pipeline.yml

 - Update pipeline.yml

 - Update pipeline.yml

 - Update pipeline.yml

 - Update pipeline.yml

 - Update pipeline.yml

 - Update pipeline.yml

 - Update pipeline.yml

 - Update pipeline.yml

 - Update pipeline.yml

 - Update pipeline.yml

* Updating Build images

* Revert changes in azure-pipelines.yml
Co-authored-by: NDipesh Kumar <85861525+dipeshmsft@users.noreply.github.com>
Co-authored-by: NDipesh Kumar <dipeshkumar@microsoft.com>

- Remove unused secrets
- PublishUsingPipelines is always true
- Fix the internal runtime download location

* Update pipeline to run DRTs on PRs

* Update pipeline.yml

[main] Update dependencies from dotnet/arcade


 - Update image used; it seems the GA 6.0.100 .NET Core SDK wants VS 2022 for WPF's purposes.

 - Temporarily change to Int pools for verification

 - Revert "Temporarily change to Int pools for verification"

This reverts commit 266cd39779e3f336854453b37fffae8f9be5f037.

 - Change platform Toolset to 143

 - Merge branch 'darc-main-83d344b6-2da4-4cb4-bc09-b0c292dfa886' of https://github.com/dotnet/wpf into darc-main-83d344b6-2da4-4cb4-bc09-b0c292dfa886

 - Update VCRuntime  VC version

 - Temporarily change pool to internal

 - Change toolsversion to 17

 - temporarily remove atl lib dependency

* WPF support for ARM64: WPF ARM64 public repo Packaging updates

* Enable arm64 builds on public WPF repo

* Update APICompat targets to work with ARM64
Co-authored-by: NAlexandre Zollinger Chohfi <alzollin@microsoft.com>
Co-authored-by: NMarcpems <marcpe@microsoft.com>
Co-authored-by: NJuan Sebastian Hoyos Ayala <juhoyosa@microsoft.com>
Co-authored-by: NRyland <41491307+ryalanms@users.noreply.github.com>

Co-authored-by: NDotNet Bot <dn-bot@microsoft.com>

There is no need to build debug in official builds as it's covered in CI as well as PRs

* Ad $(Debug) suffix to packages when $(Configuration) == Debug. Enable publishing packages in debug builds.

* Temporarily remove test projects from build - they require updaed Microsoft.DotNet.Wpf.DncEng.Debug packages which are not ready yet.

* Add platform suffix to log folder

* Evaluate $Configuration during target execution.

Merged PR 4378: [.Net Core 3.1] MSRC 54179, 54120: Reflecting into internal overloads of XamlReader.Load to use RestrictiveXamlXmlReader

Bugs:

- Bug [1006083](https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1006083): MSRC 54120: XAMLReader.Load used by `GetFixedDocumentSequence` method which could lead to code execution [.Net Core 3.1]
- Bug [1006086](https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1006086): MSRC 54179: Code Execution using Malicious Annotation Files for Sticky Notes in WPF apps [.Net Core 3.1]

###Description

Loose xaml can contain executable payload e.g. `ObjectDataProvider`. This Xaml can be included as part of `XpsDocument`s or base-64 encoded and then included in `StickyNote`s' annotation xml files.

In WPF, we were allowing `XpsDocument`s and `StickyNote`s' annotation xml files to be loaded freely via `XamlReader.Load`.

This exposes an attack vector - when a user downloads an XPS file from the internet for *viewing*, they could end up executing untrusted code.

The fix is to identify known dangerous types and limit them from being deserialized during XAML loading.

In order to accomplish this, we add new _non-public_ overloads to the `XamlReader.Load` method to enable the use of `RestrictiveXamlXmlReader`. `RestrictiveXamlXmlReader` restricts known dangerous types from being loaded while deserializing xaml.

We then call `XamlReader.Load` via `XamlReaderProxy`, which is an adapter for `XamlReader` type and uses reflection to access `XamlReader.Load`. Reflection is used to avoid adding additional public surface area to `XamlReader` in servicing.

Small changes are made to `TextRange` as well since the call-site for the `StickyNote`s case was through a call to `TextRange` which in turn calls into `XamlReader.Load`.

### Customer Impact

Customers would be protected from opening potentially-compromised XPS documents and stickynotes annotation xml files.

### Regression
No. This security issue was reported by an external party.

### Risk - Low

- This change only affects loading XPS documents and loading stickynotes annotation data.
- The change has been tested well internally.
  - We ran regression tests to ensure nothing else is inadvertently broken.
  - Validated against POC to ensure that the fix works as intended.

In .NET Framework, we are introducing a quirk to give developers/cusotmers the option of going back to the old (i.e., unsecure) behavior where deserializing dangerous types like `ObjectDataProvider` will be allowed. In .NET Core, no quirks are being provided - we do not believe that this is a scenario that should be supported for compatibility in a relatively new platform.

* Update for YAML stages
* Temporarily disable SDL validation until https://github.com/dotnet/arcade/issues/3565 gets resolved.