Мой FlatFiles проект использует System.Reflection.Emit для генерации десериализаторов / сериализаторов во время выполнения для чтения / записи файлов CVS и т. Д. До недавнего времени я мог просто использовать DynamicMethod, передавая true для параметр конструктора restrictedSkipVisibility .
Новые функции, над которыми я работаю, требуют создания класса во время выполнения вместо простого метода. Я смог реализовать новую логику, используя AssemblyBuilder / ModuleBuilder / TypeBuilder / и т. Д. Однако я сталкивался с проблемами всякий раз, когда мне нужно было получить доступ к internal проектным классам. Для этого я добавил атрибут [InternalsVisibleTo] в мой файл Assembly.cs, предоставив видимость моей динамической сборке.
Когда я смотрю на такие проекты, как Castle.DynamicProxy.Core , я вижу, что они также полагаются на [InternalsVisibleTo]. Глядя на другие проекты , использующие DynamicProxy, я вижу, что они добавляют один и тот же атрибут. Любой, кто использует эти библиотеки, должен также добавить атрибут: пример . Даже в этом случае не предоставляется доступ к private классам и членам.
Из того, что я читаю онлайн, звучит так, что пропустить проверки видимости просто невозможно при использовании динамических сборок. Это правда? Я просто ищу подтверждение.
Мои исследования также показывают, что способность DynamicMethod пропускать проверки видимости работает только в определенных средах. Другими словами, FlatFiles не будет работать в более ограничительной среде (например, в Интернете). Это правда? Это может быть оправданием для того, чтобы заставить моих пользователей добавлять атрибут [InternalsVisibleTo] в свои проекты в будущем.