[msbuild] Fix FilterStaticFrameworks task to support custom framework binary names #23045

Copilot · 2025-06-13T18:10:16Z

The FilterStaticFrameworks MSBuild task was hardcoded to assume framework executables are always located at Framework.framework/Framework, but some frameworks (like FFmpeg's libavcodec) use custom executable paths specified in their Info.plist via the CFBundleExecutable property.

This caused build failures with frameworks that use custom binary names:

error MT158: The file '/path/to/libavcodec.framework/libavcodec' does not exist.

The actual executable was at libavcodec.framework/libavcodec.dylib as specified in the framework's Info.plist CFBundleExecutable property.

Solution

Added a GetFrameworkExecutablePath helper method that:

Reads Info.plist: Checks for CFBundleExecutable property in framework's Info.plist
Uses custom path: Returns the path specified by CFBundleExecutable when present
Falls back gracefully: Uses default behavior for standard frameworks or when Info.plist is missing/corrupt
Maintains compatibility: All existing frameworks continue to work unchanged

Example

Before (fails):

libavcodec.framework/
├── Info.plist  # CFBundleExecutable = "libavcodec.dylib"
└── libavcodec.dylib

Task looks for: libavcodec.framework/libavcodec ❌

After (works):
Task reads Info.plist and looks for: libavcodec.framework/libavcodec.dylib ✅

Testing

Added comprehensive tests covering:

✅ Custom CFBundleExecutable scenarios (reproduces the original issue)
✅ Standard frameworks without Info.plist (backward compatibility)
✅ Non-framework paths (edge case handling)
✅ Error handling for malformed/missing Info.plist files

Fixes #23039.

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

Co-authored-by: rolfbjarne <249268+rolfbjarne@users.noreply.github.com>

mandel-macaque · 2025-06-13T18:32:46Z

msbuild/Xamarin.MacDev.Tasks/Tasks/FilterStaticFrameworks.cs

+				try {
+					var plist = PDictionary.FromFile (infoPlistPath);
+					var bundleExecutable = plist?.GetCFBundleExecutable ();
+					if (!string.IsNullOrEmpty (bundleExecutable)) {
+						return Path.Combine (frameworkPath, bundleExecutable);
+					}
+				} catch {
+					// If reading the plist fails, fall back to the default behavior
+				}


FromFile does not raise any exception, what exception are you trying to catch? This can me cleaner with a if statement no need for the try/catch.

You're right! I've simplified the code by removing the try-catch and using explicit null checking instead. Since GetFrameworkExecutablePath is called within a larger try-catch block that handles framework validation errors appropriately, any exceptions from PDictionary.FromFile will be caught and logged with proper error messages. The refactored code is cleaner and follows the patterns used elsewhere in the codebase. Fixed in d3f208c.

mandel-macaque · 2025-06-13T18:33:42Z

msbuild/Xamarin.MacDev.Tasks/Tasks/FilterStaticFrameworks.cs


+		static string GetFrameworkExecutablePath (string frameworkPath)
+		{
+			if (!frameworkPath.EndsWith (".framework", StringComparison.OrdinalIgnoreCase) || !Directory.Exists (frameworkPath))


Simplify the || to use an and so that it can be short circuit.

Simplified the logical condition to use && with short-circuiting instead of ||. The change is logically equivalent but more efficient - if the path doesn't end with ".framework", we skip the Directory.Exists check entirely. Fixed in 0b203a4.

Co-authored-by: mandel-macaque <2190086+mandel-macaque@users.noreply.github.com>

Copilot · 2025-06-13T18:50:43Z