Bug 7970 - Static/Field attributes fail to build in bindings project.
Summary: Static/Field attributes fail to build in bindings project.
Alias: None
Product: iOS
Classification: Xamarin
Component: Tools ()
Version: 6.0.x
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
Depends on:
Reported: 2012-10-24 12:07 UTC by kenny goers
Modified: 2013-01-11 19:56 UTC (History)
3 users (show)

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

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:

Description kenny goers 2012-10-24 12:07:34 UTC
I created a MonoTouch program project and a bindings project from the templates in 6.0.X, the bindings project will not build when a static interface as taken from the documentation.  I've attached a project that fails.

Also, if the static is removed, the bindings project won't link, when it will link with projects built with 5.x templated projects.
Comment 1 Sebastien Pouliot 2012-10-24 12:16:57 UTC
The templates comes from MonoDevelop (the iPhone addin that ships with it) so the MonoTouch version you use should not affect them.

Could you attach a test case that fails with 6.0 and works with 5.0 ? we'll be able to drill down the cause of this by testing it against several MT releases.
Comment 2 kenny goers 2012-10-24 12:21:58 UTC
The project that I've attached fails for the Static type I tried to bind, static binding types fail no matter how they are entered, if you have a sample that includes a static binding, please, post a sample somewhere, I've been unable to find ANY.  And if someone could clarify what the LibraryName is supposed to be, that would be great as well.

On top of that, if I remove the static type from the binding, the app will not link with the sample program I generated for this bug, but if I include it in my real application, it links and runs fine.  Assuming it has something to do with the generated app for this sample.
Comment 3 Rolf Bjarne Kvinge [MSFT] 2012-10-24 19:22:59 UTC
Kenny: did you forget to attach the project?
Comment 4 kenny goers 2012-10-24 23:17:41 UTC
Here is a link to my dropbox to get it.  The project is 65MB because of the wrapped library.  I didn't notice an error when uploading last time, but guessing it failed.  Please let me know ASAP if you can, this little thing is causing a delay to QA....


Comment 5 Rolf Bjarne Kvinge [MSFT] 2012-10-25 04:18:22 UTC
You need to use "__Internal" as the library name.

I'll update the documentation to reflect this.
Comment 6 kenny goers 2012-10-25 07:23:37 UTC
I'm guessing that "__Internal" should also be the default?

Also, this is almost working, but not quite.  The code below now builds but only creates a getter, no setter:

	interface RDPDFGlobal {
		[Field("RDPDFKitEnabledFeatures", "__Internal")]
		int RDPDFKitEnabledFeatures { get; set; }

In the assembly browser:

using MonoTouch.ObjCRuntime;
using System;
public static int RDPDFKitEnabledFeatures
		return Dlfcn.GetInt32 (RDPDFGlobal.__Internal_libraryHandle, "RDPDFKitEnabledFeatures");

this line of code: 
RDPDFGlobal.RDPDFKitEnabledFeatures = 0;

Main.cs(80,46): error CS0200: Property or indexer `RDPDFKit.RDPDFGlobal.RDPDFKitEnabledFeatures' cannot be assigned to (it is read-only)
Comment 7 Rolf Bjarne Kvinge [MSFT] 2012-10-25 08:12:53 UTC
FieldAttribute is used to access constant values inside the library, so they are by definition read-only.

How does this look in ObjectiveC (both in the header and usage)?
Comment 8 kenny goers 2012-10-25 08:44:49 UTC
Header looks like this:

/** This variable holds features set, that should be availavle in RDPDFKit view. Set this mask to match feature set you've licensed from Readdle Inc. */

extern NSUInteger RDPDFKitEnabledFeatures;

-- Usage is to enable features in the library (silly implementation..)

    RDPDFKitEnabledFeatures = RDPDFKitFeatureReading | RDPDFKitFeatureAnnotating | RDPDFKitFeatureFormFilling;

I couldn't find a way to simply bind a global variable...
Comment 9 Rolf Bjarne Kvinge [MSFT] 2012-10-25 17:49:47 UTC
Currently we do not support read/write for fields.

I have created this workaround: https://gist.github.com/07491da9df9ba9c26ec1 - can you try and see if it works for you? In particular test that you can write the variable on device (I believe it *might* end up trying to write to readonly/executable memory, which will fail on device).
Comment 10 kenny goers 2012-11-15 09:31:58 UTC
The code given works both on the device and the emulator!  Please add to the bindings project documentation!
Comment 11 Rolf Bjarne Kvinge [MSFT] 2012-11-20 10:21:51 UTC
MonoTouch now supports binding rw fields, so you can just add the setter like this in the binding:

[Field ("foo")]
int Foo { get; set; }

and the right code will be generated.

master: cb368eecaf5e1aed1b3d8158ff99d3ab9a2c17ab
ios6 398053b8b718af98ceafeaa4fa0841c6f5bd0583
Comment 12 kenny goers 2013-01-07 12:20:07 UTC
I had tried this, but was still getting a message that only getters we supported, which version of MonoTouch supports this construct?  I'm on 6.0.5 currently due to a registration code snaffu, with trying to  update to versions after 6.0.5
Comment 13 Rolf Bjarne Kvinge [MSFT] 2013-01-07 12:28:10 UTC
6.0.8 is the first version where read/write fields are supported.
Comment 14 kenny goers 2013-01-07 17:14:30 UTC
I just built our solution with 6.0.8 and the assignment feature is not working when linking.  If built without linking the code assigns the value just fine and executes without fault, if we do link, the setter appears to transparently fail.  

Here is the construct we previously used to assign the value:

		static readonly IntPtr __Internal_libraryHandle = Dlfcn.dlopen (null, 0);

		public static int RDPDFFeatures {
			get {
				return Dlfcn.GetInt32 (__Internal_libraryHandle, "RDPDFKitEnabledFeatures");
			set {
				var indirect = Dlfcn.dlsym (__Internal_libraryHandle, "RDPDFKitEnabledFeatures");
				if (indirect == IntPtr.Zero)
					throw new Exception ("Field 'RDPDFKitEnabledFeatures' not found.");
				Marshal.WriteInt32 (indirect, value);

When linking the Dlfcn.dlsym() method fails to find the desired indirect reference and throws the exception, without linking it succeeds.  Similarly, when we use the 6.0.8 built in Field references, the code works when NOT linking, but fails silently when you do the assignment, I know it fails only because of how the code functions as assigning the value enables certain features and those features are not enabled when we link.  

I'm guess the method generated (Dlfcn.SetInt32(__Internal_libraryHandle, "RDPDFKitEnabledFeatures", value)) fails silently when the value isn't found, where as we throw an exception.

Please let me know if I can help further, has the Field functionality been tested with linking yet?
Comment 16 kenny goers 2013-01-11 11:28:29 UTC
Sorry for the delay, I didn't get a notification email with an update.

I've updated sample to mimic what I'm saying.  If I build for debug/iPhone I can edit the PDF forms, if I build for release/iPhone I can't edit the PDF forms.  This is a result of the Global field not getting set when linking is enabled.

Please let me know if the link above is still to the old build or you have ANY questions.
Comment 17 Rolf Bjarne Kvinge [MSFT] 2013-01-11 19:30:15 UTC
What happens is that in the release build we strip symbols from the final assemblies, and it looks like that strips away the symbol for the field, so MonoTouch can't find it anymore.

A workaround is to add -nosymbolstrip to the additional mtouch arguments.
Comment 18 Rolf Bjarne Kvinge [MSFT] 2013-01-11 19:56:58 UTC
With MonoTouch 6.0.9 it will be possible to specify the symbols to keep, like this:


which will still strip away all the other symbols (as before).