Custom NSView won't work if referenced only in storyboard (not referenced in the C#-code)

[snechaev]

Steps to Reproduce

1. Build and run the project attached
2. Observe the light blue rectangle in the main window (it's a custom NSView with a background color)
3. Open the AppDelegate.cs and comment out the line MyView test;
4. Rebuild and run the project, check the main window's content.

Expected Behavior

Nothing has changed, the light blue rectangle is still there because we only commented a declaration without any instantiation or anything else meaningful.

Actual Behavior

The light blue rectangle is missing.

Environment

Version information

Visual Studio Professional 2022 for Mac
Version 17.6.12 (build 410)
Installation UUID: 0fad0ecd-571d-44d3-a344-3945a9ce46fb

Runtime
.NET 7.0.3 (64-bit)
Architecture: X64
Microsoft.macOS.Sdk 13.1.1007; git-rev-head:8afca776a0a96613dfb7200e0917bb57f9ed5583; git-branch:release/7.0.1xx-xcode14.2

Roslyn (Language Service)
4.6.0-3.23180.6+99e956e42697a6dd886d1e12478ea2b27cceacfa

NuGet
Version: 6.4.0.117

.NET SDK (x64)
SDK: /usr/local/share/dotnet/sdk/7.0.316/Sdks
SDK Versions:
	8.0.204
	7.0.316
	7.0.315
	7.0.314
	7.0.313
	7.0.310
	7.0.309
	7.0.308
	7.0.307
	7.0.306
	7.0.304
	7.0.302
	6.0.422
	6.0.421
	6.0.420
	6.0.419
	6.0.416
	6.0.415
	6.0.414
	6.0.413
	6.0.412
	6.0.410
	6.0.408
MSBuild SDKs: /Applications/Visual Studio.app/Contents/MonoBundle/MSBuild/Current/bin/Sdks

.NET Runtime (x64)
Runtime: /usr/local/share/dotnet/dotnet
Runtime Versions:
	8.0.4
	7.0.19
	7.0.18
	7.0.17
	7.0.16
	7.0.13
	7.0.12
	7.0.11
	7.0.10
	7.0.9
	7.0.7
	7.0.5
	6.0.30
	6.0.29
	6.0.28
	6.0.27
	6.0.24
	6.0.23
	6.0.22
	6.0.21
	6.0.20
	6.0.18
	6.0.16

Xamarin.Profiler
Version: 1.8.0.49
Location: /Applications/Xamarin Profiler.app/Contents/MacOS/Xamarin Profiler

Updater
Version: 11

Apple Developer Tools
Xcode: 15.2 22503
Build: 15C500b

Xamarin.Mac
Version: 9.3.0.23 Visual Studio Professional
Hash: 9defd91b3
Branch: xcode14.3
Build date: 2023-10-23 16:14:59-0400

Xamarin.iOS
Version: 16.4.0.23 Visual Studio Professional
Hash: 9defd91b3
Branch: xcode14.3
Build date: 2023-10-23 16:15:00-0400

Xamarin Designer
Version: 17.6.3.9
Hash: 2648399ae8
Branch: remotes/origin/d17-6
Build date: 2024-05-08 22:24:17 UTC

Xamarin.Android
Version: 13.2.2.0 (Visual Studio Professional)
Commit: xamarin-android/d17-5/45b0e14
Android SDK: /Users/sergey/Library/Developer/Xamarin/android-sdk-macosx
	Supported Android versions:
		12.0 (API level 31)
		13.0 (API level 33)

SDK Command-line Tools Version: 7.0
SDK Platform Tools Version: 33.0.3
SDK Build Tools Version: 32.0.0

Build Information: 
Mono: d9a6e87
Java.Interop: xamarin/java.interop/d17-5@149d70fe
SQLite: xamarin/sqlite/3.40.1@68c69d8
Xamarin.Android Tools: xamarin/xamarin-android-tools/d17-5@ca1552d

Microsoft Build of OpenJDK
Java SDK: /Library/Java/JavaVirtualMachines/microsoft-11.jdk
11.0.16.1
Android Designer EPL code available here:
https://github.com/xamarin/AndroidDesigner.EPL

Eclipse Temurin JDK
Java SDK: /Library/Java/JavaVirtualMachines/temurin-8.jdk
1.8.0.302
Android Designer EPL code available here:
https://github.com/xamarin/AndroidDesigner.EPL

Android SDK Manager
Version: 17.6.0.50
Hash: a715dca
Branch: HEAD
Build date: 2024-05-08 22:24:22 UTC

Android Device Manager
Version: 0.0.0.1309
Hash: 06e3e77
Branch: HEAD
Build date: 2024-05-08 22:24:22 UTC

Build Information
Release ID: 1706120410
Git revision: 2f8e0518dd80a933901821bac53f7398d4b61c0f
Build date: 2024-05-08 22:22:37+00
Build branch: release-17.6
Build lane: release-17.6

Operating System
Mac OS X 14.4.1
Darwin 23.4.0 Darwin Kernel Version 23.4.0
    Fri Mar 15 00:11:05 PDT 2024
    root:xnu-10063.101.17~1/RELEASE_X86_64 x86_64

Build Logs

msbuild.binlog.zip

Example Project (If Possible)

UiFromClassLib.zip

Additional information

• The solution consists of the two projects - main macos app + macos class library.
• The class library contains a custom reusable UI MyView (MyView.xib + MyView.cs) which provides the colored background.
• The MyView is only referenced in the main app storyboard (the custom view is added and then Class=MyView in the XCode Interface builder).
• If the MyView is referenced only in the storyboard, it will not work.
• If we somehow reference the MyView type in the main app code (see line MyView test; in the AppDelegate), everything works fine.
• The problem can be reproduced in net6/7/8.

[snechaev]

Additional note - it is not necessary to reference the exact the view class in the code to make it work. It is sufficient to reference any type from the class library.

For example, I added the new empty class called UnrelatedClassLibClass in the class library then referenced this class without instantiation in the AppDelegate - UnrelatedClassLibClass test1; - and the MyView works now.

So, it looks like it is not a Xamarin problem, but some kind of general build system feature. However, in very specific Xamarin use cases, such a feature can cause strange behavior for the Xamarin apps.

[rolfbjarne]

Thanks a lot for the report!

The problem is that if you don't reference any managed code from the class library in your executable, the C# compiler won't add a reference to the class library into the main executable (which makes sense - why would the executable reference the class library if it's not used?).

And when deciding which assemblies to add in the app bundle, we start with the main executable assembly, and recursively find all the referenced assemblies (we don't include every assembly referenced by the executable project, because that would make all apps incredibly huge).

In theory we could:

• Parse any storyboards/xibs, and look for references to custom types.
• Recursively iterate over all references in the main project file, and search for custom types in those references, and if found, somehow force those references into the app bundle.

There are a few of downsides:

• We're currently not parsing storyboards/xibs for any purpose, so this would probably be a non trivial amount of work to implement and get right (but it could technically be done, if we decided to).
• It would slow down the build significantly, because a standard .NET project references a lot of other assemblies, and we'd have to read and process all those files during the build.

So, since:

• This is a fairly small corner case (it's not common to have a class library where you don't use any managed code from it at all through other managed code).
• Fixing it would require a rather big amount of work.
• The fix would negatively affect people that wouldn't need this feature.
• There's a trivial workaround.

I don't foresee we'll decide to fix this, so I'm closing this issue.

[snechaev]

Thank you very much for your detailed explanation! I totally agree that it's a very rare edge case and I'm glad to see that even though it won't be fixed, there is now some sort of searchable explanation of what's going on and how it can be workarounded. Thanks again for this explanation and for all your work in general.