Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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 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.
"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.
- 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?
Created attachment 6614 [details]
An solution file that illustrates the problem.
I have this exact problem and posted about it here:
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.
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. :(
Update: Just realized that in my case, I do have some outlets defined. So here's the layout:
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. :/
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.
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.
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 184.108.40.206 + 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.
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
Mono 3.12.0 ((detached/de2f33f)
GTK+ 2.24.23 (Raleigh theme)
Package version: 312000076
=== Apple Developer Tools ===
Xcode 6.1.1 (6611)
=== Xamarin.Mac ===
Version: 220.127.116.11 (Business Edition)
=== Build Information ===
Release ID: 507010017
Git revision: 0bc7d3550b6b088ac25b08dcf7bbe73bcc8658b3
Build date: 2015-02-03 19:43:29-05
Xamarin addins: f7b7d34419c9ec24501bfa7c658e80a6305613e0
Created attachment 9913 [details]
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.
I have checked this issue with the following builds:
=== Xamarin Studio ===
Version 5.8 (build 1043)
Installation UUID: 011d70a5-dede-428b-ab04-ef451c2e539d
Mono 4.0.0 ((detached/2634099)
GTK+ 2.24.23 (Raleigh theme)
Package version: 400000017
Apple Developer Tools Xcode 6.1 (6604)
Xamarin.Mac Version: 18.104.22.1687 (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
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.