Порой наши библиотеки могут содержать некоторый функционал, который мы активно используем в составе сборки, но который мы бы не хотели делать общедоступным. Такие методы и классы, как правило, объявляются с модификатором доступа 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 элементы, дополнительно помечая их "сердечком".
Комментариев нет:
Отправить комментарий