InternalsVisibleTo 属性不起作用
在我继续之前我确实经历过这个 InternalsVisibleTo 属性不起作用!
因此,标题
好吧,我有一个工作版本使用类似以下内容的项目。
[assembly: InternalsVisibleTo("Stuff.Test.Support, PublicKey="0024000004800000940000000302000000240000525341310004000001000100d158cd56401c3d90b52ca1a5f273d608c3ce12aaa21385b0f4ad7dc1b747e45ee1f1771c104c52cb4da1b587ae38b6d36fa1d8e8f14003c42f700bc62ef2ec04b231c5d930e4bc3691aa1ef7b6713926316d4be1165ede086e94190b44edd4ad0d024230ae6eb9deb728b00d71d1d468b20a9bb78f242bd6c41e640c2e5c0cd5")]
在 Properties/AssemblyInfo.cs 文件中,其中包含我想要访问的内部内容。 在检查之前它正在工作。但在 Team Foundation IDK 上合并之后,WTF 是错误的,就像我的 AssemblyInfo.cs 没有看到该属性,但我验证了文件中没有任何更改,但我仍然得到 “由于其保护级别,innaccessable。”< /代码> 错误。 (伽马辐射?太阳黑子?训练错误将工作代码调整为不工作代码的小邪恶侏儒哈哈)
我尝试过使用反射添加单个实例...
Assembly Core = Assembly.LoadFile("C:\Stuff.Internal.Core\bin\Debug\Stuff.Internal.Core.dll");
Object AssmWithIdentifier = Core.CreateInstance("AssemblyWithIdentifer", false);
当我尝试这样做时,我得到'Stuff.Internal。由于保护级别,AssemblyWithIdentifer' 无法访问。
否则,如果我注释掉与内部内容有关的任何内容,我的项目编译得很好。
我用 Red Gates Reflector 仔细检查了我的“PublicKey”
,并且我还尝试使用 privateObjects 来可能以这种方式访问方法,但无论我如何尝试,我都无法实例化任何内部内容。
我还尝试简单地添加一个新项目,编译它的任何引用,是的,实际上有效,但之后我尝试创建一个新项目并添加“Stuff.Test.Support”项目中的所有内容以包括引用等将其添加到我希望访问的项目中的 AssemblyInfo.cs 中,但是,一旦我尝试编译,我就会收到相同的错误 “由于其保护级别而无法访问。”
编辑: 我确实忘记提及我正在使用全局管理程序集的sharedAssembly.cs,并以与我在本问题开头显示的示例程序集:InternalsVisibleTo
属性类似的方式设置了多个属性。 如果我的示例没有突出这一点,我也会使用强命名程序集。
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.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
事实证明,工作流程定义导致了差异。仍在尝试找出原因......
好吧,如果有人可以提供一个链接来解释为什么会从我这里得到+1。
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.
1)如果InternalsVisibleTo设置正确,则不需要反射来从“朋友”实例化它们,它可以直接使用ctor等。我会走这条路,以便 VS IDE 可以为您提供更快的反馈,了解目标项目的内部结构是否真正可见。
2)根据您后来收到的错误消息,您是否尝试过InternalsVisibleTo(“Stuff.Test.Support”)?
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") ?