This is Xamarin's bug tracking system. For product support, please use the support links listed in your Xamarin Account.
Bug 9165 - InternalsVisibleTo Not Working With a MonoTouch Unit Test
: InternalsVisibleTo Not Working With a MonoTouch Unit Test
Status: NEW
Product: Xamarin Studio
Classification: Desktop
Component: General
: Trunk
: Macintosh Mac OS
: --- normal
: ---
Assigned To: Bugzilla
:
:
:
:
  Show dependency treegraph
 
Reported: 2012-12-30 14:23 EST by Rodney S. Foley
Modified: 2013-01-18 14:24 EST (History)
4 users (show)

See Also:
Tags:
Test Case URL:
External Submit: ---


Attachments
Reproducible Solution (10.59 KB, application/zip)
2012-12-30 14:23 EST, Rodney S. Foley
Details

Description Rodney S. Foley 2012-12-30 14:23:47 EST
Created attachment 3146 [details]
Reproducible Solution

Sebastien Pouliot suggested I create a bug after a discussion we had on
StackOverflow.com here:

http://stackoverflow.com/questions/14093217/is-internalsvisibleto-available-to-allow-monotouch-unit-tests-access-to-the-inte

I also posted this question on Xamarin forums:

http://forums.xamarin.com/discussion/686/is-internalsvisibleto-available-to-allow-monotouch-unit-tests-access-to-the-internal-of-a-mt-lib

The issue is that I can't seem to get a MonoTouch Unit Test application to be
signed/strong named so that I can use to test a signed/strong named MonoTouch
Library using the InternalsVisibleTo assembly attribute. 

I have attached a MonoDevelop solution with a MT Library and a MT Unit Test
that reproduces the problem I am having. If you compile the solution you will
get this error:

Error CS0281: Friend access was granted to 'MonoTouchUnitTests,
PublicKeyToken=47ed45b5687d5373', but the output assembly is named
'MonoTouchUnitTests, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'.
Try adding a reference to 'MonoTouchUnitTests, PublicKeyToken=47ed45b5687d5373'
or change the output assembly name to match it (CS0281) (MonoTouchUnitTests)

My MD Version Info:

MonoDevelop 3.1.1
Installation UUID: 5051fd40-f4ac-49d3-b9cd-8d23ec98017d
Runtime:
    Mono 3.0.2 (master/9e7f206)
    GTK 2.24.11
    GTK# (2.12.0.0)
    Package version: 300020000
Apple Developer Tools:
     Xcode 4.5.2 (1847)
     Build 4G2008a
Xamarin.Mac: Not Installed
Mono for Android: Not Installed

Monotouch: 6.0.8
Build information:
    Release ID: 30101000
    Git revision: 5d928ec4f9d5864b4db04a1301b8a8649b43fb9d
    Build date: 2012-12-14 19:11:30+0000
    Xamarin addins: 80f2dcc8fe4ed316b3e77dde496fc33d90305047
Operating System:
    Mac OS X 10.8.2
    Darwin GnomeBook.local 12.2.0 Darwin Kernel Version 12.2.0
        Sat Aug 25 00:48:52 PDT 2012
        root:xnu-2050.18.24~1/RELEASE_X86_64 x86_64
Comment 1 Sebastien Pouliot 2013-01-02 14:16:18 EST
This is a bug in MonoDevelop, likely the addin, where the "Assembly Signing"
section seems ignored (or would be done later, but the compiler error stops it
from reaching that stage).

The workaround is to add:

-keyfile=/path/to/your/keypair.snk

on both projects (in Project Options, Build / Compiler, Additional Options).
Once that's done then the build works fine.
Comment 2 Rodney S. Foley 2013-01-02 22:14:46 EST
It seems the the Additional Options for the Compiler doesn't allow use of the
variables used elsewhere.  For example I would want
-keyfile=${ProjectDir}/keypair.snk however it doesn't like that.

I also tried:

-keyfile=./keypair.snk 
-keyfile=../keypair.snk 
-keyfile=../../keypair.snk 
-keyfile=../../../keypair.snk 

But they don't work either. If I have to provide a full path from root then
this is worthless. I cannot check in a full path. All pathing within a project
need to be relative or use the variables.

What is the default working directory the compiler works from and is it the
same on all versions of MD and platforms? If it is then I could work out a
relative pathing if not then this is no go.

This is a file linked from the solution folder into the project folder, so I
would EXPECT it to work.  

However as a last restore I tried fully qualified path from root to my solution
to the SNK file and if this works this I could work relative to this, however
still does not work..

The error is "Unrecognized command-line option"  so this sounded promissing but
doesn't seem to work.

So I am assuming that the compiler doesn't have a "keyfile" option to use at
all. So then I did a --help so I can see the options at it is "-keyfile:" not
"-keyfile=" you had and equals and not a colon.

However now I get a NEW error than before using this proposed workaround:

error CS1577: Referenced assembly `monotouch, Version=0.0.0.0, Culture=neutral,
PublicKeyToken=null' does not have a strong name

I did this using the attached solution and setting a fully qualified path from
root to the keyfile using the correct keyfile option for bother the library and
the application. 

So it seems MONOTOUCH itself is not strong named for some reason? How is that
possible? Shouldn't MONOTOUCH be signed and strong named?
Comment 3 Jeffrey Stedfast 2013-01-07 15:12:03 EST
This error:

Error CS0281: Friend access was granted to 'MonoTouchUnitTests,
PublicKeyToken=47ed45b5687d5373', but the output assembly is named
'MonoTouchUnitTests, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'.
Try adding a reference to 'MonoTouchUnitTests, PublicKeyToken=47ed45b5687d5373'
or change the output assembly name to match it (CS0281) (MonoTouchUnitTests)

is because you set your keyfile in the Project Options to the wrong path (see:
Build / Assembly Signing). Once I set it to the correct path, this error went
away.

However, now I get the following error:

Error CS1577: Referenced assembly `monotouch, Version=0.0.0.0, Culture=neutral,
PublicKeyToken=null' does not have a strong name (CS1577) (MonoTouch.Library)

(which is what you were getting after you made MonoDevelop manually pass the
right key by using "Additional Options")

I'm guessing this error is caused by monotouch.dll not being signed.
Comment 4 Sebastien Pouliot 2013-01-07 15:31:38 EST
Hmm... I missed that the path to the key was bad. Jeff, can you add a warning
(or even an error) if the path provided in "Assembly Signing" is bad ? 

Using an invalid path on the command-line (or using the older assembly
attributes) would abort the compilation (it's treated like an error). It's not
helpful to hide this failure from developers.

As for monotouch.dll it's already being signed for the next major release
(6.2).
Comment 5 Rodney S. Foley 2013-01-07 15:33:04 EST
@Jeffrey as I stated in comment 2 on 2013-01-02 22:14:46 EST I got pass that
issue and have the CS1577 error and I stated that same conclusion about
monotouch.dll not being signed/strong named. 

Regardless, that doesn't fix the issue that InternalsVisibleTo does not work
with MonoTouch. First they would have to provide a signed monotouch.dll which
they should have been doing all along. It doesn't matter that it all gets
compiled to native code it is a security measure for software to know they are
using an official version of a library that has not been tampered with.

Then once they provide that, we would at least be able to go to the next step
to be able to see if InternalsVisibleTo works with MonoTouch libraries and
MonoTouch unit tests. This is the primary scenario I can think of where
allowing InternalsVisibleTo work within MonoTouch would make sense so that we
can unit test internal visibility items similar to how we can do it with
regular DLL and unit tests.
Comment 6 Rodney S. Foley 2013-01-07 15:36:29 EST
@sebastien thats good to hear about it being signed in the next major release,
but what about patching it into current releases?

Also since internally you have a 6.2 monotouch.dll that is signed can you
verify if once we sign our MT DLL and MT Unit Tests that InternalsVisibleTo
will work allow for unit testing internal visibility classes and methods in
simulator and device?

If it does they great, if it doesn't then it would be how can we get this to
work without changing the visibility of the classes and methods?
Comment 7 Sebastien Pouliot 2013-01-07 15:54:43 EST
-> MD

Jeff, once comment #4 is fixed the bug can be closed (as the strongnaming part
is already done in MT master).

Rodney, Mono never validated any strongname signatures (no point since it's
open source). MonoTouch did not add this back because the AOT/linking process
destroy the signatures anyway (since the assemblies are all modified, e.g.
linking and stripping) and application-wide signing is required for the
appstore.

The next major version of MT already have assemblies strongnamed (for yet
another reason besides [InternalsVisibleTo]) which is why, in comment #1, I
told you it worked - it did work for me (your solution builds and runs on both
simulator and devices), just not with MT 6.0.x (and it's part of a large change
that won't be backported).
Comment 8 Rodney S. Foley 2013-01-07 17:12:23 EST
Okay thanks Sebastien! When is 6.2 being released by chance? or when is it
going to the beta channel at least?
Comment 9 Sebastien Pouliot 2013-01-18 14:24:25 EST
Rodney, no exact date - but it's part of
http://blog.xamarin.com/call-for-beta-participants/ (in case you're interested
in beta-testing it)

Note You need to log in before you can comment on or make changes to this bug.