Может ли отражение когда-либо потерпеть неудачу в C #?

Question

У нас есть приложение, которое мы разрабатываем на C #. Мы храним все ресурсы в центральной библиотеке DLL, ресурс содержит изображения, значки и строки, из которых мы поддерживаем несколько культур.

Мы получаем доступ к ресурсам из любого проекта в решении, используя следующий код:

private ResourceManager ResMan;
ResMan = new ResourceManager("libResx.Resource", Assembly.ReflectionOnlyLoad("libResx"));

Затем мы получаем доступ к любому элементу ресурса, используя;

btnClose.Text = ResMan.GetString("btnClose");

Помимо отсутствующей библиотеки ресурсов, есть ли что-то, что может вызвать отражение, чтобы не найти библиотеку ресурсов (сборку). До сих пор в тестировании это было безупречно, есть ли что-то, о чем мы должны знать, когда это в конечном счете развернуто в дикой природе?

Может ли отражение потерпеть неудачу?

Answer 1

Может произойти сбой. Вы можете присвоить сборку, чтобы предотвратить отражение от другой сборки за пределами того же пространства имен.

Answer 2

Просмотрите справочную документацию для каждого из этих API, чтобы увидеть список исключений, которые может выдать каждый API.

Answer 3

Отражение чрезвычайно полезно, однако оно может потерпеть неудачу и по более практическим причинам.

Это случилось со мной совсем недавно в веб-приложении MVC (Castle MVC, Windsor, Brail & Boo). Когда скрипт boo компилирует и получает доступ к списку из пакета свойств, он использует отражение, чтобы идентифицировать подпись MyModel, чтобы он мог затем ссылаться на атрибуты для представления.

В этом случае отражение не удалось в том случае, если более старые записи базы данных MyModel больше не синхронизировались с новой моделью, поскольку старые данные имели нулевые значения для некоторых новых атрибутов или свойств MyModel. Это не было проблемой для новых записей, которые имели значения в новых полях атрибутов.

Как общее практическое правило, я бы зарегистрировал вашу сборку как зависимость и поместил пространство имен в ваше предложение using. Это дает компилятору четкие цепочки зависимостей при компиляции. Это также облегчает другим разработчикам определять, от чего зависит конкретная библиотека, вместо того, чтобы перебирать кучу кода, чтобы найти скрытый вызов Assembly.Reflection.OnLoad для внешней библиотеки DLL.

Кроме того, если вы ожидаете, что ваш ResourceManager сильно изменится, вам следует подумать о том, чтобы полностью разделить его на отдельную dll. (В соответствии с принципами SOLID OOP Design). Это делает ваше приложение более модульным, и если вам когда-либо понадобится обновить сборку ресурсов, вы перекомпилируете только те библиотеки, на которые это влияет.

Дядя Боб - Принципы ООД (ТВЕРДЫЕ)

Answer 4

По своему опыту я обнаружил, что вместо зависимости от имени сборки указание полного пути является более надежным. Вы можете использовать Assembly.ReflectionOnlyLoadFrom вместо.