2011-09-22 5 views
0

Windows 및 웹 모두에서 사용되는 공유보고 dll이 있습니다. 지금은 Windows 프로그램을 .NET 4 클라이언트 프로파일로 이동하려고 시도하고 있으므로 System.Web 참조를 피할 필요가 있습니다.System.Web 참조를 피하기 위해 반사

일부 지점에서 코드는 웹 사이트의 디렉토리 또는 dll 디렉토리를 가져와야합니다.

string path; 
if (HttpContext.Current != null) 
{ 
    path = HttpContext.Current.Server.MapPath("default.aspx"); 
} 
else 
{ 
    path = Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location); 
} 

난 아직 적절한 경로를 얻을 수 있도록 System.Web 참조를 방지하기 위해 반사 또는 유사한을 사용하는 방법이 있나요 :이 같은 코드 뭔가를 사용? 그렇다면 어떻게해야합니까?

어떤 대안이 있습니까?

편집 이 나는 ​​스타일 시트 파일을 보고서에 적용 할 수 있습니다보고 시스템을 사용하는 것입니다 내가하고 싶은 이유 (나는 모든 보고서에 대해이 작업을 수행). 내가 이전에 DLL 자체에서 가지고 있던 설정으로 mystylesheet.repss.So 스타일을 변경하려면 dll에서 변경하고 모든 보고서에 적용됩니다. 그런 다음 적절한 repss 파일을 Windows 및 웹 사이트의 루트 디렉토리에 저장하는 경우입니다. 그리고 그들에게 적절한 경로를 찾는다.

dll로 상대 경로를 사용하면 문제가 발생합니다. 보고서. \ mystylesheet.repss는 Windows에서 제대로 작동하지만 ~/mystylesheet.repss. \ mystylesheet.repss 또는 웹의 dll에서 생각할 수있는 다른 내용은 잘못된 디렉토리 "c : \ windows \ system32 \ inetsrv ".

나는 각기 다른 창과 웹 응용 프로그램으로 설정을 옮겨서 전체 경로와 함께 전달할 수 있습니다. 실제로는 dll에 대한 내부 설정 일 때 거꾸로 표시됩니다.

모두 의미가 있습니다.

+0

클라이언트 코드에서 기본 경로를 라이브러리로 전달하는 것이 좋지 않습니까? – Lazarus

+0

그럴 수는 있지만 할 필요가없는 것을 선호합니다. 나는 왜 내가 이것을하고 싶은지를 설명하기 위해 편집을 추가하고있다. – PeteT

답변

2

AppDomain.BaseDirectory에 상대적인 경로를 사용하지 않는 이유는 무엇입니까?

이 파일은 ASP.NET 용 웹 응용 프로그램의 루트 디렉터리이고 콘솔 또는 WinForms 응용 프로그램 용 실행 파일이 들어있는 디렉터리입니다.

다른 응용 프로그램 유형의 경우 일반적으로 적절한 기본 위치가됩니다. 예를 들어 VSTO 2005 응용 프로그램에서는 Excel에 대한 경로가 아니라 응용 프로그램에 대한 VSTO 관리되는 어셈블리가 들어있는 디렉터리가됩니다 실행 파일.

해당하는 경우 기본 설정 인 기본 디렉토리에서 DLL 호출자가 대체 위치를 지정할 수 있도록 선택적 구성 설정 (예 : appSetting)을 지원할 수 있습니다.

또 다른 옵션은 발신자가 스타일 시트 파일의 경로를 지정하도록 허용하는 것입니다.이 경로는 절대적이거나 상대적 일 수 있습니다. 친척 인 경우 AppDomain.BaseDirectory에 상대적으로 지정하십시오. 상대 경로를 사용하는 경우,이 응용 프로그램의 수명 동안 변경 및 응용 프로그램의 기본 디렉토리와 동일하지 않습니다 수있는 현재 작업 디렉토리에 상대적 될 것

if (!Path.IsPathRooted(stylesheetPath)) 
{ 
    stylesheetPath = Path.Combine(
          AppDomain.CurrentDomain.BaseDirectory, 
          stylesheetPath); 
} 
... 

참고.

+0

그게 내 문제를 정렬했습니다. 고마워, 나는 AppDomain이 IIS에서 뭔가 다른 것을 생각해 낼 것이라고 생각했지만 사이트로의 정확한 경로를 얻는다. – PeteT

0

위치를 결정하는 메커니즘이 컨텍스트에 따라 다르면 호출자가 생성자 또는 메서드 매개 변수 또는 이와 비슷한 것으로 전달하는 것이 적절하다고 판단됩니다. 그것이 "경로 해석자"로서 Func<string, string>과 같이 똑 바른 경로 일지 여부는 정확하게 수행해야하는 작업에 달려 있습니다.

+0

한 번 나는 Jon Skeet에 동의해야합니다. 일부 상황에서는 호출자가 경로 해석자를 제공하는 것이 바람직 할 수 있지만, AppDomain.BaseDirectory를 사용하는 것과 같은 합리적인 기본값을 제공하는 것보다는 그를 강제로 수행하는 것이 바람직하지 않습니다. – Joe

+0

@Joe : 사용 방법에 따라 달라집니다. 나는 이런 종류의 의존성을 명시 적으로 만드는 것에 매우 열중하고 있습니다. 호출자가 무엇을해야할지 결정하게하고,'AppDomain.BaseDirectory' *가 적절할지도 모른다는 문서를 지적하십시오. 이것은 시간대와 비슷합니다. 호출자가 명시 적으로 선택하도록하기 위해 Noda Time의 특정 시간대에 고의로 * 기본값으로 설정하지 않았습니다. –

+0

그것은 물론 트레이드 오프입니다. 그러나 적절한 기본값을 사용할 수 있다면 API가 더 일반적으로 유용하다고 생각합니다. Noda Time은 좀 더 일반적인 DateTime 및 DateTimeOffset 유형보다 구체적인 사용 사례를 다룰 예정이므로 선택이 맞을 수도 있습니다. 그러나 또 다른 유추는'String.Format'일지도 모르지 만, 현재 문화권에 대한 불이행이 올바른 선택 인 IMHO는 모든 사람이 동의하지는 않습니다. 이는 "컨벤션 오버 컨피규레이션"디자인 패턴을 고려할 때의 상반 관계와 다소 비슷하지만, 프로그래머 스택 익스체인지 사이트에는 어떤 논의가 가장 적합 할 것이다. – Joe

관련 문제