방금 Microsoft “Roslyn”의 백서 및 예제를 읽었 으며 그 개념은 매우 흥미로워 보입니다. 내가 알 수있는 것은 컴파일러 인 블랙 박스를 열고 Visual Studio로 작성된 코드에 대한 정보와 메트릭을 얻는 데 사용할 수있는 인터페이스를 제공합니다.
Roslyn은 또한 코드를 “스크립트”하고 즉시 컴파일 / 실행할 수있는 것으로 보입니다 (CodeDom과 유사). 그러나 필자는 경험상 해당 유형의 기능에 대해 제한된 용도로만 사용했습니다.
코드 분석 및 메트릭 요소는 흥미로운 공간이지만 오랜 시간 동안 사용되어 왔으며 이미 코드 분석 및 리팩토링 도구 (예 : ReSharper, CodeRush)에 많은 돈을 투자 한 수많은 제공 업체가 있습니다 , nCover 등) 그리고 그들은 꽤 잘 작동합니다!
기존 툴 중 하나에 대한 라이센스를 구매하여 적은 비용으로 제공 할 수있는 것을 구현하려는 회사가없는 이유는 무엇입니까?
어쩌면 Roslyn 프로젝트의 핵심 기능 중 일부를 언급 한 도구의 도메인 외부에 배치하는 것을 놓쳤을 수도 있습니다 …
답변
Roslyn은 또한 코드를 “스크립트”하고 즉시 컴파일 / 실행할 수있는 것으로 보입니다 (CodeDom과 유사). 그러나 필자는 경험상 해당 유형의 기능에 대해 제한된 용도로만 사용했습니다.
실시간 컴파일 및 실행은 Roslyn의 주요 이점입니다. 실제로이 기능이 실제로 사용되는 환경에서 유스 케이스를 본 적이 없기 때문에이 기능의 이점을 과소 평가하고 있다고 생각합니다. 그리고 이것은 말이됩니다. 동적 컴파일의 필요성은 아마도 틈새 기능 일 것입니다. 그러나 이것이 없으면 훨씬 더 어려울 수있는 강력한 응용 프로그램을 제공합니다.
다음은 동적 컴파일이 매우 유용한 두 가지 예입니다. 이 모든 것들을 달성하는 다른 방법이 있지만 Roslyn은 그것들을 더 쉽게 만듭니다.
- 런타임에로드되고 컴파일되어 “부모”응용 프로그램 실행에 포함 된 플러그인 파일이 있습니다.
- 런타임에 C #으로 변환되고 Roslyn을 사용하여 컴파일 되는 DSL 을 만듭니다 .
- C #을 가져 와서 분석하고 번역하는 프로그래머 지향 응용 프로그램 만들기
- 공백과 같은 “표면”차이점과 달리 컴파일 후 차이점에 대해 두 개의 코드 청크 비교 이것은 시맨틱 차이 로 알려져 있습니다 .
그래서, 요약하면, 당신은 당신이 당신의 시간을 쓰기를 지출 어떤 소프트웨어에 따라, 로슬린의 사용을 찾을 수 없을 수 있습니다. 그러나 Roslyn이 테이블을 많이 사용하는 많은 사용 사례가 있습니다. 언급 한 도구 중 어느 것도이 기능을 제공하지 않습니다. 또한 아키텍처와 목적을 기반으로 할 수도 없었습니다.
답변
툴링 (예 : JetBrains *)을 제공하는 회사는 Roslyn에 매우 관심이 있습니다. 훌륭한 툴링은 Microsoft의 생태계 사용을 장려하기 때문에 Microsoft는 툴링을 쉽게 만들려고합니다.
* JetBrains 블로그 ( 이 항목 )에 따라 JetBrians는 Roslyn을 사용하지 않을 것이라고 발표했습니다. 그러나 기존의 코드베이스가없는 JetBrains의 새로운 경쟁자는 Roslyn을 사용할 것이라고 생각합니다. 그것은 그들에게 머리 시작을 제공합니다.
질문 10의 6 질문, Roslyn의 10 답변 :
6 : Roslyn의 실질적인 용도는 무엇입니까? 개발자로서 어떻게 도움이 되나요?
Roslyn의 첫 번째 용도 중 하나는 비즈니스 규칙 엔진입니다. Roslyn 이전에는 사용자 매크로를 평가하는 데 일반적으로 VBA (Visual Basic for Applications) 구현, Ruby 표현식으로 DLR 호출, 동적으로 생성 된 Visual Basic 또는 C # 코드로 명령 행 컴파일러에 쉘링 및 실행 결과 얻기가 포함되었습니다. 그 코드. 이 방법들은 이상적이지 않았습니다.
Eric Vogel의 기사 “C #에서 Roslyn 스크립팅 API 사용”에서 설명한 것처럼 Roslyn은 Evaluate () 함수를 사용하여 C # 및 최종적으로 Visual Basic 코드를 동적으로 컴파일하고 실행할 수 있습니다. 응용 프로그램과 동일한 언어로 작성된 사용자 매크로를 통해 개발자는 비즈니스 규칙을 나타내는 사용자 매크로를보다 쉽게 지원할 수 있습니다.
Roslyn을 사용하면 코드 리팩토링이 훨씬 쉬워집니다. Roslyn 이전에는 DevExpress CodeRush 및 Refactor Pro 및 JetBrains ReSharper와 같은 도구 개발자가 많은 컴파일러 작업을 제품의 기초로 다시 만들어야했습니다. Roslyn을 통해 리팩토링 개발자는 기존 컴파일러 기능을 직접 활용할 수 있습니다. Roslyn이 널리 사용 가능 해지면 개별 리팩토링 규칙을 설치하는 NuGet 패키지의 모습을 상상할 수 있습니다.
답변
모든 컴파일러가 일상적으로 CaaS (Compiler as a Service)를 제공하는 날을 간절히 기다리고 있습니다. 컴파일러는 프리 링커 코드 만 방출한다고 생각하지 말고 컴파일러가 여러 대상으로 변환 될 수있는 트리를 생성한다고 생각해야합니다. 모든 컴파일러에는 트리 및 선택적으로 JSON / XML을 생성하는 기능이 있어야합니다. 그런 다음 출력을 미화 동일한 언어, C, IL 소스, IL 이진, Java, Javascript, LLVM, PIC 실행 파일 및 사전 링커 코드와 같은 여러 유형의 대상으로 변환 할 수 있습니다.
나는 생계를 위해 컴파일러를 작성합니다. 고객은 CaaS에서 판매되어 환상적인 유연성, 이식성 및 분석의 문을 열 수 있습니다.
Microsoft가 오래 전에 CaaS를 구현하지 않은 것에 대해 정말 실망했습니다. 예를 들어 VB6을 다른 것으로 마이그레이션하거나 .Net을 C ++로 마이그레이션하는 경로로 사용할 수 있습니다.
답변
MSFT가 Roslyn에 투자하는 이유에 대한 간단한 대답은 C # 컴파일러의 기존 코드베이스가 이제 5 년 이전-11 년이라는 것입니다. 모든 코드베이스가 관리 가능한 상태를 유지 하는 데 오랜 시간이 걸렸습니다. 또한 재 작성한 이후 모든 내부가 API로 노출되도록하기 위해 투자하기로 결정했습니다.