Проблема, с которой вы сталкиваетесь, заключается в том, что SharePoint использует Code Access Security (CAS), чтобы дать действительно хорошо образованным администраторам возможность убедиться, что они не подвергают свою среду ненужному риску при добавлении функциональности к ней.
Проблема в том, что, хотя CAS и был в .Net с самого начала, почти никто не использовал его до SharePoint, поэтому большинство разработчиков не знают, как с этим справиться.
Все в _app_bin работает с полным доверием, что объясняет, почему там работает ваша dll.
Все в bin работает с гораздо меньшим доверием, в зависимости от уровня доверия, указанного в web.config (на самом деле это также тот, который указывает, что _app_bin имеет полное доверие, но это распространено на всех уровнях доверия из коробки) ).
Для того, чтобы заставить вашу dll работать из bin (без изменения уровня доверия на полный, что плохо), вам нужно изменить файл политики, на который указывает уровень доверия, с правильным xml для того, который вам нужен.
Добавление атрибутов не помогает вам напрямую, изначально они фактически только усугубляют проблему, потому что теперь ваша dll требует прав, даже если она может не вызывать ничего, что требует их.
Атрибуты помогут вам, если вы используете WSPBuilder для создания пакета WSP для развертывания в SharePoint (вы используете право WSP), тогда он будет искать атрибуты безопасности и делать соответствующие записи в manifest.xml, которые затем заставляют SharePoint добавлять соответствующие записи в файл политики при развертывании.
Чтобы атрибуты работали с WSPBuilder, я думаю, что они должны быть изменены на SecurityAction.Demand.