Как разрешить сборкам Reflection.Emit доступ к внутренним членам в генерирующей сборке?

Для одного из моих проектов мне нужно сгенерировать во время выполнения некоторые классы, и я подумал, что это будет довольно просто сделать с помощью Reflection.Emit, но я получаю исключения MemberAccessExceptions, когда запускаю часть сгенерированного кода, вызывающего методы, которые являются помечены как внутренние в сборке генератора. Есть ли способ сообщить среде выполнения, что динамическая сборка должна иметь прямой доступ к моему собственному коду? Я бы действительно предпочел не раскрывать никого из этих членов публично потребителям моей библиотеки.


Что касается InternalsVisibleTo, я не уверен, как я буду использовать его в случае динамически генерируемых сборок. Это вообще возможно?


person Alex Lyman    schedule 07.02.2009    source источник
comment
Вы пробовали InternalsVisibleTo?   -  person tuinstoel    schedule 07.02.2009


Ответы (2)


InternalsVisibleTo работает, открывая сборку другим пользователям. Поэтому, если вы хотите использовать сборку Foo из ваших сгенерированных типов, вы должны указать имя созданной сборки в AssemblyInfo.cs для Foo.

Если вы создаете новую сборку с использованием класса AssemblyBuilder, вы можете указать имя для созданной сборки. Это имя должно совпадать с именем, используемым для атрибута InternalsVisibleTo в сборке Foo.

person Brian Rasmussen    schedule 07.02.2009

Я полагаю, что есть причина того, что члены в вашей генерирующей сборке помечены как внутренние.

Вы можете либо предоставить необходимую функциональность в общедоступных методах, либо у вас останется только два варианта: InternalsVisibleTo (как @tuinstoel, упомянутый в разделе комментариев) или Reflection (с помощью отражения вы можете получить доступ к непубличным членам в разных сборках).

person Darin Dimitrov    schedule 07.02.2009
comment
Я не уверен, как я буду использовать его в случае динамически генерируемых сборок. Это вообще возможно? - person Alex Lyman; 07.02.2009