2009-02-02 4 views
7

여러 웹 서비스를 사용하는 웹 응용 프로그램 (ASP.NET 3.5)을 개발 중입니다. 각 웹 서비스에 대해 별도의 dll 프로젝트를 만들었습니다.이 프로젝트에는 서비스 참조 및 클라이언트 코드가 포함되어 있습니다.별도의 dll 프로젝트에서 WCF를 구성하는 방법

그러나이 정보가 dll의 app.config 파일에도 있지만 호출하는 웹 사이트는 <system.serviceModel> 정보 (<bindings><client> 노드)가 web.config에 있어야합니다. serviceclass.dll.config를 웹 사이트의 bin 디렉토리에 복사하려고 시도했지만 도움이되지 않았습니다.

WCF 클라이언트의 구성을 중앙 집중화 할 수있는 방법이 있습니까?

+0

이 질문에 대한 답변을 얻으려면 http://stackoverflow.com/a/839941/592732 – MarioVW

답변

4

저는 WCF 환경이 제한되어 있으며, 모두 BasicHTTP 바인딩을 사용하고 있습니다. 하지만 난 WCF의 XML 파일에 알레르기 반응을 보이며 그걸 피할 ​​수 있었다. 이 방법을 일반적으로 권장하지는 않지만 구성 정보를 기존의 구성 저장소에 저장 한 다음 프로그래밍 방식으로 적용합니다. 예 : 웹 서비스 프록시를 사용하면 'bindings'및 'endpoint'를 사용하는 클라이언트 용 생성자를 사용하고 프로그래밍 방식으로 바인딩을 & 바인딩에 적용합니다.

좀 더 우아한 해결책이 여기에 나와 있습니다. Reading WCF Configuration from a Custom Location하지만 아직 시도하지 않았습니다.

+0

감사합니다. 제공하신 링크를 작성하려고 시도했습니다. – edosoft

3

xml 구성을 무시하고 생성자 또는 사용자 지정 "Service Factory"에서 서비스와 관련된 바인딩 및 끝점 클래스를 빌드하는 것이 가능합니다. IDesign의이에 대한 몇 가지 좋은 정보가 있습니다 http://www.idesign.net/idesign/DesktopDefault.aspx?tabindex=5&tabid=11 (PROC 공장에서 참조) 그들의 접근에서

, 당신은 그들이 작동하는 방법을 높은 수준에서 지정하여 서비스에 대한 속성을 설정 (즉 [인터넷], [인트라넷] , [BusinessToBusiness]) 서비스 팩토리는 각 시나리오에 대한 모범 사례에 따라 서비스를 구성합니다. http://www.amazon.com/Programming-WCF-Services-Juval-Lowy/dp/0596526997

방금 ​​구성 XML 설정을 공유하려면, 어쩌면 configSource 구성에 대한 경로를 지정하는 속성을 사용합니다 : 내 경험에서 http://weblogs.asp.net/cibrax/archive/2007/07/24/configsource-attribute-on-system-servicemodel-section.aspx

4

를 라이브러리 프로젝트는 읽어 본 적이 그들의 책은 서비스의 종류를 구축 설명 app.config.

정말 사용하지 않기 때문에 파일을 삭제할 수 있습니다. 라이브러리의 호스트 구성이 대신 읽혀 지므로 엔드 포인트와 바인딩 구성이 있어야하는 유일한 위치입니다.

+1

정확하게 - 앱에서 호스팅/사용하는 DLL이있는 경우 앱의 구성 만 중요합니다 .NET 기본 설계 결정이므로 별도의 DLL DLL의 app.config 파일에있는 설정이 AT ALL ALL .... :-(사용하지 마십시오. –

3

구성 파일은 진입 점이있는 실행 파일로 읽습니다. 라이브러리 dll에는 엔트리 포인트가 없으므로이를 읽는 어셈블리가 아닙니다. 실행중인 어셈블리에는 읽을 구성 파일이 있어야합니다.

웹 구성을 중앙 집중화하려면 IIS에서 가상 디렉터리를 중첩시켜야합니다. 이렇게하면 구성 상속을 사용하여 필요한 모든 것을 중앙 집중식으로 관리 할 수 ​​있습니다.

0

우선 클래스 라이브러리 (DLL)는 자체 구성을 가지고 있지 않지만 호스트 (웹/실행 파일 등)의 구성을 읽을 수 있습니다. 즉, 템플릿과 쉬운 참조로 라이브러리 프로젝트의 app.config 파일을 유지합니다.

WCF 구성은 서비스 구성 자체와 관련하여 누군가 쉽게 머리카락을 꺼낼 수 있습니다. 그것은 지나치게 복잡하고 지나치게 복잡한 조각입니다.응용 프로그램의 목표는 최소한 구성에 의존하는 동시에 제품 배포 시나리오의 유연성을 유지해야합니다.

1

두 가지 옵션이 있습니다.

옵션 1. 채널을 사용한 작업.

채널로 직접 작업하는 경우 .NET 4.0 및 .NET 4.5는 ConfigurationChannelFactory입니다. MSDN의 예는 다음과 같습니다

var factory1 = new ConfigurationChannelFactory<ICalculatorChannel>(
     "endpoint1", 
     newConfiguration, 
     null); 
ICalculatorChannel client1 = factory1.CreateChannel(); 

이 설명되어 있습니다 :

랭던에 의해 지적
ExeConfigurationFileMap fileMap = new ExeConfigurationFileMap(); 
fileMap.ExeConfigFilename = "Test.config"; 
Configuration newConfiguration = ConfigurationManager.OpenMappedExeConfiguration(
    fileMap, 
    ConfigurationUserLevel.None); 

ConfigurationChannelFactory<ICalculatorChannel> factory1 = 
    new ConfigurationChannelFactory<ICalculatorChannel>(
     "endpoint1", 
     newConfiguration, 
     new EndpointAddress("http://localhost:8000/servicemodelsamples/service")); 
ICalculatorChannel client1 = factory1.CreateChannel(); 

, 당신은 단순히 다음과 같이 null을 전달하여 구성 파일에서 엔드 포인트 주소를 사용할 수 있습니다 MSDN documentation에서 확인하십시오.

옵션 2. 프록시 작업.

코드 생성 프록시로 작업하는 경우 구성 파일을 읽고 ServiceModelSectionGroup을로드 할 수 있습니다. 단순히 ConfigurationChannelFactory하지만를 사용하는 것보다 참여 좀 더 많은 작업이 적어도 당신이 할 수있는 후드 아래 ChannelFactory을 사용하고 당신을 위해 IChannelFactory을 관리하는 (생성 된 프록시를 사용하여 계속합니다.

파블로 Cibraro 여기이의 좋은 예를 보여줍니다 : Getting WCF Bindings and Behaviors from any config source