вторник, 20 мая 2014 г.

InternalsVisibleTo и Intellysience

Порой наши библиотеки могут содержать некоторый функционал, который мы активно используем в составе сборки, но который мы бы не хотели делать общедоступным. Такие методы и классы, как правило, объявляются с модификатором доступа internal. Если программист желает разрешить доступ к этому функционалу из внешних сборок, то в целевой сборке он помечает их как дружественные, при помощи атрибута сборки InternalsVisibleTo. Однако может случиться так, что в дружественной сборке Intellysience откажется показывать то, что в целевой было объявлено с модификатором internal. При этом компиляция проектов по прежнему будет проходить благополучно.

Например, программист может писать тесты для своего плагина AutoCAD, разместив код этих тестов в отдельном проекте. В этом случае, дабы не объявлять весь тестируемый функционал как public, он может быть объявлен как internal, после чего в коде плагина добавляется соответствующий атрибут сборки:

   1:  #if DEBUG
   2:  // Объявляем сборку acad_plugin_tests дружественной
   3:  [assembly: InternalsVisibleTo("acad_plugin_tests")] 
   4:  #endif

Т.о. проект acad_plugin_tests содержащий тесты, объявляется дружественным для отладочного варианта нашей сборки, что даёт нам возможность добраться до функционала, подлежащего тестированию. При компиляции Release версии сборка acad_plugin_tests уже не будет объявлена дружественной.

Однако, если вы вдруг обнаружите, что в процессе написания кода в дружественной сборке не отображаются элементы, помеченные в целевой как internal:


то для решения этой проблемы следует удалить *.suo файлы, находящиеся в каталоге нашего решения, рядом с *.sln файлом:


Как видим, теперь в коде дружественной сборки Intellysience отображает в т.ч. и internal элементы, дополнительно помечая их "сердечком".

Комментариев нет: