Метод C#, который выполняется после блока, загружается
Откройте приложение xampp, затем выполните следующие действия:
-
перейдите к: томам,
-
нажмите кнопку [mount] и
-
, наконец, нажмите исследовать.
5 ответов
Я довольно часто использовал Ninject за последние 9 месяцев. Похоже, что вам нужно «загрузить» ваши модули, существующие в вашей библиотеке, в ядро Ninject, чтобы зарегистрировать привязки.
Я не уверен, используете ли вы Ninject 1.x или бета-версию 2.0. Две версии работают немного по-разному, хотя концептуально они одинаковы. Для этого обсуждения я буду придерживаться версии 1.x. Другая часть информации, которую я не знаю, заключается в том, создает ли ваша основная программа экземпляр ядра Ninject, а ваша библиотека просто добавляет привязки к этому ядру, или ваша библиотека сама содержит ядро и привязки. Я предполагаю, что вам нужно добавить привязки в вашей библиотеке к существующему ядру Ninject в основной сборке. Наконец я' Предположим, что вы загружаете эту библиотеку динамически и что она не связана статически с основной программой.
Первое, что нужно сделать, это определить модуль ninject в своей библиотеке, в котором вы регистрируете все свои привязки - возможно, вы уже это сделали, но об этом стоит упомянуть. Например:
public class MyLibraryModule : StandardModule {
public override void Load() {
Bind<IMyService>()
.To<ServiceImpl>();
// ... more bindings ...
}
}
Теперь, когда ваши привязки содержатся в модуле Ninject, вы можете легко зарегистрировать их при загрузке сборки. Идея состоит в том, что как только вы загрузите свою сборку, вы можете сканировать ее для всех типов, производных от StandardModule. Когда у вас есть эти типы, вы можете загрузить их в ядро.
// Somewhere, you define the kernel...
var kernel = new StandardKernel();
// ... then elsewhere, load your library and load the modules in it ...
var myLib = Assembly.Load("MyLibrary");
var stdModuleTypes = myLib
.GetExportedTypes()
.Where(t => typeof(StandardModule).IsAssignableFrom(t));
foreach (Type type in stdModuleTypes) {
kernel.Load((StandardModule)Activator.CreateInstance(type));
}
Следует отметить, что вы можете еще больше обобщить приведенный выше код для загрузки нескольких библиотек и регистрации нескольких типов. Кроме того, как я упоминал выше, Ninject 2 имеет встроенные возможности такого рода - на самом деле он может сканировать каталоги, загружать сборки и регистрировать модули. Очень круто.
Если ваш сценарий немного отличается от того, что я обрисовал в общих чертах, аналогичные принципы, вероятно, могут быть адаптированы.
Похоже, вы ищете эквивалент C ++ DllMain. В C # это невозможно сделать.
Не могли бы вы предоставить нам дополнительную информацию о своем сценарии и о том, почему вам нужен код для выполнения в функции стиля DllMain?
Определение статического конструктора для типа не решает эту проблему. Конструктор статического типа гарантированно запускается только до того, как сам тип будет использован каким-либо образом. Вы можете определить статический конструктор, использовать другой код в Dll, который не имеет доступа к типу, и этот конструктор никогда не запустится.
Вы пробовали событие AppDomain.AssemblyLoad ? Он срабатывает после загрузки сборки.
AppDomain.CurrentDomain.AssemblyLoad += (s, e) =>
{
Assembly justLoaded = e.LoadedAssembly;
// ... etc.
};
Можете ли вы управлять кодом клиента? Если да, вместо того, чтобы пытаться творить чудеса при загрузке сборки, я бы пошел на реализацию одного класса, такого как Registry, который выполняет привязки, реализуя интерфейс IRegistry. Затем во время загрузки вы можете искать реализацию IRegistry в вашей сборке и запускать необходимые методы.
Вы также можете иметь атрибуты в своих классах:
[Component(Implements=typeof(IMyDependency)]
ищите эти атрибуты и загружайте их в контейнер на стороне клиента.
1294] Или вы можете взглянуть на MEF , которая представляет собой библиотеку для подобных ситуаций.
Насколько я знаю, ответ отрицательный . Насколько я понимаю, вы хотите настроить свой контейнер IoC в своей библиотеке классов, и если это так, это не лучшая идея. Если вы определяете свои привязки в своей библиотеке классов, тогда какой толк от внедрения зависимостей? мы используем внедрение зависимостей, чтобы мы могли внедрять зависимости во время выполнения, а затем мы можем внедрять различные объекты в разных сценариях. Хотя лучшее место для настройки контейнера IoC - это запуск вашего приложения (поскольку контейнер IoC похож на основу для приложения :)) но он должен быть размещен в начальной загрузке, которая отвечает за запуск приложения. В простых приложениях это может быть метод Main.