Честность 2 тривиальна.Вы можете легко скопировать файл конфигурации в каталог сборки.Простой поиск в Google может дать вам все, что вам нужно.
Для части 1 у вас есть варианты, я бы предложил просто определить API для вашего сервиса в форме интерфейса.Затем с помощью DI подключить «реализацию» через DLL.Это делается постоянно с использованием Adapter Pattern , а затем с использованием чего-то вроде Unity для реализации во время выполнения.
PSEUDO:
interface IMyServiceAdaptor {
void SomeMethod(params );
void SomeMethod2(params );
}
public class ServiceAdaptor : IMyServiceAdaptor{
#psudo code
ServiceProxyClient client { get;set;}
public void SomeMethod(parms){
var convertedParams = Convert(parms);
return client.SomeMethod(convertedParams );
}
...etc
}
public class MyClient {
[Dependancy]
IMyServiceAgent agent { get;set;}
public MyClient(){
#resolve
}
}
Концепция проста.У вас есть внутреннее представление вашего сервиса (IMyServiceAdaptor).Важно, чтобы он полностью не зависел от базовых прокси-вызовов (сервисных ссылок), которые фактически вызывают ваш сервис.Идея в том, что вы создаете дружественный интерфейс для своего сервиса и взаимодействуете с ним.Вы всегда адаптируете сервис под API вашего интерфейса приложений.Это защитит вас от изменений на стороне службы, предоставит интерфейс, который вы можете использовать для внедрения, а также позволит вам вставить дополнительную логику для решения проблем.