Могу ли я автоматически размещать все службы в app.config при использовании SelfHosting?

Question

Я пишу приложение, которое должно разместить несколько служб WCF. Одной из сильных сторон WCF является возможность настраивать службы без перекомпиляции, указав параметры в файле app.config.

При самостоятельном размещении не существует готового способа автоматического размещения служб, которые находятся в файле app.config. Я нашел этот вопрос, в котором упоминается возможное решение для динамического перечисления сервисов, перечисленных в app.config во время выполнения, и создания ServiceHost для каждого.

Тем не менее, мои сервисы, контракты и хостинговое приложение находятся в разных сборках. Это вызывает Type.GetType(string name) не удается найти тип моей службы (возвращает null) потому что он определен в другой сборке.

Как надежно разместить все службы, перечисленные в файле app.config, динамически (т. Е. Без жесткого программирования)? new ServiceHost(typeof(MyService)) в моем приложении для самостоятельного размещения?

Примечание. Мой app.config был создан с помощью "Редактора конфигурации WCF" в Visual Studio 2010.

Также обратите внимание: моя основная цель - чтобы это управлялось файлом app.config, чтобы была единственная точка конфигурации. Я не хочу настраивать это в отдельном месте.

РЕДАКТИРОВАТЬ: я могу прочитать файл app.config (см. Здесь), но мне нужно иметь возможность разрешать типы в разных сборках.

РЕДАКТИРОВАТЬ: один из ответов ниже побудил меня попытаться указать AssemblyQualifiedName в app.config вместо только основного имени типа. Это удалось обойти Type.GetType() проблема, однако ServiceHost.Open() сейчас терпит неудачу с InvalidOperationException независимо от того, как я достигну типа:

// Fails
string typeName = typeof(MyService).AssemblyQualifiedName;
Type myType = Type.GetType(typeName);
ServiceHost host = new ServiceHost(myType);
host.Open(); // throws InvalidOperationException

// Also fails
Type myType2 = typeof(MyService);
ServiceHost host2 = new ServiceHost(myType2);
host2.Open(); // throws InvalidOperationException

Детали исключения:

Service 'SO.Example.MyService' has zero application (non-infrastructure) endpoints. This might be because no configuration file was found for your application, or because no service element matching the service name could be found in the configuration file, or because no endpoints were defined in the service element.

Я предполагаю, что WCF пытается сопоставить буквенную строку для имени службы при внутреннем анализе файла app.config.

РЕДАКТИРОВАТЬ / ОТВЕТ: То, что я в итоге сделал, было в основном то, что было в ответе ниже. Вместо того, чтобы использовать Type.GetType() Я знаю, что все мои сервисы находятся в одной сборке, поэтому я переключился на:

// Get a reference to the assembly which contain all of the service implementations.
Assembly implementationAssembly = Assembly.GetAssembly(typeof(MyService));
...
// When loading the type for the service, load it from the implementing assembly.
Type implementation = implementationAssembly.GetType(serviceElement.Name);

Answer 1

Вы правильно определили ответ на свою проблему в своей ссылке на вопрос, и ответ @marc_s также дает правильный подход. Фактическая проблема, с которой вы столкнулись, заключается в том, что вам необходимо динамически получать экземпляр Type сборки, на который можно ссылаться только через файл конфигурации, чтобы он не мог быть загружен в текущий домен приложения.

Посмотрите на этот пост в блоге, чтобы найти способ динамически ссылаться на сборки в вашем коде. Хотя эта статья предназначена специально для приложений ASP.NET, общий подход должен работать в автономном сценарии. Идея состоит в том, чтобы заменить вызов Type.GetType (string) закрытым вызовом метода, который динамически загружает запрошенную сборку (если необходимо) и возвращает объект Type. Параметр, который вы отправляете этому методу, по-прежнему будет element.Name, и вам необходимо выяснить, какая сборка является правильной для загрузки. Должна работать простая схема именования сборок на основе соглашения. Например, если тип сервиса:

MyNamespace.MyService.MyServiceImpl

тогда предположим, что сборка:

MyNamespace.MyService

Answer 2

    // get the <system.serviceModel> / <services> config section
    ServicesSection services = ConfigurationManager.GetSection("system.serviceModel/services") as ServicesSection;

    // get all classs
    var allTypes = AppDomain.CurrentDomain.GetAssemblies().ToList().SelectMany(s => s.GetTypes()).Where(t => t.IsClass == true);

    // enumerate over each <service> node
    foreach (ServiceElement service in services.Services)
    {
        Type serviceType = allTypes.SingleOrDefault(t => t.FullName == service.Name);
        if (serviceType == null)
        {
            continue;
        }

        ServiceHost serviceHost = new ServiceHost(serviceType);
        serviceHost.Open();
    }

Основываясь на других ответах, я расширил код до следующего, который ищет во всех сборках службы в app.config

Answer 3

Это определенно должно быть возможно! Проверьте этот фрагмент кода - используйте его в качестве основы и перейдите отсюда:

using System.Configuration;   // don't forget to add a reference to this assembly!

// get the <system.serviceModel> / <services> config section
ServicesSection services = ConfigurationManager.GetSection("system.serviceModel/services") as ServicesSection;

// enumerate over each <service> node
foreach(ServiceElement aService in services.Services)
{
    Console.WriteLine();
    Console.WriteLine("Name: {0} / Behavior: {1}", aService.Name, aService.BehaviorConfiguration);

    // enumerate over all endpoints for that service
    foreach (ServiceEndpointElement see in aService.Endpoints)
    {
        Console.WriteLine("\tEndpoint: Address = {0} / Binding = {1} / Contract = {2}", see.Address, see.Binding, see.Contract);
    }
}

Это прямо сейчас просто выводит информацию - но вы определенно можете использовать это для фактического построения хостов вашего сервиса внутри вашего собственного сервиса NT!

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

В этом случае вам необходимо динамически загружать эти сборки по мере необходимости - вы можете, например, "просто знать", какие сборки загружать, или вы можете поместить их все в определенные подкаталоги и загружать все сборки в этом каталоге, или вы можете просто осмотрите все сборки в том же месте, где ваш MyOwnServiceHost.exe проживает и проверьте, если вы найдете какие-либо типы, которые вам нужны.

Эта часть - какой тип сервиса нужно найти, в какой сборке - не обрабатывается конфигурацией WCF - вам нужно сделать это самостоятельно, в зависимости от того, что для вас наиболее целесообразно.

// find currently executing assembly
Assembly curr = Assembly.GetExecutingAssembly();

// get the directory where this app is running in
string currentLocation = Path.GetDirectoryName(curr.Location);

// find all assemblies inside that directory
string[] assemblies = Directory.GetFiles(currentLocation, "*.dll");

// enumerate over those assemblies
foreach (string assemblyName in assemblies)
{
   // load assembly just for inspection
   Assembly assemblyToInspect = Assembly.ReflectionOnlyLoadFrom(assemblyName);

   if (assemblyToInspect != null)
   {
      // find all types
      Type[] types = assemblyToInspect.GetTypes();

      // enumerate types and determine if this assembly contains any types of interest
      // you could e.g. put a "marker" interface on those (service implementation)
      // types of interest, or you could use a specific naming convention (all types
      // like "SomeThingOrAnotherService" - ending in "Service" - are your services)
      // or some kind of a lookup table (e.g. the list of types you need to find from
      // parsing the app.config file)
      foreach(Type ty in types)
      {
         // do something here
      }
   }
}