2010-03-15 49 views
9

Tôi đang tìm một nhóm các lớp (tốt nhất là trong khung .net) sẽ phân tích cú pháp mã C# và trả về danh sách hàm với tham số, lớp với phương thức, thuộc tính, v.v. sẽ cung cấp tất cả những gì cần thiết để xây dựng bản intellisense của riêng tôi.Tìm kiếm trình phân tích cú pháp mã C#

Tôi có cảm giác một cái gì đó như thế này nên ở trong khung .net, được cung cấp tất cả những thứ phản ánh mà họ cung cấp, nhưng nếu không thì một giải pháp thay thế nguồn mở là đủ tốt.

Những gì tôi đang cố gắng xây dựng về cơ bản giống như trình biên dịch Snippet, nhưng với một bước ngoặt. Tôi đang cố gắng tìm ra cách để có được mã số dom đầu tiên.

Tôi đã thử googling cho điều này nhưng tôi không chắc chắn những gì các thuật ngữ chính xác cho điều này là vì vậy tôi đã đưa ra sản phẩm nào.

Chỉnh sửa: Vì tôi đang tìm cách sử dụng tính năng này để xử lý giống như intelliSense, nên việc biên dịch mã sẽ không hoạt động vì rất có thể sẽ không hoàn thành. Xin lỗi tôi đã đề cập đến điều đó trước tiên.

+0

Ứng dụng có phải hoạt động với mã hoặc mã không đầy đủ có lỗi hay không (tức là mã không biên dịch với trình biên dịch thông thường?) Đó thường là yêu cầu đối với các trình phân tích cú pháp kiểu IntelliSense. –

+0

Phải làm việc trên mã không đầy đủ. Tôi đang tìm kiếm nội dung trực tuyến. – Blindy

Trả lời

5

Trong khi không gian tên CodeDom của .NET cung cấp basic API for code language parsers, chúng không được triển khai. Visual Studio thực hiện điều này thông qua các dịch vụ ngôn ngữ riêng của mình. Đây không phải là có sẵn trong khuôn khổ redistributable.

Bạn có thể hoặc là ...

  1. Biên dịch mã sau đó sử dụng phản ánh trên lắp ráp kết quả
  2. Nhìn vào một cái gì đó giống như Mono C biên dịch # mà tạo ra những cây cú pháp. Nó sẽ không phải là một API cấp cao như CodeDom nhưng có lẽ bạn có thể làm việc với nó.

Có thể có something on CodePlex hoặc trang web tương tự.

CẬP NHẬT
Xem bài đăng liên quan này. Parser for C#

+0

+1 để cập nhật - nó chứa các giải pháp khả thi –

1

Hãy xem CSharpCodeCompiler trong không gian tên Microsoft.CSharp. Bạn có thể biên dịch bằng cách sử dụng CSharpCodeCompiler và truy cập vào tập hợp kết quả bằng cách sử dụng CompilerResults.CompiledAssembly. Tắt hội đồng đó, bạn sẽ có thể nhận được các loại và loại bỏ bạn có thể nhận được tất cả các tài sản và phương pháp thông tin bằng cách sử dụng phản ánh.

Hiệu suất sẽ khá trung bình vì bạn sẽ cần phải biên dịch tất cả mã nguồn bất cứ khi nào có thay đổi. Tôi không biết về bất kỳ phương pháp nào sẽ cho phép bạn biên dịch các đoạn mã một cách gia tăng.

1

Bạn đã thử sử dụng lớp học Microsoft.CSharp.CSharpCodeProvider chưa? Đây là nhà cung cấp mã C# đầy đủ hỗ trợ CodeDom. Bạn chỉ cần gọi .Parse() trên một dòng văn bản, và bạn lấy lại CodeCompileUnit.

var codeStream = new StringReader(code); 
var codeProvider = new CSharpCodeProvider(); 

var compileUnit = codeProvider.Parse(codeStream); 

// compileUnit contains your code dom 

Vâng, nhìn thấy như ở trên không làm việc (tôi chỉ thử nghiệm nó), bài viết sau đây có thể quan tâm. Tôi đã đánh dấu nó một thời gian dài trước đây, vì vậy tôi tin rằng nó chỉ hỗ trợ C# 2.0, nhưng nó vẫn có thể đáng giá:

Generate Code-DOMs directly from C# or VB.NET

+0

Điều này không được thực hiện bởi bất kỳ nhà cung cấp mã dom nào và ném ra một NotImplementedException. – Josh

+0

@Josh: Có vẻ như bạn đã đúng. Tôi chỉ cố gắng, và nó thực sự thất bại. Thật đáng tiếc. – jrista

2

Nếu bạn cần nó để làm việc trên không đầy đủ mã, hoặc mã với các lỗi trong nó, sau đó tôi tin rằng bạn đang khá nhiều trên của riêng bạn (nghĩa là, bạn sẽ không thể sử dụng lớp học CSharpCodeCompiler hoặc bất kỳ thứ gì tương tự).

Có các công cụ như ReSharper thực hiện phân tích cú pháp của riêng nó, nhưng đó là tính chuyên nghiệp. Bạn có thể bắt đầu với trình biên dịch Mono, nhưng theo kinh nghiệm của tôi, viết một trình phân tích cú pháp hoạt động trên mã không hoàn chỉnh là một trò chơi ballgame hoàn toàn khác để viết một cái mà chỉ cần nhổ ra các lỗi trên mã không đầy đủ.

Nếu bạn chỉ cần tên lớp và phương pháp (siêu dữ liệu, về cơ bản) thì bạn có thể thực hiện phân tích cú pháp "bằng tay", nhưng tôi đoán nó phụ thuộc vào mức độ chính xác mà bạn cần kết quả.

+0

Tôi đang bắt đầu xem xét phân tích cú pháp bằng tay. Không chắc chắn như thế nào khó khăn này sẽ được với Generics mặc dù. – Blindy

2

Dự án Mono Trình biên dịch GMCS chứa một trình phân tích cú pháp khá có thể tái sử dụng cho C# 4.0. Và, nó là tương đối dễ dàng để viết phân tích cú pháp của riêng bạn mà sẽ bộ nhu cầu cụ thể của bạn. Ví dụ: bạn có thể sử dụng lại tính năng này: http://antlrcsharp.codeplex.com/

+0

Vấn đề với các trình phân tích cú pháp đã thực hiện này là chúng sẽ không hoạt động đối với mã không đầy đủ (và do đó không hợp lệ). Mục đích của họ là tạo một cây cú pháp đủ chi tiết để tạo mã, không cung cấp dữ liệu cho intellisense. – Blindy

+0

Đúng. Nhưng, vì chúng có thể tái sử dụng, người ta có thể dễ dàng chỉnh sửa chúng. ANTLR có thể được sử dụng để phân tích một phần. Nhưng tất nhiên, tùy chọn chung nhất là PEG, vì vậy nếu bạn có thể nắm giữ thực thi PEG tốt cho .NET, và bạn có thể chuyển một trình phân tích cú pháp ANTLR hiện có, bạn sẽ nhận được một giải pháp chung nhanh chóng và dễ dàng. Ví dụ: trình phân tích cú pháp Packrat từ http://www.meta-alternative.net/mbase.html có khả năng tạo các chế độ đánh dấu cú pháp cho trình chỉnh sửa văn bản, trong bất kỳ cú pháp chung nào và nó hoạt động tốt với không đầy đủ hoặc không hợp lệ đầu vào. –

1

Có thể hơi muộn cho Blindy, nhưng gần đây tôi đã phát hành trình phân tích cú pháp C# hoàn hảo cho loại điều này vì nó được thiết kế để xử lý các đoạn mã và giữ lại nhận xét: C# Parser and CodeDOM

Nó xử lý C# 4.0 và cũng là tính năng 'không đồng bộ' mới. Đó là thương mại, nhưng là một phần nhỏ của chi phí của các trình biên dịch thương mại khác. Tôi thực sự nghĩ rằng rất ít người nhận ra việc phân tích cú pháp C# đã trở nên khó khăn như thế nào, đặc biệt nếu bạn cần giải quyết các tham chiếu tượng trưng đúng cách (thường là cần thiết, trừ khi có thể bạn chỉ đang định dạng). Chỉ cần thử để đọc và hiểu đầy đủ phần Loại suy luận của đặc điểm ngôn ngữ của hơn 500 trang. Sau đó, suy ngẫm về thực tế rằng thông số kỹ thuật không thực sự hoàn toàn chính xác (như được đề cập bởi chính Eric Lippert).

Các vấn đề liên quan