views:

196

answers:

3

Before I go on I did go through this InternalsVisibleTo attribute ain’t workin'!

Hence the title

Okay so I had a working version of my project that was using something like the following.

[assembly: InternalsVisibleTo("Stuff.Test.Support, PublicKey="0024000004800000940000000302000000240000525341310004000001000100d158cd56401c3d90b52ca1a5f273d608c3ce12aaa21385b0f4ad7dc1b747e45ee1f1771c104c52cb4da1b587ae38b6d36fa1d8e8f14003c42f700bc62ef2ec04b231c5d930e4bc3691aa1ef7b6713926316d4be1165ede086e94190b44edd4ad0d024230ae6eb9deb728b00d71d1d468b20a9bb78f242bd6c41e640c2e5c0cd5")]

In the Properties/AssemblyInfo.cs file with the internal stuff I want to access. Before checking it in it was working. but after so merging on Team Foundation IDK WTF is wrong but its like my AssemblyInfo.cs doesnt see the attribute but I verified that nothing has changed in the file but still I get the "innaccessable due to its protection level." error. (Gama Radiation? Sunspot? The little evil gnomes that train bugs to tweek working code into not working code lol)

I have tried just adding the individual instances using reflection...

Assembly Core = Assembly.LoadFile("C:\Stuff.Internal.Core\bin\Debug\Stuff.Internal.Core.dll");

Object AssmWithIdentifier = Core.CreateInstance("AssemblyWithIdentifer", false);

When I attempt this I get 'Stuff.Internal.AssemblyWithIdentifer' is inaccessible due to protection level.

Otherwise if I comment out anything having to do with the internal stuff my project compiles just fine.

I double checked my "PublicKey" with Red Gates Reflector

and I have also tried using privateObjects to possibly access methods that way but no matter how I try i can't instantiate anything internal.

I have also tried simply adding a new project, compiling it any referencing and yes that actually worked but after that I attemped to create a new project and add all the stuff in "Stuff.Test.Support" project to include references and the like and add that to the AssemblyInfo.cs that in in the project that I wish to access but, once I attempt to compile I get the same error "innaccessable due to its protection level."

Edit: I did forget to mention I am using a sharedAssembly.cs that globally manages the assemblies and has several attributes set up in a similar fashion to the example assembly: InternalsVisibleTo attribute I have shown at the beginning of this question. I am also using Strong Named assemblies if that is something not made prominent by my example.

A: 

Your PublicKey looks way too long. Also, it should be referred to as PublicKeyToken. For example:

[assembly: InternalsVisibleTo(
   "System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089")] 

Edit: as per comments below, this is wrong.

bruceboughton
Okay tried adding it directly to the end of the AssemblyInfo.cs that I wanted and commented out the internal stuff and compiled. That much compiled. But then I added in the internal stuff and I still get the Error 'is inaccessible due to its protection level.
Terrance
I also tried to add it to SharedAssemblies.cs (global assembly manager) and received the following errorFriend assembly reference 'Stuff.Tests.Support, Version=1.0.0.0, Culture=neutral, PublicKeyToken=4fe470e63e2d354f' is invalid. InternalsVisibleTo declarations cannot have a version, culture, public key token, or processor architecture specified.
Terrance
Apologies--I was wrong. The InternalsVisibleToAttribute does not use standard FQ assembly names. The documentation for the constructor (http://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.internalsvisibletoattribute.internalsvisibletoattribute.aspx) states that if your assembly is signed then (a) both assemblies must be signed and (b) you must include the PublicKey of the friend assembly (not PublicKeyToken) in the name.
bruceboughton
Np, I should have specified strong named assemblies in the question. Its kinda weird that it compiled without any errors or warnings that first time through though.
Terrance
Bruce this is wrong. You need the full token; the MSDN documentation is incorrect.
Will
+1 for Will, -1 for Bruce
STW
+1  A: 

1) if InternalsVisibleTo is set up correctly, you shouldn't need reflection to instantiate them from the 'friend', it can just use ctor's and the like directly. I would go this route so that the VS IDE can give you faster feedback on whether the internals are really visible to the target project.

2) as per the error message you got later, have you tried InternalsVisibleTo("Stuff.Test.Support") ?

James Manning
1)I have tried using reflection as an alternative to using InternalsVisibleTo since it is not currently working. I'm currently tinkering with reflection and seeing if there is something I missed.2) I am currently using strong-named assemblies so I get the errorFriend assembly reference 'Stuff.Tests.Support' is invalid. Strong-name signed assemblies must specify a public key in their InternalsVisibleTo declarations. Sorry I just modded my question to divulge a bit more info about my setup. So maybe that could help you better.
Terrance
A: 

Turns out workflow definitions were causing the discrepancy. Still trying to figure out why though.....
Well if anyone can provide a link to something explaining why will get +1 from me.

Terrance
what did you do to fix it?
Sven Hecht
I removed all the workflow defs in the project. Not the best answer but it works now. And there is currently a bug report to Microsoft for it. And the link is https://connect.microsoft.com/VisualStudio/feedback/details/588710/internalsvisibleto-fails-when-mixed-with-wf4-0-activity-definitions-and-custom-activities
Terrance