xamarin-android/.vscode/settings.json

{
    "nxunitExplorer.modules": [
        "bin/Test*/**/net472/*.dll",
    ],
    "cmake.configureOnOpen": false,
    "dotnetCoreExplorer.searchpatterns": "bin/Test{Debug,Release}/**/net6.0/{Xamarin.Android.Build.Tests,MSBuildDeviceIntegration}.dll",
}
[build] Add VSCode .code-workspace (#3611) The new `Xamarin.Android.code-workspace` and related `.vscode/*` files will improve the experience of developers to opening the root folder of a xamarin-android checkout within VSCode. Developers can build `Xamarin.Android.Build.Tasks.csproj` and `Xamarin.Android.Build.Tests.csproj`, then run the unit tests. Unit tests can then be run and debugged if the [xunit-test-adapter][0] extension is installed. [0]: https://marketplace.visualstudio.com/items?itemName=wghats.vscode-nxunit-test-adapter 2019-09-12 19:29:35 +03:00			`{`
			`"nxunitExplorer.modules": [`
[Xamarin.Android.Build.Tasks] Add %(AndroidJavaSource.Bind) (#5926) Update the `@(AndroidJavaSource)` Build action: 1. In .NET 7, all `*\.java` files are automatically added to the `@(AndroidJavaSource)` Build action. 2. Add `%(AndroidJavaSource.Bind)` item metadata, a boolean value (default is True) which controls whether or not the file is compiled and bound prior to the C# build. The combination of these means that custom Java code can be added to any .NET Android project, and a binding of that Java code will be usable by the C# code. Both Java code and bindings will be included in App builds of referencing apps. There are some restrictions on the Java code. You can only use Java types or types which are defined in `.jar` or `.aar` files referenced by the project via `@(AndroidLibrary)` or `@(EmbeddedJar)`. It is suggested that you do not have `publi` Java types which use Java generics. As with normal bindings, Java generics can cause significant problems; try to stuck to normal types if you can. 2022-05-12 03:56:23 +03:00			`"bin/Test//net472/.dll",`
[Xamarin.Android.Build.Tasks] Run `aapt2 compile` incrementally (#4190) The `aapt2 compile` command runs in two modes. The one we currently use is the `archive` mode: we call `aapt2 compile` with the `--dir` argument tp gemerate one `.flata` archive for all the files. The side effect of this is that even if you only change one file, it will need to regenerate the entire `.flata` archive. There is a second mode: rather than using `--dir` you just send in a single file. This then writes a single `.flat` file to the output directory. While this does mean you have to call `aapt2 compile` for every file, it does mean we can leverage MSBuild's support for partial targets. This means MSBuild will detect only the files which changed and allow us to call `aapt2 compile` with just the modified files. One exception to this new system are references which use the `%(AndroidSkipResourceProcessing)` metadata. In those cases the chance of those libraries being updated on a regular basis is quite low, so in that case using a `flata` archive will be better since the files won't be changing often. While this may impact initial build times, the goal is to make incremental builds quicker. This is especially true for users which use lots of `@(AndroidResource)` items. A note regarding the `aapt2 daemon` mode: in order to write accented characters we need to set the `Process.StandardInput` encoding to UTF-8. This is not possible directly in .NET Standard 2.0. We have to instead use `Console.InputEncoding`. Also note that we cannot include a BOM when writing the commands. This is because `aapt2` will try to parse the BOM as command characters. Finally, the `aapt2 link` command sometimes reports it is "Done" before it has even written the archive for the file. We can get into a position where we think we are done but the file is not on disk. Work around this by including a nasty wait which will poll for the existence of the expected output file and only return when it exists. The good news is we know at this point if the command failed or not, so we can bypass the check on failure. By using incremental builds, we improve incremental build times: \| Test \| Latest Stable \| Aapt2 Daemon \| \|--------------\|---------------\|--------------\| \| From Clean \| 00:00:27.92 \| 00:00:27.41 \| \| No Changes \| 00:00:03.14 \| 00:00:03.72 \| \| Alter Layout \| 00:00:16.37 \| 00:00:05.53 \| Note that Alter Layout with Aapt2 Daemon runs in 34% of the time. 2020-03-24 19:17:52 +03:00			`],`
[build] Update VSCode Support (#5987) Update the extensions list to use the correct id for the VSCode C# extension. Remove the `nxunitExplorer.nunit` setting as it was causing the unit tests to not load. This is because the extension is expecting a CIL image, but we were passing a batch file. As a result none of the unit tests would load in the IDE. Add some documentation around using VSCode to run the unit tests and debug the sample apps. This includes a link to a patched version of the `testrun.exe` which the `nxunit.explorer` extension uses. (There is a bug in the extension where tests with parameters will NOT run or debug. A link to the patched version of the files is included in the docs. A PR to the upstream extension has also been sent.) Added the `dotnet-adapter` extension which lets us run the tests under a `dotnet` context. 2021-07-08 20:27:40 +03:00			`"cmake.configureOnOpen": false,`
			`"dotnetCoreExplorer.searchpatterns": "bin/Test{Debug,Release}/**/net6.0/{Xamarin.Android.Build.Tests,MSBuildDeviceIntegration}.dll",`
[xaprepare] Use global NuGet package cache instead of in-tree one (#5491) Our `NuGet.config` specified a local path to store NuGet packages (commit 3a4acf5dcb) because some of our projects need to access various files from the packages, and they need to know where to find the unpacked content. However, having the `packages/` directory be a subdirectory within the `xamarin-android` checkout means that every time the repo is cleaned e.g. with `git clean -xdf`, the `packages/` directory is removed, necessitating that the NuGet packages be re-downloaded on the next `make prepare` invocation. Fix this conundrum by partially reverting 3a4acf5dcb, removing the `globalPackagesFolder` setting within `NuGet.config`. `make prepare`/`xaprepare` will create the file `bin/Build$(Configuration)/Configuration.Generated.props` and add an `$(XAPackagesDir)` MSBuild property which contains the detected NuGet global packages folder location. `Configuration.props` imports the new `Configuration.Generated.props` file, making `$(XAPackagesDir)` available to other `.targets` files should they need to access files located within NuGet packages. The `$(XAPackagesDir)` variable will contain the first valid path from: * [The `NUGET_PACKAGES` environment variable][0] * The parent directory of the parent directory of the `$(PkgXamarin_LibZipSharp)` MSBuild property, as set by the [`@(PackageReference.GeneratePathProperty)` metadata][1]. The local NuGet global-packages folder was also needed by some YAML scripts and `.vscode` files to launch `nunit3-console.exe`. Replace these `nunit3-console.exe` invocations with calls to the new `build-tools/scripts/nunit3-console` and `build-tools/scripts/nunit3-console.cmd` scripts, which will correctly determine the NuGet packages folder and execute `nunit3-console.exe` from the `nunit.consolerunner` package. Both scripts determine the NuGet global-packages folder by using the first valid path from: * The `NUGET_PACKAGES` environment variable. * If `Nuget.exe` was downloaded by a previous `make prepare` invocation, then by running: mono .nuget/NuGet.exe locals -list global-packages * The `$HOME/.nuget/packages` directory (Unix) or the `%userprofile%\.nuget\packages` directory (Windows). This removes the need to hardcode package version into our azure pipeline as well as VSCode configuration. However, both scripts still have the `nunit.consolerunner` package version embedded in them. This is done so that we don't need to generate them in scenarios where `xaprepare` is undesirable to run. [0]: https://docs.microsoft.com/en-us/nuget/consume-packages/managing-the-global-packages-and-cache-folders [1]: https://docs.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files#generatepathproperty 2021-01-26 22:49:01 +03:00			`}`