Bug 14468 - Registering NSWindow and NSView subclasses in a library project doesn't add the names in the final app
Summary: Registering NSWindow and NSView subclasses in a library project doesn't add t...
Status: VERIFIED FIXED
Alias: None
Product: Xamarin.Mac
Classification: Desktop
Component: Other ()
Version: 1.12.0
Hardware: PC Mac OS
: Normal normal
Target Milestone: 2.0.x
Assignee: Chris Hamons
URL:
Depends on:
Blocks:
 
Reported: 2013-09-05 23:22 UTC by Brendan Zagaeski (Xamarin Team, assistant)
Modified: 2015-03-03 05:27 UTC (History)
5 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
An solution file that illustrates the problem. (103 bytes, text/plain)
2014-04-18 17:36 UTC, Jacob
Details
Test case (24.59 KB, application/zip)
2015-02-18 17:30 UTC, Brendan Zagaeski (Xamarin Team, assistant)
Details


Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
VERIFIED FIXED

Description Brendan Zagaeski (Xamarin Team, assistant) 2013-09-05 23:22:48 UTC
Related to bug #3611, and a forum post: http://forums.xamarin.com/discussion/7682

Steps to reproduce:
1. Open the example project attached to bug #3611, or the test app from github (https://github.com/baulig/Provcon-Faust/tree/027be7ac05a9d2ac8d2a468f40e4bf13fbe5708b/TestMac)

2. Clean, build, and run the project.


Result:
"A System.InvalidCastException was thrown" while casting `base.Window` or `base.View` to the subclass (`MySpecialWindow` or `TestView`) in the "strongly typed accessor" in the Library project.


Additional information:
- Moving all of the `.cs` files from the Library project into the app project is one work-around.

- Removing the subclass cast for the accessor, and returning just a plain NSWindow or NSView prevents the Exception, but leads to a different error message:

"Unknown Window class MySpecialWindow in Interface Builder file, creating generic Window instead"

The app finds the NIB file (bug #3611 is still fixed), but the NIB file cannot find the custom MySpecialWindow class. Perhaps this indicates that the Register attribute in the Library project is not adding the class name to the Objective-C environment of the app?
Comment 1 Jacob 2014-04-18 17:36:44 UTC
Created attachment 6614 [details]
An solution file that illustrates the problem.

I have this exact problem and posted about it here: 
http://forums.xamarin.com/discussion/15599/is-this-a-bug-with-xamarin#latest

Registering your custom NSView seems to work but the moment you create an outlet of the custom NSView a casting exception is thrown.  

See my Example App Soultion file (attached above) that illustrates this problem.
- The "Fails" project uses a custom view in a referenced library project
- The "Works" project has a custom view within itself
Run the "Fails" project to see the fail and the "Works" project to see it work.

I really need this fixed to move forward on my project so any help is greatly appreciated.
Comment 2 xamarin 2014-06-03 21:25:19 UTC
This problem is a barrier in my app development as well. Even worse, it's inconsistent. I have an executable and three assemblies. One is back-end, no UI code. The other two are extensions that plug into the app. For ONE of them, it seems I can create the view from the viewcontroller just fine (though I don't yet have any outlets). For the second assembly, not even a trivial, empty view will load. The constructor is never even called.

At this point, my only recourse is to entirely ignore architecture and put all of the xibs into the actual executable. :(
Comment 3 xamarin 2014-06-03 21:30:42 UTC
Update: Just realized that in my case, I do have some outlets defined. So here's the layout:
Library A
Library B : uses A
Library C: uses A, B
App : uses A, B, C

Tonight I experimented putting a xib in B and  .... it worked! So I moved a xib from App to B (including outlets) and it still seemed to work after clean, etc.

So, feeling bold, moved another xib out of the app into C. no worky, even new, simplistic empty ones. :/
Comment 4 xamarin 2014-06-03 21:47:04 UTC
BREAKTHROUGH! (OK, a hack of sorts)...

In my case, it turns out that my assembly 'B' also is the portion of the application that provides the custom NSApplication implementation I'm using. Looking at the debug output, it occurred to me that the very first reference I was making to Libarary C was in AwakeFromNib() in my main window, creating the view controller and the view itself.

Well... the hack is to refer to Library C sooner. In my case, the temp hack is to just access a static in Library C.

So, it appears that this is all an order-of-operations type thing perhaps? I.e. if I can ensure that the 'C' assembly is fully loaded prior to accessing the first xib from it, it seems to be working.

All conjecture, and not very carefully elaborated, but it's something.

So perhaps a workaround for this for now is simply to find a convenient, early access point (in my case, shudder, Main.cs). Total hack.
Comment 5 Chris Hamons 2015-02-18 14:46:15 UTC
Apologies on the long delay in response. This bug was misfiled and overlooked.

This appears to work for me with modern Xamarin.Mac / Xamarin.Studio combinations. Please reopen if this doesn't work for you (I tested the attached use case).

Sorry again for the delay in response.
Comment 6 Brendan Zagaeski (Xamarin Team, assistant) 2015-02-18 17:30:22 UTC
Unfortunately, I didn't add either of the test cases from my original description (comment 0) as attachments on this bug report. The attachment from bug 3611 still shows the original bug behavior in Xamarin.Mac 1.12.0.4 + Xamarin Studio 5.7.1.

To be thorough, I recreated the test case from bug 3611 from scratch starting with the "C# -> Mac -> Classic API -> Xamarin.Mac Project" template in XS 5.7.1. I'll attach that in my next comment.


## Step to reproduce

Build and run the new attached test case.


## Results

From the Application Output:

> 2015-02-18 17:02:19.839 XamarinMacDemo[36996:e07] Unknown Window class MySpecialWindow in Interface Builder file,
> 	 creating generic Window instead
> 
> Unhandled Exception:
> System.InvalidCastException: Cannot cast from source type to destination type.
>   at Library.MySpecialWindowController.get_Window () [0x00002] in /Volumes/ramdisk/XMac/XamarinMacDemo/Library/MySpecialWindowController.cs:45 
>   at XamarinMacDemo.AppDelegate.DidFinishLaunching (MonoMac.Foundation.NSNotification notification) [0x00012] in /Volumes/ramdisk/XMac/XamarinMacDemo/XamarinMacDemo/AppDelegate.cs:24 
>   at (wrapper managed-to-native) MonoMac.AppKit.NSApplication:NSApplicationMain (int,string[])
>   at MonoMac.AppKit.NSApplication.Main (System.String[] args) [0x00041] in /Users/builder/data/lanes/1248/7af09261/source/xamcore/src/AppKit/NSApplication.cs:106 
>   at XamarinMacDemo.MainClass.Main (System.String[] args) [0x00007] in /Volumes/ramdisk/XMac/XamarinMacDemo/XamarinMacDemo/Main.cs:14 


## Version info

### OS X 10.9.5, MacBook Air

=== Xamarin Studio ===

Version 5.7.1 (build 17)
Installation UUID: 2c0ea975-8f73-4920-8414-3e9ae359fbf4
Runtime:
	Mono 3.12.0 ((detached/de2f33f)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 312000076

=== Apple Developer Tools ===

Xcode 6.1.1 (6611)
Build 6A2008a

=== Xamarin.Mac ===

Version: 1.12.0.4 (Business Edition)

=== Build Information ===

Release ID: 507010017
Git revision: 0bc7d3550b6b088ac25b08dcf7bbe73bcc8658b3
Build date: 2015-02-03 19:43:29-05
Xamarin addins: f7b7d34419c9ec24501bfa7c658e80a6305613e0
Comment 7 Brendan Zagaeski (Xamarin Team, assistant) 2015-02-18 17:30:59 UTC
Created attachment 9913 [details]
Test case
Comment 8 Chris Hamons 2015-02-24 16:06:25 UTC
This WFM with the latest master as of today. It should be fixed in XM 2.0 (this summer).

@Brendan - Poke me if you want a build to test.
Comment 9 Rajneesh Kumar 2015-03-03 05:27:56 UTC
I have checked this issue with the following builds:

=== Xamarin Studio ===
Version 5.8 (build 1043)
Installation UUID: 011d70a5-dede-428b-ab04-ef451c2e539d
Runtime:
Mono 4.0.0 ((detached/2634099)
GTK+ 2.24.23 (Raleigh theme)
Package version: 400000017
Apple Developer Tools Xcode 6.1 (6604)
Build 6A1052d
Xamarin.Mac Version: 1.13.1.417 (Business Edition)
=== Build Information ===
Release ID: 508001043
Git revision: eeba4b77cc5ab021f9c5e2bddf16272e1f6b75d9
Build date: 2015-03-02 06:49:10-05
Xamarin addins: a58814e6e6034bf1169e758b92ead093a3f40404
Operating System Mac OS X 10.9.5
Darwin MacMini.local 13.4.0 Darwin Kernel Version 13.4.0
Sun Aug 17 19:50:11 PDT 2014
root:xnu-2422.115.4~1/RELEASE_X86_64 x86_64

I open attached test case in XS, and able to run it successfully without any exception. Her eis the screencast for the same: http://www.screencast.com/t/n2LQHVyMCP

This issue has been fixed, hence I am closing this issue.