우리 환경에는 프로젝트가 참조하는 다양한 타사 어셈블리가 포함 된 Lib 폴더가 있습니다. 예 : Enterprise Libary 및 Elmah.Visual Studio의 어셈블리 참조 업데이트를 중지하는 방법은 무엇입니까?
때때로 dev는 그 폴더에서 최신 항목을 가져 오지 않습니다. Dev가 예상 폴더에 어셈블리를 찾을 수없는 프로젝트를로드하면 Visual Studio는 자동으로 다른 복사본을 찾고 프로젝트 참조를 업데이트합니다.
개발자가 프로젝트를 검사 할 때 문제가 발생하고 다른 모든 사람이이를 조장합니다.
Visual Studio 2008에서이 작업을 중단하는 방법이 있습니까?
업데이트 : 소스 제어를 위해 TFS를 사용하고 있다고 덧붙였습니다.
다음은 Google에서 내 회사를 보호하는 방법입니다. (귀하의 마일리지는 달라질 것입니다!)
모든 비 시스템 (또는 GAC 이외의) 참조는 모든 개발자가 W : 드라이브에 매핑 한 Dev 서버에서 가져옵니다. 우리는 클라이언트 (또는 벤더)에 의한 서브 디렉토리와 적절한 다른 서브 디렉토리를 가진 공통의 DLL 디렉토리를 가지고 있습니다. 은 소스 컨트롤에 저장되어 있지 않습니다. 때때로 Infragistics에서 필요에 따라 license.dll을 제외합니다.
W : 드라이브에서 참조하는 정책과 같이 공급 업체 제공 라이브러리 (EntLib, Infragistics 등)의 경우. 기간. 어느 누구도 다른 곳에서 참조 할 수있는 권한이 없습니다. 이렇게하면 프로젝트 파일의 힌트가 공통 경로로 코딩됩니다.
사내 라이브러리 (클라이언트 및 내부 프로젝트)의 경우, 우리의 지속적인 통합 프로세스는 DLL을이 디렉토리의 해당 분기로 출력합니다. 우리의 모든 참조가 나온 곳입니다.
이렇게하면 VS가 매번 서버에 대해 자동으로 새로 고침하므로 로컬 컴파일 시간이 느려집니다 (로컬 디버깅의 경우). 그것은 귀찮은 일입니다 (때로는 프로젝트가 로컬로 구축하는 데 5 ~ 6 분이 걸릴 수도 있음). 그러나 다른 참조를 사용하는 사람들을 해결하는 것은 필요한 악마입니다. 여기서 이점은 누군가가 이러한 참조 중 하나에 대한 코드를 체크인하자마자 CI 서버가 빌드를 시작하고 모든 사람들이 신속하게 그 코드를 가져옵니다.
이 트릭은 안정적이고 반복 가능한 빌드 프로세스와 지속적인 통합 서버입니다. 우리는 NAnt 빌드와 통합 된 CruiseControl.NET을 사용하고 있지만, 여기에 좋아하는 CI 서버와 빌드 툴을 삽입하십시오.
소스 제어 시스템 (악마 스폰이라고도하며, 최근의 여러 가지 발언 참조)이 대규모 시스템에서 수행하는 동안 빌드 서버가 작동하는 것을 제외하고는 지금까지이 프로세스의 결과로 문제가 발생하지 않았습니다. 다중 파일 체크인. (Demon Spawn은 거래 체크인을 지원하지 않기 때문에) 그러나 이것은 매우 드물게 발생합니다 - 아마도 5 ~ 6 주에 한 번. 그리고 즉시 재건하는 군대가 그것을 처리합니다.
단지 몇 가지 생각 ...이 기법을 사용하면 사람들이 소스 제어를 망쳐 놓지 않아야합니다. 추가 보너스로 dll.refresh를 DLL에 체크인하지 않고 소스 제어의 크기를 줄이십시오. 파일.
이것은 거의 올바른 대답입니다. 우리는 TFS를 사용하고 있으며 체크인시 파일을 볼 수있는 ForbiddenPatternsPolicy를 발견했습니다. 감사! – NotMe
문제 없습니다! 그것이 너를 위해 일하기를 바래! –
나는 이것이 가능하지 않다고 생각합니다.
텍스트 편집기에서 프로젝트 파일을 열면 Visual Studio는 어셈블리에 대한 하드 참조를 저장하지 않지만 대신 "HintPath"를 저장합니다. 참조가 없으면 Visual Studio에서 자동으로 GAC를 시도합니다.
연속 통합 서버를 설정하는 것이 좋습니다 (아직없는 경우). 이런 경우에 조기 경보 시스템으로 작동합니다.
TeamCity는 최대 20 명의 사용자와 20 명의 빌드에서 무료입니다. 그것은 내가 현재 사용하고있는 것이고, 그것은 꽤 멋지다. – MrBoJangles
우리는 CI를 설정했습니다. 기본적으로 저는 빌드 서버에있는 모든 어셈블리를 gac'd 한 Dev 환경의 커다란 엉망을 청소하는 중입니다. 문제는 물론 여기 몇몇 앱은 다른 버전을 사용하기 때문에 문제가 더 많이 발생합니다. – NotMe
그러나 다음 단계는 빌드 서버를 정리하는 것입니다. - 감사합니다. – NotMe
나는 소스 제어에 dll을 넣는 것을 제외하고 대부분의 지점에서 John과 함께 작업합니다.
나는 대개 ThirdParty 폴더가 있는데, 그러면 벤더 제품과 버전이 분류되므로 ajax 툴킷은 $/ThirdParty/Microsoft/AjaxToolkit/(일부 버전 번호)에 저장됩니다. 저는이 방법을 좋아합니다. 왜냐하면 빌드를 만드는 모든 아티팩트에 레이블을 붙일 수 있기 때문입니다.
또 다른 아이디어는 프로젝트 내의 dll 일 수 있으므로 프로젝트의 최신 버전을 얻으면 dll이 생성됩니다.
나는 두 가지 방법으로 회사를 보았다. 우리는이 작업을 한 번 해봤지만 소스 제어에 실제로 포함 된 아티팩트의 크기를 제한하려했기 때문에 중단했습니다. –
예, 이것은 절대적으로 미숙하며 실제로 고통 스럽습니다. 다음은 다른 옵션입니다. 1. GAC에서 어셈블리를 제거하십시오. 2. 종속성 해결 시스템에서 BIN 폴더로 어셈블리를 배달하십시오. 여기서 모든 솔루션 어셈블리도 컴파일됩니다. 3. 모든 참조 설정 Copy Local = false AND Specific Version = False. 이 점은 디버깅 할 때 어셈블리 로딩 예외를 발생시키는 것입니다. BIN에 없으면 거기에 복사 할 것이 없기 때문입니다. VS가 파일을 복사 할 필요가 없으므로 솔루션이 더 빨리 컴파일됩니다. 그리고 이것은 "언데드"dll을 obj 디렉토리에 앉아서 기적적으로 찾고 복사 할 수 없도록합니다.
이것은 사용자가 제어하는 솔루션에서 잘 작동합니다. 우리는 수년간 이것을 해왔다. 그리고 트랙 무언가가 떨어져 나간다는 것을 알아내는 것은 매우 쉽습니다. 그런 다음 Copy Local = true 또는 Specific Version = True로 조립품을 찾으러 간다. 잊어 버리거나 피곤한 경우 등. 현재 문제는 내가 작업하고있는 솔루션의 구조 나 설정을 제어하지 않아서이 고대의 문제에 대한 해결책을 찾고 있다는 것입니다. 나는 VS 팀이 그것을 해결하기를 바랐다 ... Alas ... 팀,이 고통을 멈춰라.
그래, 그게 바로 내가 GAC에 직접 넣은 적이없는 이유야. –
또한 문제가 devs와 같은 것 같습니다. 어쩌면이 실수를하지 않도록 가르치기 위해 뭔가 할 수 있습니다. 누군가가 실수로 실수로 5 달러를 지불하면 기억할 수 있습니다. :) –
주요 문제는 DevExpress 컨트롤과 같은 GAC의 어셈블리. 우리는 lib 폴더 업데이트에 대한 책임이있는 사람 1 명에게 제 3 자 어셈블리를 할당하고 아무도 설치하지 못하게했습니다. 그 통제를위한 고통의 종류, 그러나 그것은 작동했다. – NotMe