역할 캐시 및 Windows Server AppFabric Azure 동일한 솔루션의 캐시

Question

우리는 Azure 응용 프로그램을 사내 구축 형 데이터 센터로 마이그레이션하고 있습니다. Azure 패키지를 Cloud 서비스에 배포 할 때 Azure를 Role Cache에 사용해야합니다. Windows Server On-Premise에 배포 할 때 Windows Server AppFabric Cache를 사용해야합니다. 어떻게 하나의 솔루션으로 작동합니까?

우리는 푸른 SDK V 2.2 클라이언트 어셈블리와 역할 캐시에 푸른에 연결

자세한 설명.

Microsoft.ApplicationServer.Caching.Client.dll, assembly version 1.0.0.0, file version 1.0.5137.0 
Microsoft.ApplicationServer.Caching.Core, assembly version 1.0.0.0, file version 1.0.5137.0 

instalation과 함께 제공되는 클라이언트 어셈블리를 사용하여 Windows Server AppFabric Cache v 1.1에 연결합니다.

Microsoft.ApplicationServer.Caching.Client.dll, assembly version 1.0.0.0, file version 1.0.4632.0 
Microsoft.ApplicationServer.Caching.Core, assembly version 1.0.0.0, file version 1.0.4632.0 

비전 문제는 Windows Server AppFabricCache, Exception, Check the client version 스레드에서 처리됩니다.

문제는 우리의 메인 웹 프로젝트가 중복 된 이름과 버전을 가진 모든 언급 된 어셈블리에 대한 참조로 끝납니다. 우리는 그것을 통해 자신의 길을 해킹하고 싶지 않을 것입니다. 최악의 경우에서부터 나쁘지 않은 경우까지 옵션은 사용자 지정 어셈블리로드를 만들거나 빌드 프로세스를 수정하는 것입니다. 선호하는 방법은 무엇입니까? 우리가 길에서 큰 시간을 벗어 났습니까?

Answer 1

동일한 프로젝트에서 azure SDK 라이브러리와 온 프레미스 라이브러리를 모두 캐시에 사용할 수는 없습니다. 온 - 프레미스의 경우 설치 폴더에있는 클라이언트 라이브러리를 사용하고 Azure SDK의 클라이언트 라이브러리를 사용해야합니다.

서버와 클라이언트가 동일한 프로젝트에 묶여있는 이유가 있다면 관리 캐시를 사용하는 것이 좋습니다. 새로운 캐시백 솔루션을 사용하면 최소한의 구성 수준 변경으로 역할 내에서 사용하는 동일한 클라이언트를 사용할 수 있습니다. 그것을 작동하게합니다. 여기서 서버는 서비스 팀 자체에서 관리하는 SLA 등을 가동 시키므로 이들에 대해 신경 쓸 필요가 없습니다.

온 프레미스로 완전히 이동하려면 예, Windows 용 Appfabric 서버가 가장 좋은 솔루션입니다. 그러나 일반적으로 전 세계 곳곳의 트래픽이있는 웹 사이트에서 캐시에 대한 하늘빛 솔루션의 혜택을 보았습니다. 하지만 당신은

Answer 2

당신 이 캐시 같은 프로젝트에 푸른 SDK 라이브러리와 온 - 프레미스 라이브러리를 모두 사용할 수 있습니다 : 당신의 시나리오를 더 잘 알 것입니다,하지만 가를 해킹 그것입니다. 그것은 좋은 생각이 아닙니다. 대신 Redis를 사용해보십시오.

나는 나쁜 조언을 계속할 것이다.

두 가지 빌드 구성이 있어야합니다. 하나는 Azure 용이고 다른 하나는 온 - 프레미용입니다. 온 - 프레스 빌드 프로세스가 필요합니다. 예를 들어. msbuild xml을 추가하거나 기본적으로 온 - dll으로 배포되는 Azure dll을 대체 할 포스트 빌드 스크립트를 실행하십시오. 온 - 프레미어로 게시 할 필요가 있습니다. 이 포인터를 확인하십시오 : AfterPublish target not working .