This is Xamarin's bug tracking system. For product support, please use the support links listed in your Xamarin Account.
Bug 9165 - Show error message when selecting invalid path in assembly signature options
Summary: Show error message when selecting invalid path in assembly signature options
Status: NEW
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Project Management (show other bugs)
Version: Trunk
Hardware: Macintosh Mac OS
: Normal enhancement
Target Milestone: master
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2012-12-30 14:23 UTC by Rodney S. Foley
Modified: 2015-08-24 13:42 UTC (History)
5 users (show)

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


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

Description Rodney S. Foley 2012-12-30 14:23:47 UTC
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 UTC
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 UTC
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 UTC
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 UTC
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 UTC
@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 UTC
@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 UTC
-> 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 UTC
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 UTC
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.