xamarin
/
xamarin-android
зеркало из https://github.com/xamarin/xamarin-android.git
1
0
Форкнуть 0
Код Задачи Пакеты Проекты Релизы Вики Активность
xamarin-android/NuGet.config

18 строки
1.3 KiB
Plaintext
Исходник Обычный вид История

[build] use a repository-wide NuGet.config (#2903) Context: https://docs.microsoft.com/en-us/nuget/consume-packages/configuring-nuget-behavior Context: http://build.devdiv.io/2500191 Context: https://github.com/xamarin/xamarin-android/pull/2859#issuecomment-476691256 Context: https://docs.microsoft.com/en-us/visualstudio/msbuild/exec-task We are randomly getting failures during Windows builds such as: NuGet.targets(114,5): Unable to load the service index for source https://someurl.visualstudio.com/_packaging/Dev/nuget/v3/index.json. Response status code does not indicate success: 401 (Unauthorized). It appears that some of our build machines on Azure DevOps have a global (or user-level) `NuGet.Config` file that points to a NuGet feed we don't have access to. The way we can workaround this, is to provide our own `NuGet.config` file that *only* uses the official nuget.org feed. * We can put a top-level `NuGet.config` next to our SLN files. * We also need to use this file during MSBuild tests. I also made sure any calls to `nuget restore` are giving us the highest log information via `-Verbosity Detailed`. This will tell us what `NuGet.config` files and feeds are used. Also in `PrepareWindows.targets`, any `<Exec/>` calls that run `NuGet.exe` need `IgnoreStandardErrorWarningFormat` set. Otherwise MSBuild treats certain output as errors. Finally, fix the `AndroidUpdateResourcesTest.CheckXmlResourcesFilesAreProcessed()` test so that `b.Build (proj, doNotCleanupOnUpdate: true)` is used. Otherwise, `$(ProjectLockFile)` is deleted on the second build, which [causes the test to fail][0]: Target _GenerateJavaStubs should have been skipped Expected: True But was: False [0]: https://jenkins.mono-project.com/job/xamarin-android-pr-pipeline-release/386/testReport/junit/Xamarin.Android.Build.Tests.AndroidUpdateResourcesTest/CheckXmlResourcesFilesAreProcessed/_False____Release/
2019-04-01 23:07:22 +03:00
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<clear />
<!-- ensure only the sources defined below are used -->
Bump to xamarin/Java.Interop/main@b46598a2; packageSources (#5608) Context: https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610 Context: https://azure.microsoft.com/en-us/resources/3-ways-to-mitigate-risk-using-private-package-feeds/ Context: https://devdiv.visualstudio.com/DevDiv/_wiki/wikis/DevDiv.wiki/12676/ncident-help-for-Substitution-attack-risk-from-multiple-package-feeds Changes: https://github.com/xamarin/Java.Interop/compare/ee7b6bbe382bf408cc1a991e6149819889ad8c6c...b46598a254c20060b107312564e0ec0aee9e33d6 * xamarin/Java.Interop@b46598a2: Bump to xamarin/xamarin-android-tools/main@479931ce; packageSources (#796) There is a Package Substitution Attack inherent in NuGet, whereby if multiple package sources provide packages with the same name, it is *indeterminate* which package source will provide the package. For example, consider the [`XliffTasks` package][0], currently provided from the [`dotnet-eng`][1] feed, and *not* present in the NuGet.org feed. If a "hostile attacker" submits an `XliffTasks` package to NuGet.org, then we don't know, and cannot control, whether the build will use the "hostile" `XliffTasks` package from NuGet.org or the "desired" package from `dotnet-eng`. There are two ways to prevent this attack: 1. Use `//packageSources/clear` and have *only one* `//packageSources/add` entry in `NuGet.config` 2. Use `//packageSources/clear` and *fully trust* every `//packageSources/add` entry in `NuGet.config`. `NuGet.org` *cannot* be a trusted source, nor can any feed location which allows "anyone" to add new packages, nor can a feed which itself contains [upstream sources][2]. As the `XliffTasks` package is *not* in `NuGet.org`, option (1) isn't an option. Go with option (2), using the existing `dotnet-eng` source and the new *trusted* [`dotnet-public`][3] package source. Update `azure-pipelines.yaml` to call [`NuGetAuthenticate@0`][4] with `forceReinstallCredentialProvider: true`. This is needed so that our commercial builds are able to authenticate with VSTS to access internal package feeds. [0]: https://github.com/dotnet/xliff-tasks [1]: https://dev.azure.com/dnceng/public/_packaging?_a=feed&feed=dotnet-eng [2]: https://docs.microsoft.com/en-us/azure/devops/artifacts/concepts/upstream-sources?view=azure-devops [3]: https://dev.azure.com/dnceng/public/_packaging?_a=feed&feed=dotnet-public [4]: https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/package/nuget-authenticate?view=azure-devops
2021-02-11 00:40:02 +03:00
<add key="dotnet-public" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-public/nuget/v3/index.json" protocolVersion="3" />
[Xamarin.Android.Build.Tasks] Move XA4214 warning text into .resx file (#3900) Context: https://dev.azure.com/devdiv/DevDiv/_workitems/edit/1009374/ This is a first step toward localizing the MSBuild error and warning messages produced by `Xamarin.Android.Build.Tasks.dll`. We will be following the [.NET Resource Localization pattern][0] and generating satellite assemblies using [`.resx` files][1], in particular `src/Xamarin.Android.Build.Tasks/Properties/Resources.resx`. `Resources.resx` is an XML file, and will contain `/root/data` elements in which `//data/@name` will start with the Xamarin.Android error or warning code, and `//data/value` will be the error or warning message: <root> <data name="XA4214" xml:space="preserve"> <value>The managed type `{0}` exists in multiple assemblies: {1}. Please refactor the managed type names in these assemblies so that they are not identical.</value> </data> </root> An optional `//data/comment` element may be provided to describe the meaning within the `//data/value` element to translators: <data name="XA4214" xml:space="preserve"> <value>The managed type `{0}` exists in multiple assemblies: {1}. Please refactor the managed type names in these assemblies so that they are not identical.</value> <comment> {0} - The managed type name {1} - Comma-separated list of all the assemblies where the managed type exists </comment> </data> During the build, `Resources.resx` will be translated into a `Resources.Designer.cs` file: namespace Xamarin.Android.Tasks.Properties { internal partial class Resources { internal static string XA4214 { get => ... } } } The `Resources` members should be used to obtain all strings for use in `LogCodedError()` and `LogCodedWarning()` calls: Log.LogCodedWarning ("XA4214", Properties.Resources.XA4214, kvp.Key, string.Join (", ", kvp.Value)); When an MSBuild error or warning code is used with more than one output string, then a semantically meaningful suffix should be used to distinguish between the two: <data name="XA4214_Result" xml:space="preserve"> <value>References to the type `{0}` will refer to `{0}, {1}`.</value> </data> Note that this infrastructure does not interoperate with C#6 string interpolation. Any error or warning messages currently using C#6 string interpolation will need to use .NET 1.0-style format strings. Our translation team doesn't work directly with `.resx` files. Instead, the translation team works with [XLIFF files][2]. `Resources.resx` is converted into a set of `src/Xamarin.Android.Build.Tasks/Properties/xlf/Resources.*.xlf` files via `XliffTasks.targets` from the [dotnet/xliff-tasks][3] repo. The `Resources.*.xlf` files should be automatically updated whenever `Resources.resx` is updated. Other: * This approach leaves the error code `XA4214` as a string literal for now. This differs from what dotnet/sdk and microsoft/msbuild do; they instead include the message code as part of the string resource in the `.resx` file. That might sometimes provide useful additional context for the translation team, but it also requires using a different set of logging methods from `Microsoft.Build.Utilities.TaskLoggingHelper`. * Fix the Test MSBuild Azure Pipelines build Specify the `feedsToUse` and `nugetConfigPath` inputs for the [`NuGetCommand@2`][6] Azure Pipelines task so that the NuGet restore step will be able to restore XliffTasks successfully from the dotnet-eng Azure DevOps NuGet package feed. This resolves the following error: The nuget command failed with exit code(1) and error(Errors in packages.config projects Unable to find version '1.0.0-beta.19252.1' of package 'XliffTasks'. C:\Users\dlab14\.nuget\packages\: Package 'XliffTasks.1.0.0-beta.19252.1' is not found on source 'C:\Users\dlab14\.nuget\packages\'. https://api.nuget.org/v3/index.json: Package 'XliffTasks.1.0.0-beta.19252.1' is not found on source 'https://api.nuget.org/v3/index.json'.) TODO: * When `Xamarin.Android.Build.Tasks.csproj` is converted into a [short-form project][4], add a dependency on dotnet/arcade and switch to using the [`GenerateResxSource` mechanism][5] instead of using `%(EmbeddedResource.Generator)`=ResXFileCodeGenerator and set `$(UsingToolXliff)`=True. This would match dotnet/sdk. [0]: https://docs.microsoft.com/dotnet/framework/resources/index [1]: https://docs.microsoft.com/dotnet/framework/resources/creating-resource-files-for-desktop-apps#resources-in-resx-files [2]: http://docs.oasis-open.org/xliff/v1.2/os/xliff-core.html [3]: https://github.com/dotnet/xliff-tasks [4]: https://docs.microsoft.com/visualstudio/msbuild/how-to-use-project-sdk [5]: https://github.com/dotnet/arcade/blob/e67d9f098029ebecedf11012a749b532d68ad2a9/Documentation/ArcadeSdk.md#generateresxsource-bool [6]: https://docs.microsoft.com/azure/devops/pipelines/tasks/package/nuget
2019-12-07 21:58:58 +03:00
<add key="dotnet-eng" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-eng/nuget/v3/index.json" protocolVersion="3" />
Bump to dotnet/installer/main@c7afae69 7.0.100-preview.4.22174.1 (#6598) Context: https://github.com/dotnet/runtime/issues/56989 Context: https://github.com/dotnet/runtime/issues/68734 Context: https://github.com/dotnet/runtime/issues/68914 Context: https://github.com/dotnet/runtime/pull/68701 Changes: https://github.com/dotnet/installer/compare/04e40fa9...c7afae69 % git diff --shortstat 04e40fa9...c7afae69 98 files changed, 1788 insertions(+), 1191 deletions(-) Changes: https://github.com/dotnet/runtime/compare/a21b9a2d...c5d40c9e % git diff --shortstat a21b9a2d...c5d40c9e 28347 files changed, 1609359 insertions(+), 1066473 deletions(-) Changes: https://github.com/dotnet/linker/compare/01c4f590...04c49c9d % git diff --shortstat 01c4f590...04c49c9d 577 files changed, 28039 insertions(+), 10835 deletions(-) Updates to build with the .NET 7 SDK and use the runtime specified by the SDK. We no longer use different SDK & runtime versions. This produces a 7.0.100 Android workload. After this is merged we should be able to enable Maestro to consume future .NET 7 builds from dotnet/installer/main. ~~ Known Issues ~~ AOT+LLVM crashes on startup: * https://github.com/dotnet/runtime/issues/68914 Xamarin.Build.Download hits a breaking change with `ZipEntry`: * https://github.com/dotnet/runtime/issues/68734 * https://github.com/xamarin/XamarinComponents/pull/1368 illink outputs different MVIDs per architecture: * https://github.com/dotnet/linker/issues/2203 * https://github.com/dotnet/runtime/issues/67660 Size of `libmonosgen-2.0.so` regressed: * https://github.com/dotnet/runtime/issues/68330 * https://github.com/dotnet/runtime/pull/68354 Newer .NET 7 builds crash on startup: * https://github.com/dotnet/runtime/pull/68701 * This is worked around by *disabling* lazy loading of AOT'd assemblies 6dc426f1. * TODO: re-enable once we get a fixed .NET 7 runtime. TODO: We can't yet push to the `dotnet7` feed. Working on this. Co-authored-by: Jonathan Peppers <jonathan.peppers@microsoft.com> Co-authored-by: Peter Collins <pecolli@microsoft.com>
2022-05-06 00:04:44 +03:00
<add key="dotnet7" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet7/nuget/v3/index.json" />
[build] Use dotnet/arcade dependency management tooling (#5731) Context: https://github.com/dotnet/arcade/blob/ea609b8e036359934332480de9336d98fcbb3f91/Documentation/Darc.md The dotnet core engineering group has some dependency management tooling known as `darc` that we'd like to adopt. Integrating this tooling into the build system will make it easier to stay up to date with the latest .NET 6 SDK changes. Many dotnet repos use a [publishing workflow][0] that will push build artifact data to a central location known as the "Build Asset Registry". This data includes a "[Channel][1]" association, which is the key to dependency updating. Local updates and automatic update "Subscriptions" compare the version files in a given repo against the product versions available in the channel that you are interested in. We hope to be able to publish Xamarin SDK build information to this central registry in the near future, so that other products can take a dependency on us as needed (dotnet/maui for instance). The `darc` tool looks for four different files in a repo when adding a dependency or when checking for an update: * `eng/Version.Details.xml` * `eng/Versions.props` * `global.json` * `nuget.config` Both of the `Version*` files present in the `eng` folder are updated when a new dependency is available. To work with `darc` locally you will need to [install][2] the `darc` global tool, join the `arcade-contrib` GitHub team, and configure your auth settings. To add a new dependency, use the [`darc add-dependency`][3] command: darc add-dependency -n Microsoft.NetCore.App.Runtime.android-arm64 -t product -v 6.0.0-preview.2.21154.6 -r https://github.com/dotnet/runtime To update all dependencies, use the [`darc update-dependencies`][4] command: darc update-dependencies --channel ".NET 6" To configure automatic updates, use the [`darc add-subscription`][5] command to enroll a target repo/branch into updates from a particular channel: darc add-subscription --channel ".NET 6" --source-repo https://github.com/dotnet/installer --target-repo https://github.com/xamarin/xamarin-android --target-branch main --update-frequency everyWeek --standard-automerge Once a subscription is configured, [a pull request][6] will be created automatically by the dotnet Maestro bot when dependency updates are available. ~~~ This PR also contains a bump to .NET 6.0.100-preview.3.21168.18. Changes: https://github.com/dotnet/installer/compare/19e22a76...823c1dfce The .NET 6 `.apkdesc` files have been updated accordingly. It seems that `System.Private.CoreLib.dll` grew in size, however reductions in native libraries/etc. results in an overall smaller package sizes. Simple XA: -"PackageSize": 2889606 +"PackageSize": 2877318 XF/XA: -"PackageSize": 8746124 +"PackageSize": 8733836 [0]: https://github.com/dotnet/arcade/blob/681511f2f63a3563494f1f27904b2842abef6b35/Documentation/CorePackages/Publishing.md#what-is-v3-publishing-how-is-it-different-from-v2 [1]: https://github.com/dotnet/arcade/blob/main/Documentation/BranchesChannelsAndSubscriptions.md#branches-channels-and-subscriptions-explained [2]: https://github.com/dotnet/arcade/blob/ea609b8e036359934332480de9336d98fcbb3f91/Documentation/Darc.md#setting-up-your-darc-client [3]: https://github.com/dotnet/arcade/blob/ea609b8e036359934332480de9336d98fcbb3f91/Documentation/Darc.md#add-dependency [4]: https://github.com/dotnet/arcade/blob/ea609b8e036359934332480de9336d98fcbb3f91/Documentation/Darc.md#update-dependencies [5]: https://github.com/dotnet/arcade/blob/ea609b8e036359934332480de9336d98fcbb3f91/Documentation/Darc.md#add-subscription [6]: https://github.com/xamarin/xamarin-android/pull/5744
2021-03-22 22:57:32 +03:00
<!-- This is needed (currently) for the Xamarin.Android.Deploy.Installer dependency, getting the installer -->
<!-- Android binary, to support delta APK install -->
<add key="xamarin.android util" value="https://pkgs.dev.azure.com/xamarin/public/_packaging/Xamarin.Android/nuget/v3/index.json" />
Bump to dotnet/installer/main@dd355bb 7.0.100-rc.2.22457.6 (#7360) Changes: https://github.com/dotnet/installer/compare/330dee39e5e4dcf765f4c41c76b94c8e4497e91c...dd355bb777249689beba30978ac26e15c96da642 Changes: https://github.com/dotnet/linker/compare/313671b195b1b36d56a8888a9a0e12edaac52c57...5f9bfd94d9c687207872ae03f751ea19704381c0 Changes: https://github.com/dotnet/runtime/compare/ef077d0b58ffddcf54fa73bd85dace6b999b8992...6d10e4c8bcd9f96ccd73748ff827561afa09af57 Changes: https://github.com/dotnet/emsdk/compare/216093204c415b6e37dfadfcbcf183881b443636...8d8d2122b16c81df4b158fe43995f958e8fe115e Updates: * Microsoft.Dotnet.Sdk.Internal: from 7.0.100-rc.2.22454.1 to 7.0.100-rc.2.22457.6 * Microsoft.NET.ILLink.Tasks: from 7.0.100-1.22423.4 to 7.0.100-1.22452.1 * Microsoft.NETCore.App.Ref: from 7.0.0-rc.1.22422.12 to 7.0.0-rc.2.22451.11 * Microsoft.NET.Workload.Emscripten.Manifest-7.0.100: from 7.0.0-rc.1.22411.1 to 7.0.0-rc.2.22430.5 This is bringing required changes from 2bf5153 to `main`. ~~ Other Changes ~~ * `darc update-dependencies --id 148018` to manually update the dotnet/installer version * Add feeds in `NuGet.config` from our .NET 6 release branch * Install both net6 & net7 workload manifests for Mono and Emscripten * Extend both net6 & net7 Mono workloads from the `android` workload * Support for `$(AotAssemblies)` property (directly uses Mono workload pack names) * Update `.apkdesc` files
2022-09-09 00:15:08 +03:00
<!-- Added manually for dotnet/runtime 6.0.9 -->
<add key="darc-pub-dotnet-emsdk-3f6c45a" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/darc-pub-dotnet-emsdk-3f6c45a2/nuget/v3/index.json" />
<add key="darc-pub-dotnet-runtime-531f715" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/darc-pub-dotnet-runtime-531f715f/nuget/v3/index.json" />
[build] use a repository-wide NuGet.config (#2903) Context: https://docs.microsoft.com/en-us/nuget/consume-packages/configuring-nuget-behavior Context: http://build.devdiv.io/2500191 Context: https://github.com/xamarin/xamarin-android/pull/2859#issuecomment-476691256 Context: https://docs.microsoft.com/en-us/visualstudio/msbuild/exec-task We are randomly getting failures during Windows builds such as: NuGet.targets(114,5): Unable to load the service index for source https://someurl.visualstudio.com/_packaging/Dev/nuget/v3/index.json. Response status code does not indicate success: 401 (Unauthorized). It appears that some of our build machines on Azure DevOps have a global (or user-level) `NuGet.Config` file that points to a NuGet feed we don't have access to. The way we can workaround this, is to provide our own `NuGet.config` file that *only* uses the official nuget.org feed. * We can put a top-level `NuGet.config` next to our SLN files. * We also need to use this file during MSBuild tests. I also made sure any calls to `nuget restore` are giving us the highest log information via `-Verbosity Detailed`. This will tell us what `NuGet.config` files and feeds are used. Also in `PrepareWindows.targets`, any `<Exec/>` calls that run `NuGet.exe` need `IgnoreStandardErrorWarningFormat` set. Otherwise MSBuild treats certain output as errors. Finally, fix the `AndroidUpdateResourcesTest.CheckXmlResourcesFilesAreProcessed()` test so that `b.Build (proj, doNotCleanupOnUpdate: true)` is used. Otherwise, `$(ProjectLockFile)` is deleted on the second build, which [causes the test to fail][0]: Target _GenerateJavaStubs should have been skipped Expected: True But was: False [0]: https://jenkins.mono-project.com/job/xamarin-android-pr-pipeline-release/386/testReport/junit/Xamarin.Android.Build.Tests.AndroidUpdateResourcesTest/CheckXmlResourcesFilesAreProcessed/_False____Release/
2019-04-01 23:07:22 +03:00
</packageSources>
[build] Use dotnet/arcade dependency management tooling (#5731) Context: https://github.com/dotnet/arcade/blob/ea609b8e036359934332480de9336d98fcbb3f91/Documentation/Darc.md The dotnet core engineering group has some dependency management tooling known as `darc` that we'd like to adopt. Integrating this tooling into the build system will make it easier to stay up to date with the latest .NET 6 SDK changes. Many dotnet repos use a [publishing workflow][0] that will push build artifact data to a central location known as the "Build Asset Registry". This data includes a "[Channel][1]" association, which is the key to dependency updating. Local updates and automatic update "Subscriptions" compare the version files in a given repo against the product versions available in the channel that you are interested in. We hope to be able to publish Xamarin SDK build information to this central registry in the near future, so that other products can take a dependency on us as needed (dotnet/maui for instance). The `darc` tool looks for four different files in a repo when adding a dependency or when checking for an update: * `eng/Version.Details.xml` * `eng/Versions.props` * `global.json` * `nuget.config` Both of the `Version*` files present in the `eng` folder are updated when a new dependency is available. To work with `darc` locally you will need to [install][2] the `darc` global tool, join the `arcade-contrib` GitHub team, and configure your auth settings. To add a new dependency, use the [`darc add-dependency`][3] command: darc add-dependency -n Microsoft.NetCore.App.Runtime.android-arm64 -t product -v 6.0.0-preview.2.21154.6 -r https://github.com/dotnet/runtime To update all dependencies, use the [`darc update-dependencies`][4] command: darc update-dependencies --channel ".NET 6" To configure automatic updates, use the [`darc add-subscription`][5] command to enroll a target repo/branch into updates from a particular channel: darc add-subscription --channel ".NET 6" --source-repo https://github.com/dotnet/installer --target-repo https://github.com/xamarin/xamarin-android --target-branch main --update-frequency everyWeek --standard-automerge Once a subscription is configured, [a pull request][6] will be created automatically by the dotnet Maestro bot when dependency updates are available. ~~~ This PR also contains a bump to .NET 6.0.100-preview.3.21168.18. Changes: https://github.com/dotnet/installer/compare/19e22a76...823c1dfce The .NET 6 `.apkdesc` files have been updated accordingly. It seems that `System.Private.CoreLib.dll` grew in size, however reductions in native libraries/etc. results in an overall smaller package sizes. Simple XA: -"PackageSize": 2889606 +"PackageSize": 2877318 XF/XA: -"PackageSize": 8746124 +"PackageSize": 8733836 [0]: https://github.com/dotnet/arcade/blob/681511f2f63a3563494f1f27904b2842abef6b35/Documentation/CorePackages/Publishing.md#what-is-v3-publishing-how-is-it-different-from-v2 [1]: https://github.com/dotnet/arcade/blob/main/Documentation/BranchesChannelsAndSubscriptions.md#branches-channels-and-subscriptions-explained [2]: https://github.com/dotnet/arcade/blob/ea609b8e036359934332480de9336d98fcbb3f91/Documentation/Darc.md#setting-up-your-darc-client [3]: https://github.com/dotnet/arcade/blob/ea609b8e036359934332480de9336d98fcbb3f91/Documentation/Darc.md#add-dependency [4]: https://github.com/dotnet/arcade/blob/ea609b8e036359934332480de9336d98fcbb3f91/Documentation/Darc.md#update-dependencies [5]: https://github.com/dotnet/arcade/blob/ea609b8e036359934332480de9336d98fcbb3f91/Documentation/Darc.md#add-subscription [6]: https://github.com/xamarin/xamarin-android/pull/5744
2021-03-22 22:57:32 +03:00
<disabledPackageSources />
[build] Use an in tree `globalPackagesFolder` (#4105) `@(PackageReference)` packages install/restore into a default global folder of `%userprofile%\.nuget\packages` (Windows) or `$HOME/.nuget/packages` (Linux, macOS). In order to avoid bloating the home directories on our machines used locally and in CI, we'll reconfigure the `globalPackagesFolder` path to point to a `packages` folder nested under `xamarin-android`. This also allows us to continue to use "known" paths to certain tools that are used by our tests, such as `nunit3-console.exe`. Each test in `Xamarin.Android.Build.Tests` copies and uses the `NuGet.config` file from the xamarin-android repo root. Now that a `globalPackagesFolder` value is specified there, NuGet restore behavior for all tests has changed. A new `globalPackagesFolder` default has now been set for all tests so that a common folder can be used rather than a `packages` folder nested under each test directory. Additionally, some tests have been updated to no longer run in parallel due to restore issues. Co-Authored-By: Jonathan Peppers <jonathan.peppers@microsoft.com>
2020-01-17 00:25:54 +03:00
</configuration>