나는 다음과 같은 상황이 : 모든 디렉토리에 같은 DLL의 싱글 톤 클래스는 여러 가상 디렉터리에 사용
하나의 싱글 톤 클래스는, 모든 가상 디렉터리 인스턴스에 대해 한 번만 생성이 싱글 톤 클래스 또는이 디 각각에 대해이 별도의 싱글 톤 클래스를 제공합니다. 싱글 톤은 그것을 사용하여 각 응용 프로그램에 대해 생성됩니다
[
Transaction(TransactionOption.Supported),
ClassInterface(ClassInterfaceType.AutoDispatch),
Guid("7DE45C4D-19BE-4AA4-A2DA-F4D86E6502A8")
]
public class SomeClass
{
private static readonly Singleton singleton = new Singleton();
:
코드는 다음과 같이 보입니다. 각 응용 프로그램은 각각 자신의 application domain에 있기 때문에 각 응용 프로그램은 서로 분리되어 있습니다.
다른 응용 프로그램에서 진정으로 싱글 톤 클래스를 사용하려면 정보를 보유한 공통 응용 프로그램 (예 : 원격 또는 WCF 등)과 통신해야합니다.
application pool은 해당 풀에서 프로세서 및 응용 프로그램이 액세스 할 수있는 메모리와 프로그램의 양을 제어합니다 (프로그램이 실행되는 계정과 함께). 그들은 여전히 서로 분리되어 있습니다.
II에서 각 가상 디렉터리에는 연결된 하나의 응용 프로그램이 있습니다. 응용 프로그램은 다른 응용 프로그램과 메모리 공간을 공유하지 않으므로 각 가상 디렉터리에 대해이 클래스의 새 인스턴스가있게됩니다.
이러한 모든 응용 프로그램에서 사용할 공유 응용 프로그램 풀을 만들 수 있습니다. 그러나이 경우 메모리는 공유되지만 각각은 해당 메모리를 사용하는 고유 한 프로세스를 갖게되며 각 고유 프로세스가 클래스를로드합니다.
같은 위치에있는 어셈블리 (DLL)를 .net CLR (같은 프로세스 (*)로 동일한 파일을 복사하더라도)에로드하면 CLR에서 각 어셈블리를 별도의 어셈블리로 처리하므로 형식 이 어셈블리에서 - 구문 적으로 동일한 (네임 스페이스 용어로도) - 여전히 다른 유형입니다!
동일한 응용 프로그램 컨텍스트 (OS 프로세스)에 있더라도 싱글 톤은 호출자간에 하나의 공통 인스턴스가 아니기 때문에 동일한 클래스의 세 개의 별도 정적 인스턴스가 있습니다. 또한 : 응용 프로그램 컨텍스트는 기본 경로 (ASP.Net의 경우 이것은 가상 디렉터리 임)로 정의됩니다 ... 웹 응용 프로그램이 모두 별도의 프로세스에서 실행된다는 추가 증거입니다 (Kevin은 맞습니다).
GAC (Global Assembly Cache)에는 여러 가지 문제가 있습니다.하지만 DLL 지옥에 대한 CLR 응답은 모든 파일을 처리하는 것입니다. 별도의 어셈블리와 다른 파일 (동일 복사본인지 아닌지) ... GAC 사용 - 어셈블리를 여러 컴퓨터로 복사하지 말 것을 강력히 권합니다. 그 외의 경우 : 그러한 파일 복사는 배포의 악몽입니다. GAC에는 부팅 할 수있는 모든 종류의 강력한 버전 관리 유틸리티가 함께 제공됩니다 (GAC 바인딩 정책 참조).
장기적인 솔루션을 지원하기를 원합니다 ...
Aidanapword
(*)이 반사를 사용하여 수행 할 수 있습니다 ... 좋은 생각 만 발생합니다.
첫 번째 메모 - IIS 6 및 7에서 실행하면 IIS가 AppPool 당 여러 프로세스를 사용하도록 허용하면 AppDomains는 별도의 작업자 프로세스에있을 수 있습니다. AppDomain은 적절한 역사적인 맥락에서이를 표현하기 위해 IIS AppPool 메커니즘이 모든 바이너리에 어떤 영향을 미치는지 에뮬레이트합니다. 많은 확장 성을 허용하며 많은 경우에 "싱글 톤 (singleton)"의 복사본이 몇 개 있는지 여부는 중요하지 않습니다. 이는 퍼포먼스를 향상시킬 수 있습니다.
정말로, 정말로, 나는 :-) 서버 수준의 싱글 톤이 필요하다는 것을 의미합니다. 리모컨 비용을 지불하지 않고 그것을 할 수있는 방법이 있지만, COM 또는 WinNT를 알고있는 경우에만 가능합니다. API.
WinNT 경로는 자원별로 가장 가벼운 편이지만 WinNT 작업을 완료해야만 C#이 아닌 C# - 공유 메모리, 이벤트 또는 WinNT 뮤텍스 등의 이유를 계속 묻는 메시지가 표시됩니다.
COM 경로를 사용하려면 proc 호출 (적절한 레지스트리 키)을 벗어나야하며 AutoDispatch 대신 AutoDual을 사용하고 싶을 수도 있습니다. 먼저 perf 및 second를 구입하여 .NET에 최소한의 가능성이 있는지 확인하십시오 그 dll을 "it 's own"으로 trerating합니다. gola는 proc 중 다른 것처럼 보이게하고 돌팔이 치게하는 것입니다. COM
중요한 질문은 - 왜 실제로 필요합니까? 빠른 이벤트 처리와 비교하여 캐싱이 목적이라면 매우 다른 전술을 사용해야합니다 (이 경우 MSMQ는 현재 WCF 우산 아래에 있습니다).