왜 누군가 Microsoft“Roslyn”에 시간을 투자하겠습니까?

37

방금 Microsoft "Roslyn"의 백서 및 예제를 읽었 으며 그 개념은 매우 흥미로워 보입니다. 내가 알 수있는 것은 컴파일러 인 블랙 박스를 열고 Visual Studio로 작성된 코드에 대한 정보와 메트릭을 얻는 데 사용할 수있는 인터페이스를 제공합니다.

Roslyn은 또한 코드를 "스크립트"하고 즉시 컴파일 / 실행할 수있는 것으로 보입니다 (CodeDom과 유사). 그러나 필자는 경험상 해당 유형의 기능에 대해 제한된 용도로만 사용했습니다.

코드 분석 및 메트릭 요소는 흥미로운 공간이지만 오랜 시간 동안 사용되어 왔으며 이미 코드 분석 및 리팩토링 도구 (예 : ReSharper, CodeRush)에 많은 돈을 투자 한 수많은 제공 업체가 있습니다 , nCover 등) 그리고 그들은 꽤 잘 작동합니다!

기존 툴 중 하나에 대한 라이센스를 구매하여 적은 비용으로 제공 할 수있는 것을 구현하려는 회사가없는 이유는 무엇입니까?

어쩌면 Roslyn 프로젝트의 핵심 기능 중 일부를 언급 한 도구의 도메인 외부에 배치하는 것을 놓쳤을 수도 있습니다 ...

.net visual-studio static-analysis

— 리차드 후퍼
소스

4

Roslyn의 요점은보다 확장 가능한 관리 형 C # 컴파일러를 만드는 Microsoft 인턴입니다. 이를 통해 팀은 새로운 언어 기능을보다 쉽게 구현하고 시도 할 수 있습니다. 또한 새로운 최적화 알고리즘을 구현하는 것이 쉬워 질 것입니다.

— JustAnotherUserYouMayKnowOrNot

1

네 펜 폴드-몇 가지를 놓친 것 같습니다. 더스틴 캠벨 스가 Channel9에서 인터뷰 한 것을 보셨습니까? channel9.msdn.com/Events/Ch9Live/…

— 제임스 스넬

3

이는 Microsoft 제품에 성공적이고 수익성있는 추가 기능을 개발할 위험이 있으므로 다음 버전에 추가 할 수 있습니다.

— JeffO

10

또한 ReSharper를 사용하는 사람들이 추가 기능에 대한 생각에 젖어 있는지 확인할 수 있습니다. 예, C # 파서 / 분석기를 작성했지만 실제 MS C # 엔진.

— 이진 걱정

2

Roslyn의 흥미로운 사용법에 대해서는 scriptcs를 확인하십시오. github.com/scriptcs/scriptcs

— Ashley Davis

53

Roslyn은 또한 코드를 "스크립트"하고 즉시 컴파일 / 실행할 수있는 것으로 보입니다 (CodeDom과 유사). 그러나 필자는 경험상 해당 유형의 기능에 대해 제한된 용도로만 사용했습니다.

실시간 컴파일 및 실행은 Roslyn의 주요 이점입니다. 실제로이 기능이 실제로 사용되는 환경에서 유스 케이스를 본 적이 없기 때문에이 기능의 이점을 과소 평가하고 있다고 생각합니다. 그리고 이것은 말이됩니다. 동적 컴파일의 필요성은 아마도 틈새 기능 일 것입니다. 그러나 이것이 없으면 훨씬 더 어려울 수있는 강력한 응용 프로그램을 제공합니다.

다음은 동적 컴파일이 매우 유용한 두 가지 예입니다. 이 모든 것들을 달성하는 다른 방법이 있지만 Roslyn은 그것들을 더 쉽게 만듭니다.

런타임에로드되고 컴파일되어 "부모"응용 프로그램 실행에 포함 된 플러그인 파일이 있습니다.
런타임에 C #으로 변환되고 Roslyn을 사용하여 컴파일 되는 DSL 을 만듭니다 .
C #을 가져 와서 분석하고 번역하는 프로그래머 지향 응용 프로그램 만들기
공백과 같은 "표면"차이점과 달리 컴파일 후 차이점에 대해 두 개의 코드 청크 비교 이것은 시맨틱 차이 로 알려져 있습니다 .

그래서, 요약하면, 당신은 당신이 당신의 시간을 쓰기를 지출 어떤 소프트웨어에 따라, 로슬린의 사용을 찾을 수 없을 수 있습니다. 그러나 Roslyn이 테이블을 많이 사용하는 많은 사용 사례가 있습니다. 언급 한 도구 중 어느 것도이 기능을 제공하지 않습니다. 또한 아키텍처와 목적을 기반으로 할 수도 없었습니다.

— RationalGeek
소스

sematic diff의 경우 +1 여기 에 의미 상 차이점을 위해 Roslyn을 사용하는 개발중인 상용 제품 에 대한 링크가 있습니다. (전체 공개-나는 그들과 관련이 없으며, Jon Skeet의 블로그에 언급 된 제품을 보았습니다 )

— MarkJ

@RationalGeek-예제 덕분에 DSL => C # 경로 예제를 고려하지 않았습니다 ... 비즈니스 응용 프로그램에서 매우 강력한 몇 가지 시나리오를 상상할 수 있습니다. 내가 본 다른 많은 예제 (귀하의 것만이 아님)는 앞에서 언급 한 리팩토링 도구와 매우 겹칩니다. 내 원래 질문의 다른 부분은 비용의 일부로 사전 롤링 된 우수한 도구가있을 때 누군가 가이 분석을 수행하기 위해 도구를 개발하는 데 돈을 투자하는 이유였습니다. 그러나 항상 다른 것을위한 공간이 있다고 생각합니다 ( 더 나은) 도구 세트! :)

— Richard Hooper

@Penfold는 항상 새로운 개발자 도구를위한 공간이 있습니다 ... :-)

— RationalGeek

1

시맨틱 diff는 컴파일 목적만을위한 것이 아닙니다. 모든 버전 관리 시스템에는 diff가 필요하며 대부분 바보 같은 diff를 사용합니다. diff가 몇 개의 함수와 일치한다고 생각할 때 2 개의 함수를 바꾸고 엉망이 된 것을보십시오 (및 {.

— MSalters

웹 응용 프로그램을 다시 작성하고 재배포하지 않고도 ASP.NET 응용 프로그램을 작성할 때 자동 재 컴파일이 가장 중요합니다. 마지막으로 ASP.NET vNext에서 발표되었으므로 문자 그대로 C #에서 스크립팅 언어와 동일하게 작업 할 수 있습니다. 나는 이것이 일반적인 접근 방식의 시작이라고 생각합니다. 결국 런타임에 코드를 변경할 수 있도록 리치 클라이언트 앱 (모바일, 데스크톱)으로 전환됩니다. 정의에 따라 각 요청에는 상태가 없으므로 웹 앱을 사용하는 것이 훨씬 쉽습니다. 그러나 시간이 지나면 다른 앱 아키텍처에도 적용됩니다.

— Marchy

12

툴링 (예 : 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 패키지의 모습을 상상할 수 있습니다.

— 브라이언
소스

4

"응용 프로그램과 동일한 언어로 작성된 사용자 매크로를 통해 개발자는 비즈니스 규칙을 나타내는 사용자 매크로를보다 쉽게 지원할 수 있습니다." -무엇이 잘못 될 수 있는가!

— gbjbaanb

9

모든 컴파일러가 일상적으로 CaaS (Compiler as a Service)를 제공하는 날을 간절히 기다리고 있습니다. 컴파일러는 프리 링커 코드 만 방출한다고 생각하지 말고 컴파일러가 여러 대상으로 변환 될 수있는 트리를 생성한다고 생각해야합니다. 모든 컴파일러에는 트리 및 선택적으로 JSON / XML을 생성하는 기능이 있어야합니다. 그런 다음 출력을 미화 동일한 언어, C, IL 소스, IL 이진, Java, Javascript, LLVM, PIC 실행 파일 및 사전 링커 코드와 같은 여러 유형의 대상으로 변환 할 수 있습니다.

나는 생계를 위해 컴파일러를 작성합니다. 고객은 CaaS에서 판매되어 환상적인 유연성, 이식성 및 분석의 문을 열 수 있습니다.

Microsoft가 오래 전에 CaaS를 구현하지 않은 것에 대해 정말 실망했습니다. 예를 들어 VB6을 다른 것으로 마이그레이션하거나 .Net을 C ++로 마이그레이션하는 경로로 사용할 수 있습니다.

— BSalita
소스

1

MSFT가 Roslyn에 투자하는 이유에 대한 간단한 대답은 C # 컴파일러의 기존 코드베이스가 이제 5 년 이전-11 년이라는 것입니다. 모든 코드베이스가 관리 가능한 상태를 유지 하는 데 오랜 시간이 걸렸습니다. 또한 재 작성한 이후 모든 내부가 API로 노출되도록하기 위해 투자하기로 결정했습니다.

— 존 태 슬러
소스