xamarin-android/NuGet.config

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <clear />
    <!-- ensure only the sources defined below are used -->
    <add key="dotnet-eng" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-eng/nuget/v3/index.json" protocolVersion="3" />
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
    <add key="dotnet internal feed" value="https://dotnetfeed.blob.core.windows.net/dotnet-core/index.json" protocolVersion="3" />
  </packageSources>
</configuration>
[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 -->`
[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" />`
[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			`<add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />`
Adding new api break workflow that uses Microsoft.DotNet.ApiCompat.dll (#3884) Fixes: https://github.com/xamarin/xamarin-android/issues/1118 Context: https://bugzilla.xamarin.com/show_bug.cgi?id=60069 Context: https://github.com/xamarin/xamarin-android/pull/930 Our current API check workflow is not able to detect some API breakage or is flagging non-breaking API changes as breaking. Examples of breakages not previously reported: * Changing the values of `[Register]` attributes may be a breaking change but is not flagged by `mono-html-html`. * Adding `abstract` methods to an `abstract` class Examples of acceptable changes which elicit warnings: * Changing a base class in a compatible manner. Instead of using `mono-api-info` + `mono-api-html`, use [Microsoft.DotNet.ApiCompat][0] to perform API compatibility validation, which is what the .NET and Azure teams use. Microsoft.DotNet.ApiCompat reports `[Register]` changes: CannotChangeAttribute : Attribute 'Android.Runtime.RegisterAttribute' on 'Android.Database.Sqlite.SQLiteDatabase.Path.get()' changed from '[RegisterAttribute("getPath", "()Ljava/lang/String;", "")]' in the contract to '[RegisterAttribute("getPath", "()Ljava/lang/String;", "GetGetPathHandler")]' in the implementation. and thus would have caught the `Build.SERIAL` breakage in #930. To override the warnings produced by Microsoft.DotNet.ApiCompat, the message can be copied into an appropriate `tests/api-compatibility/acceptable-breakages-*.txt` file. See `tests/api-compatibility/README.md` for details. [0]: https://github.com/dotnet/arcade/tree/master/src/Microsoft.DotNet.ApiCompat 2019-12-08 07:45:13 +03:00			`<add key="dotnet internal feed" value="https://dotnetfeed.blob.core.windows.net/dotnet-core/index.json" protocolVersion="3" />`
[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>`
			`</configuration>`