누구도 생산 환경에서 Postsharp AOP 프레임 워크를 사용하고 있습니까? 함정이 있습니까? 일부 로깅 등을하기 위해 Postsharp를 log4net과 함께 사용할 수 있습니까?포스트 샤프 제작 경험이있는 사람은 누구입니까?
Web Apps 및/또는 log4net에서 Postsharp를 사용하는 데 필요한 자습서를 제공해 주시면 대단히 감사하겠습니다.
감사의 말 전진.
1 명의 다른 팀원은 생산 중이며 몇 달 동안 여러 프로젝트에서 다른 방법으로 PostSharp를 사용합니다. 예를 들어, 어떤 경우에는 예외의 경우 메서드 매개 변수 값을 기록하는 데이 메서드를 사용합니다. 포스트 샤프 라오스 (PostSharp에 포함됨)는 메소드 호출 (메소드 엔트리, 종료 및 예외에 대한 주입)을 사용하기 쉬운 방법이며 log4net 등록 된 로거에 로그 호출을 쉽게 추가 할 수 있습니다.
빌드 습관이 약간 변경 될 수 있지만 빌드 시간이 길어졌지만 IMO가 제공하는 이점은 그다지 크지 않습니다. 코드를 작성하는 동안 로컬 빌드에서 제외하기를 원할 수도 있습니다. 그렇게하면 쉽고 빠르게 빌드를 빌드 한 다음 빌드 서버 등에 포함시킬 수 있습니다.
여기에 Gael의 good PostSharp tutorial이 있습니다. (PostSharp 창작자) ... 오래되었지만 관람하는 것이 좋았습니다. 지금까지 내가 만난 콘솔, winforms, WPF 또는 WebApp에서 사용하는 데 실제로 차이가 없습니다.
나는 라오스를 프로젝트에 추가하는 방법을 알면 운동을 반복하는 것이 쉽다는 것을 알 수 있습니다. 그리고 aspect를 적용한 어셈블리/클래스의 수와 PostSharp가 빌드에 추가하는 시간과의 관계가 있습니다. 따라서 빌드 시간 문제를 제어 할 수도 있습니다.
코드에 관해서는, 나는 PostSharp가 얼마나 잘 작동하는지 매우 감명 받았다.빌드를 망치거나 어셈블리를 무효로 만들거나 코드를 엉망으로 만들지 않았습니다. 그리고 코드 적용 범위와 성능 계측 기능을 갖춘 ASP.NET 응용 프로그램에서도 사용했습니다. 따라서 MS의 어셈블리 계측 도구와 잘 맞습니다.
전체적으로 나는 변합니다. log4net 요구 사항에 대해 시험해 보시길 권합니다.
우리는 하나 또는 두 가지에 대해 날카로운 포스트를 사용해 보았습니다. 문제는 빌드 타임이 너무 길게 나왔다는 것이 었습니다. CI를 사용하고 자주 체크인하는 방법을 사용하는 경우 좋은 빌드 서버와 워크 스테이션을 사용하는 것이 좋습니다.
명백하게 .net 4.0에는 AOP와 같은 것을 쉽게하기 위해 많은 컴파일러 훅이있을 것입니다. 우리의 최종 결론은 그것을 기다리는 것이 었습니다.
감사합니다.이 유형의 입력을 정확히 찾고있었습니다. 우리 팀에서 Postsharp fanboy가 있습니다. – Perpetualcoder
컴파일러 후크에 대해 읽은 곳은 어디입니까? 궁금해! – Paco
Anders는 최근 컨퍼런스에서 그것에 대해 이야기 해 왔습니다. (정확히 어디서 들었는지는 확실하지 않습니다.) 장기 목표는 csc가 완전히 관리되는 코드 인 것입니다. –
나는 포스트 샤프를 사용하며 나는 그것을 좋아한다. 그것은 나에게 다르게 추가해야만했던 중복 된 코드를 저장한다.
log4Net에 대한 고급 기능이 필요하지 않았으며 google은 작동 방식을 파악하기에 충분합니다. 그것은 단지 일을합니다. 지금까지 어떤 단점도 보지 못했습니다.
포스트 샤프의 경우 웹 사이트, 블로그 및 소스를 통한 검색 시작으로 충분합니다. 주요 단점은 빌드 시간이 증가한다는 것입니다. 나는 내 컴퓨터가 일하기를 기다리는 것을 싫어한다. 포스트 샤프 빌드 액션을 사용하는 2 개의 프로젝트가있는 +60K loc 솔루션의 Visual Studio (빠른 PC)에서 ctrl-shift-b를 누르는 데 약 8 초가 걸립니다. 가능한 경우 최소한의 프로젝트로 Postsharp를 사용해보십시오.
실제로 postsharp를 사용하지 않으려는 경우, 20 개의 프로젝트로 솔루션을 만들고 각 프로젝트에 post-build 명령을 추가 할 수 있습니다. 빌드 시간은 나머지 팀을 괴롭히기에 충분히 길어집니다.
개인적으로 나는 앞으로의 프로젝트를 위해 Postsharp를 계속 사용할 것입니다. 장점은 추가 빌드 시간을 무효화합니다.
저는 날카로운 글씨를 사용합니다. 게시물의 날카로운 빌드 시간은 짜증나지만 맨손으로 할 수 있습니다. 디버그 모드에서 나는 postsharp를 제거하는 조건부 SKIPPOSTSHARP를 사용합니다.
우리는 3.5 런타임 및 Silverlight 런타임 모두 프로덕션 환경에서 PostSharp를 사용합니다. 빌드 속도를 약간 높이려면/m : msbuild (msbuild를 사용하는 병렬 빌드의 경우 google) 스위치를 사용하십시오. 그들은 또한 향후 출시 될 때 극적으로 속도를 높일 것을 약속합니다.
PostSharp Community Survey에 따르면, 많은 회사들이 생산에서 PostSharp를 사용합니다. 실망스러운 점은 그들이 식별하기를 거부한다는 것입니다 :-(.
Gael, www.pirform.co.uk에서 생산시 PostSharp를 사용합니다. 이제 베타 버전이지만 곧 출시 될 예정입니다. 우리는 기꺼이 확인되기도합니다. –
질문에 PostSharp에 링크 해주시겠습니까? –
AOP 라이브러리의 경우 매우 잘못된 경로입니다. –
커뮤니티 버전이 여전히 존재한다고 생각합니다. – Perpetualcoder