[build] Remove unused bin/configuration.mk by jonathanpeppers · Pull Request #11580 · dotnet/android

jonathanpeppers · 2026-06-04T23:39:38Z

Why

bin/configuration.mk exists only to persist CONFIGURATION=<value> between Unix make invocations. Removing it lets us delete the only meaningful contents of Step_GenerateFiles.Unix.cs, continuing the slow removal of xaprepare (see precedent: #11568, #11529).

What

Drop -include bin/configuration.mk from the top of Makefile. The CONFIGURATION ?= Debug fallback at the top of the file is unchanged.
Delete build-tools/xaprepare/xaprepare/Steps/Step_GenerateFiles.Unix.cs entirely (it contained GeneratedConfigurationFile and a one-line AddUnixPostBuildSteps partial that registered it).

The partial void AddUnixPostBuildSteps (Context context, List<GeneratedFile> steps); declaration in Step_GenerateFiles.cs is intentionally left in place — partial methods without an implementation are legal in C#, and the call site becomes a zero-cost no-op. Step_GenerateFiles.Windows.cs implements a different partial (AddOSSpecificSteps) and is unaffected.

Why this is safe

Caller	Pre-change behavior	Post-change behavior
All CI YAML (`build-linux-steps.yaml`, `build-macos-steps.yaml`, `commercial-build.yaml`, `azure-pipelines-apidocs.yaml`)	Passes `CONFIGURATION=$(XA.Build.Configuration)` on every `make` call	Same — explicit value still wins
`build.sh` (`make prepare && make jenkins && make pack-dotnet`)	First `make prepare` runs against an empty `bin/`, so the `-include` no-ops and `?= Debug` takes effect	Identical — `?= Debug` still takes effect
Fresh local checkout, bare `make all`	`?= Debug` (no `bin/configuration.mk` yet)	Same
Local dev who runs `make prepare CONFIGURATION=Release` then bare `make all`	Persisted Release via `bin/configuration.mk`	Now defaults back to Debug — must pass `CONFIGURATION=Release` on every invocation

That last case is the only behavior change. It was never documented as a contract anywhere in Documentation/ or README.md, and developers building Release locally should be passing the flag explicitly anyway.

Verification

git grep "configuration\.mk" and git grep "GeneratedConfigurationFile": zero matches after this change.
dotnet build build-tools/xaprepare/xaprepare/xaprepare.csproj: 0 warnings, 0 errors.
Rubber-duck review: no remaining Path.Combine(..., "configuration.mk") references, no Makefile target depends on bin/configuration.mk as a prerequisite, and the leftover partial-method declaration is benign.

`bin/configuration.mk` existed only to persist `CONFIGURATION=<value>` between Unix `make` invocations. CI passes `CONFIGURATION=...` explicitly on every `make` call, and `build.sh` never sets it (so a fresh checkout always hit the `CONFIGURATION ?= Debug` default anyway). Dropping the include lets us delete the only meaningful contents of `Step_GenerateFiles.Unix.cs`, continuing the slow removal of xaprepare. - Drop `-include bin/configuration.mk` from the top of `Makefile`. The `CONFIGURATION ?= Debug` fallback is unchanged. - Delete `build-tools/xaprepare/xaprepare/Steps/Step_GenerateFiles.Unix.cs` entirely. The `partial void AddUnixPostBuildSteps (...)` declaration in `Step_GenerateFiles.cs` is left as a no-op (legal C#); the call site becomes a zero-cost no-op. `Step_GenerateFiles.Windows.cs` implements a different partial (`AddOSSpecificSteps`) and is unaffected. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot

Pull request overview

Removes the Unix make configuration persistence mechanism (bin/configuration.mk) as part of the ongoing cleanup/removal of xaprepare, relying solely on the existing CONFIGURATION ?= Debug default and explicit CONFIGURATION=... passed to make.

Changes:

Removed -include bin/configuration.mk from the repo Makefile.
Deleted the Unix-only xaprepare generated-file step that produced bin/configuration.mk.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
Makefile	Stops including `bin/configuration.mk`, leaving `CONFIGURATION ?= Debug` as the sole default mechanism.
build-tools/xaprepare/xaprepare/Steps/Step_GenerateFiles.Unix.cs	Removes the generator that created `bin/configuration.mk` and the Unix partial-step registration.

After deleting `Step_GenerateFiles.Unix.cs`, the `partial void AddUnixPostBuildSteps (...)` declaration and its call site in `Step_GenerateFiles.cs` were no-ops. Remove them so the file no longer references a vestige of the `bin/configuration.mk` generator. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

jonathanpeppers · 2026-06-04T23:44:37Z

/azp run

azure-pipelines · 2026-06-04T23:44:45Z

Azure Pipelines successfully started running 1 pipeline(s).

…11608) `Mono.Android.Apis.projitems` was previously generated at prepare time by `GeneratedMonoAndroidProjitemsFile` (in xaprepare) from the `BuildAndroidPlatforms.AllPlatforms` list. Both had exactly one consumer (each other), so check in the projitems as a source file and drop the generator plumbing. Changes: * Add `src/Mono.Android/Mono.Android.Apis.projitems` — content matches the generator's output byte-for-byte; only the header comment now points at `Documentation/workflow/HowToAddNewApiLevel.md` instead of declaring "GENERATED FILE". * Repoint the 4 importers (`Mono.Android.targets` x2, `create-installers.targets`, `create-android-api.csproj`, `Xamarin.Android.Build.Tasks.targets`) at the new path and drop the `Condition="Exists(...)"` guards — the file is always present now. * Delete `GeneratedMonoAndroidProjitemsFile.cs` and `AndroidPlatform.cs` (whole files — `AndroidPlatform` class and `AndroidPlatformExtensions` both become unused). * Drop the `new GeneratedMonoAndroidProjitemsFile()` registration in `Step_GenerateFiles.cs`. * Remove `BuildAndroidPlatforms.AllPlatforms` and the now-unused `using System.Collections.Generic;`. Keep the NDK constants (`AndroidNdkVersion`, `AndroidNdkPkgRevision`, `NdkMinimumAPI`, `NdkMinimumAPILegacy32`) — they still have consumers. * Update `Documentation/workflow/HowToAddNewApiLevel.md` with the XML-based instructions for adding a new API level. * Narrow the `build-tools/xaprepare/README.md` blurb for `BuildAndroidPlatforms.cs` to NDK metadata. * Fix stale doc comment in `GenerateSupportedPlatforms.cs` pointing at the old generated path. Continues the xaprepare cleanup started in PRs #11568 and #11580. ### [docs] Fix Stable=True/False contradiction in HowToAddNewApiLevel The added prose said Stable should be False for preview API levels, but the example (CANARY) sets <Stable>True</Stable>, and every entry in Mono.Android.Apis.projitems is True. Rewrite the prose to match the data and briefly explain what setting Stable=False would actually do (excludes entry from default stable framework selection). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Localized file check-in by OneLocBuild Task (#11610) Build definition ID 17928: Build ID 14320800 * [xaprepare] Check in `Mono.Android.Apis.projitems`, remove generator (#11608) `Mono.Android.Apis.projitems` was previously generated at prepare time by `GeneratedMonoAndroidProjitemsFile` (in xaprepare) from the `BuildAndroidPlatforms.AllPlatforms` list. Both had exactly one consumer (each other), so check in the projitems as a source file and drop the generator plumbing. Changes: * Add `src/Mono.Android/Mono.Android.Apis.projitems` — content matches the generator's output byte-for-byte; only the header comment now points at `Documentation/workflow/HowToAddNewApiLevel.md` instead of declaring "GENERATED FILE". * Repoint the 4 importers (`Mono.Android.targets` x2, `create-installers.targets`, `create-android-api.csproj`, `Xamarin.Android.Build.Tasks.targets`) at the new path and drop the `Condition="Exists(...)"` guards — the file is always present now. * Delete `GeneratedMonoAndroidProjitemsFile.cs` and `AndroidPlatform.cs` (whole files — `AndroidPlatform` class and `AndroidPlatformExtensions` both become unused). * Drop the `new GeneratedMonoAndroidProjitemsFile()` registration in `Step_GenerateFiles.cs`. * Remove `BuildAndroidPlatforms.AllPlatforms` and the now-unused `using System.Collections.Generic;`. Keep the NDK constants (`AndroidNdkVersion`, `AndroidNdkPkgRevision`, `NdkMinimumAPI`, `NdkMinimumAPILegacy32`) — they still have consumers. * Update `Documentation/workflow/HowToAddNewApiLevel.md` with the XML-based instructions for adding a new API level. * Narrow the `build-tools/xaprepare/README.md` blurb for `BuildAndroidPlatforms.cs` to NDK metadata. * Fix stale doc comment in `GenerateSupportedPlatforms.cs` pointing at the old generated path. Continues the xaprepare cleanup started in PRs #11568 and #11580. ### [docs] Fix Stable=True/False contradiction in HowToAddNewApiLevel The added prose said Stable should be False for preview API levels, but the example (CANARY) sets <Stable>True</Stable>, and every entry in Mono.Android.Apis.projitems is True. Rewrite the prose to match the data and briefly explain what setting Stable=False would actually do (excludes entry from default stable framework selection). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * [Xamarin.AndroidTools] Remove dead VS Mac / legacy code (#11607) Context: after the `android-platform-support` repo was inlined here (see c22cdcf), `src/Xamarin.AndroidTools/` carries a large amount of code that was only used by old VS Mac / installer / debugger-host workflows that are no longer part of the .NET for Android product. None of these types have callers anywhere in this repo, in `external/xamarin-android-tools/`, or in `external/Java.Interop/`. Removed (13 files): * `PublicationUtilities/PublishAndroidApplication.cs` * `PublicationUtilities/PackageSigningTasks.cs` * `PublicationUtilities/KeyManagement.cs` * `PublicationUtilities/KeystoreEntry.cs` * `Sessions/AndroidDeploySession.cs` * `Sessions/AndroidConnectCommandSession.cs` * `Sessions/AndroidCommandSession.cs` * `Sessions/AndroidDeploymentException.cs` * `Devices/AndroidPackageList.cs` * `Devices/AndroidPackageListExtensions.cs` * `Debugging/MonoDroidProcessMonitor.cs` * `PlatformPackage.cs` * `IProgressNotifier.cs` * `AndroidSigningOptions.cs` Moved (still needed by `ProcessUtils.cs`): * `PublicationUtilities/AndroidSdkToolException.cs` -> `AndroidSdkToolException.cs` (namespace unchanged) Pruned from `Devices/AndroidDeviceExtensions.cs` (the methods only referenced the just-deleted types and had no in-tree callers): * `StartActivityWithCommandSession` (used `AndroidCommandSession`) * `GetDeploySession`, `GetPackagesAsync`, `GetPackages` (used `AndroidDeploySession` / `IProgressNotifier`) * `InstallSharedRuntime*` and `InstallSharedPlatform*` overloads that took `IProgressNotifier` * `GetPackageRemotePath`/`GetPackageRemotePathAsync` (used `AndroidDeploymentException`) * `GetFastDevRemotePath`/`GetFastDevRemotePathAsync` and the inner `FastDevRemotePathInfo` class (only consumer was `GetPackageRemotePathAsync`) Kept methods in `AndroidDeviceExtensions.cs` are the ones still used by `Xamarin.Android.Build.Debugging.Tasks` (`EnsureProperties`, `KillProcessAndWaitForExit`, `PushAndInstallPackageAsync`) and by `DebuggingExtensions` (`SetFastDevPropertyFile`, `GetProcessIDAsync`, `SetDebugPropertiesAsync`). Also cleaned up: * `Properties/Resources.resx` (English source): removed seven `CreateKeyError_*` strings that only `KeyManagement.cs` used. * `Properties/Resources.Designer.cs`: removed the seven matching properties. * `MonoDroidSdk.cs`: two `[Obsolete]` messages referenced the now-deleted `PlatformPackage`; changed to `"Do not use."`. Non-English `Resources.*.resx` and `Localize/loc/**/*.lcl` are left alone per repo policy (auto-regenerated by OneLocBuild). Build verified locally: * `src/Xamarin.AndroidTools/Xamarin.AndroidTools.csproj` * `src/Mono.AndroidTools/Mono.AndroidTools.csproj` * `src/Xamarin.Android.Build.Debugging.Tasks/Xamarin.Android.Build.Debugging.Tasks.csproj` * `src/Xamarin.Installer.AndroidSDK/Xamarin.Installer.AndroidSDK.csproj` Net change: -4225 / +2 lines across 19 files. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * [NUnitLite] Add OneTimeSetUp/OneTimeTearDown attribute shims NUnit 3.x renamed [TestFixtureSetUp]/[TestFixtureTearDown] to [OneTimeSetUp]/[OneTimeTearDown]. dotnet/java-interop#1437 migrated the Java.Interop test suite to the new names. The bundled Xamarin.Android.NUnitLite (src-ThirdParty/NUnitLite/) only defines the legacy names. Add no-op subclasses for the new names so test source using [OneTimeSetUp]/[OneTimeTearDown] still compiles against bundled NUnitLite once the Java.Interop submodule is bumped past dotnet/java-interop#1437. These shims become unnecessary once dotnet/android moves off bundled NUnitLite to stock NUnit (tracked in PR #11224). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: VS MobileTools Engineering Service 2 <vsmobiletoolsengsvc2@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…#11613) Continues the slow `xaprepare` removal. Recent precedent: #11568 (CopyExtraResultFilesForCI → YAML), #11580 (configuration.mk removal), #11529 (android-platform-support consolidation, which also dropped `Step_PrepareExternalGitDependencies`). ## What `Step_PrepareProps` generated `external/Java.Interop/Configuration.Override.props` (inside the submodule) by substituting two placeholders into `build-tools/scripts/Configuration.Java.Interop.Override.in.props`. The substituted properties (`_XamarinAndroidCecilVersion`, `UtilityOutputFullPathCoreApps`, `XamarinAndroidToolsDirectory`) are now supplied directly via the checked-in static file `external/Java.Interop.override.props`, which Java.Interop's own `Directory.Build.props` already auto-imports via the parent-dir convention added in dotnet/java-interop#872. The shared version values (`MonoCecilVersion`, `AndroidPackVersion`, `AndroidPackVersionSuffix`) move into `eng/Versions.props`. `Directory.Build.props` and `external/Java.Interop.override.props` both `<Import>` it. No duplicate-import sentinel is needed because every code path that imports `Configuration.props` has already loaded `Directory.Build.props` (either via MSBuild auto-load or via the explicit `<Import>` in `external/xamarin-android-tools.override.props`). `MicrosoftAndroidSdkPackName` stays in `Configuration.props` (it is OS-conditioned, not version-shaped, so it doesn't belong in `Versions.props`). The same 3-line OS-conditioned block is mirrored privately in `external/Java.Interop.override.props` as `_MicrosoftAndroidSdkPackName`, used only to compute `UtilityOutputFullPathCoreApps` for the Java.Interop build. Also dropped: - `Configurables.Paths.InstallMSBuildDir` and its backing field — the only consumer was `Step_PrepareProps`. - The dead `UtilityOutputFullPath` line in the old template — Java.Interop's `TargetFrameworkDependentValues.props` unconditionally routes it to `$(UtilityOutputFullPathCoreApps)` anyway, so it was a no-op. Updated `build-tools/scripts/XAVersionInfo.targets` (the `GitBlame` for `<AndroidPackVersion>` now points at `eng/Versions.props`) and `Documentation/guides/HowToBranch.md` to reflect the moves. ## Why not just `<Import>` `Directory.Build.props` from the Java.Interop override? That was the original idea. I prototyped it: importing dotnet/android's full props chain from `external/Java.Interop.override.props` flips `DotNetTargetFrameworkVersion` from `10.0` to `11.0` inside Java.Interop, and `dotnet restore Java.Interop.csproj` then fails with: ``` NETSDK1045: The current .NET SDK does not support targeting .NET 11.0 ``` `xamarin-android-tools.override.props` gets away with the same trick only because its sole csproj sets `AndroidToolsDisableMultiTargeting=true`, which makes the TFM-clobber harmless. Java.Interop has no equivalent escape hatch. `eng/Versions.props` is collision-free with Java.Interop (verified against the submodule sources — none of the existing entries collide), has no `<Import>` of its own, and is the safe minimal shared file. ## Verification On Windows: - `dotnet build build-tools/xaprepare/xaprepare/xaprepare.csproj` — 0 warnings, 0 errors. - From `src/Xamarin.Android.Build.Tasks/`: `dotnet msbuild --getProperty:MonoCecilVersion,AndroidPackVersion,AndroidPackVersionSuffix,MicrosoftAndroidSdkPackName,MicrosoftAndroidSdkOutDir` — values unchanged from baseline. - From `external/Java.Interop/src/Java.Interop/`: - `dotnet msbuild --getProperty:DotNetTargetFramework,_XamarinAndroidCecilVersion,UtilityOutputFullPathCoreApps` returns `net10.0`, `0.11.5`, the expected packs/tools path. - `dotnet restore Java.Interop.csproj` succeeds (no `NETSDK1045`). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

### Context `Get_Omnisharp_Json` in `Step_GenerateFiles` substituted two placeholders into `build-tools/scripts/omnisharp.json.in` and wrote `omnisharp.json` at the repo root for OmniSharp / VS Code C# extension users. The generated file was always `.gitignore`d and **nothing in the repo, build, or CI consumes it** — it was purely a local-dev convenience. Anyone who actually wants an `omnisharp.json` can keep their own local copy (it remains gitignored). Removing this generation slice is another small step in the slow xaprepare reduction, continuing the pattern from #11568, #11580, #11608, and #11613. ### Audit Before this change `git grep -in "omnisharp"` returned five hits. After it returns only one — the unrelated MSBuild-context guard in `xaprepare.csproj` that prevents xaprepare's targets from importing under OmniSharp's MSBuild process: ``` build-tools/xaprepare/xaprepare/xaprepare.csproj:52: <Import Project="xaprepare.targets" Condition=" $(MSBuildToolsPath.IndexOf('omnisharp')) < 0 " /> ``` That guard is intentional and is **not** touched by this PR. ### Changes - `build-tools/xaprepare/xaprepare/Steps/Step_GenerateFiles.cs`: drop the `Get_Omnisharp_Json (context)` entry from the generated-files list and delete the `Get_Omnisharp_Json` method. - Delete `build-tools/scripts/omnisharp.json.in`. The shared properties used by the deleted method (`MicrosoftDotnetSdkInternalPackageVersion`, `DotNetPreviewPath`) are still referenced by `Step_InstallDotNetPreview` and `xaprepare.targets`, so they remain. ### Verification - `dotnet build build-tools/xaprepare/xaprepare/xaprepare.csproj -c Debug` — 0 warnings, 0 errors. - `git grep -in "omnisharp"` — returns only the unrelated `xaprepare.csproj` guard described above. - No `Documentation/` references to omnisharp; no `.vscode/` folder in the repo. - Diff: 3 files, 35 deletions, 0 additions. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot AI review requested due to automatic review settings June 4, 2026 23:39

jonathanpeppers requested a review from simonrozsival as a code owner June 4, 2026 23:39

Copilot started reviewing on behalf of jonathanpeppers June 4, 2026 23:39 View session

Copilot AI reviewed Jun 4, 2026

View reviewed changes

Comment thread Makefile

jonathanpeppers added the ready-to-review This PR is ready to review/merge, I think any CI failures are just flaky (ignorable). label Jun 5, 2026

simonrozsival approved these changes Jun 8, 2026

View reviewed changes

simonrozsival merged commit 67ecc27 into main Jun 8, 2026
2 of 3 checks passed

simonrozsival deleted the jonathanpeppers/remove-configuration-mk branch June 8, 2026 11:37

jonathanpeppers mentioned this pull request Jun 8, 2026

[build] Check in Mono.Android.Apis.projitems, remove generator #11608

Merged

jonathanpeppers mentioned this pull request Jun 9, 2026

[build] Remove Step_PrepareProps; fold values into eng/Versions.props #11613

Merged

jonathanpeppers mentioned this pull request Jun 11, 2026

[build] Remove omnisharp.json generation from xaprepare #11631

Merged

This was referenced Jun 15, 2026

[build] Inline xxHash submodule into src-ThirdParty/ #11657

Closed

[build] Inline lz4 submodule into src-ThirdParty/ #11658

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[build] Remove unused bin/configuration.mk#11580

[build] Remove unused bin/configuration.mk#11580
simonrozsival merged 2 commits into
mainfrom
jonathanpeppers/remove-configuration-mk

jonathanpeppers commented Jun 4, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

Uh oh!

jonathanpeppers commented Jun 4, 2026

Uh oh!

azure-pipelines Bot commented Jun 4, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

jonathanpeppers commented Jun 4, 2026

Why

What

Why this is safe

Verification

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

jonathanpeppers commented Jun 4, 2026

Uh oh!

azure-pipelines Bot commented Jun 4, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants