Tôi có nên biên dịch các bản phát hành với thông tin gỡ lỗi là “đầy đủ” hoặc “chỉ pdb” không?

114

Trong Visual Studio 2010 cho một dự án C #, nếu bạn đi tới Thuộc tính dự án> Xây dựng> Nâng cao> Thông tin gỡ lỗi, bạn có ba tùy chọn: không có, đầy đủ hoặc chỉ pdb. Dựa trên câu trả lời cho câu hỏi này , tôi tin rằng tôi hiểu một số điểm khác biệt giữa đầy đủ và chỉ pdb. Tuy nhiên, cái nào thích hợp hơn cho một bản phát hành? Nếu tôi sử dụng "đầy đủ" sẽ có sự phân chia hiệu suất? Nếu tôi sử dụng "pdb-only" thì việc gỡ lỗi sản xuất sẽ khó hơn phải không?

Sự khác biệt giữa "full" và "pdbonly" là gì? https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/compiler-options/debug-compiler-option

— RationalGeek
nguồn

Chỉ pdb hoặc không, luôn dành cho các bản dựng phát hành.

— leppie 10/10/11

13

@leppie Cảm ơn nhưng tôi đang tìm kiếm một số biện minh cho vị trí đó.

— RationalGeek

Câu hỏi liên quan: stackoverflow.com/questions/1270986/…

— janv8000 Ngày

Điều đó thật tuyệt nếu không có tác động đến hiệu suất. Còn về tác động của bộ nhớ? Nếu tôi tạo một phiên bản của StackTrace và yêu cầu thông tin tệp, nó phải đến từ dữ liệu ký hiệu pdb. Tất cả các ký hiệu có được tải vào bộ nhớ khi khởi động ứng dụng không? Việc sử dụng bộ nhớ gần đúng của điều này là gì? (ví dụ: chi phí phần trăm so với kích thước mã.)

— yoyo

90

Tôi sẽ xây dựng với pdb-only. Bạn sẽ không thể đính kèm trình gỡ lỗi vào sản phẩm đã phát hành, nhưng nếu gặp lỗi kết xuất, bạn có thể sử dụng Visual Studio hoặc WinDBG để kiểm tra dấu vết ngăn xếp và kết xuất bộ nhớ tại thời điểm xảy ra sự cố.

Nếu bạn đi cùng với fullthay vì pdb-only, bạn sẽ nhận được những lợi ích tương tự, ngoại trừ việc tệp thực thi có thể được đính kèm trực tiếp vào trình gỡ lỗi. Bạn sẽ cần xác định xem điều này có hợp lý với sản phẩm và khách hàng của bạn hay không.

Hãy nhớ lưu các tệp PDB ở đâu đó để bạn có thể tham khảo chúng khi có báo cáo sự cố. Nếu bạn có thể thiết lập một máy chủ ký hiệu để lưu trữ các ký hiệu gỡ lỗi đó thì càng tốt.

Nếu bạn chọn xây dựng với none, bạn sẽ không có quyền sử dụng khi có sự cố trên thực địa. Bạn sẽ không thể thực hiện bất kỳ loại kiểm tra thực tế nào về vụ tai nạn, điều này có thể cản trở nghiêm trọng đến khả năng tìm ra sự cố của bạn.

Một lưu ý về hiệu suất:

Cả John Robbins và Eric Lippert đều đã viết các bài đăng trên blog về /debugcờ và cả hai đều chỉ ra rằng cài đặt này không có tác động đến hiệu suất . Có một /optimizecờ riêng cho biết liệu trình biên dịch có nên thực hiện tối ưu hóa hay không.

— Matt Dillard
nguồn

7

@Matt, bài báo MSDN về công tắc / gỡ lỗi cảnh báo rõ ràng về tác động hiệu suất của việc sử dụng cài đặt 'đầy đủ':

If you use /debug:full, be aware that there is some impact on the speed and size of JIT optimized code and a small impact on code quality with /debug:full. We recommend /debug:pdbonly or no PDB for generating release code.

— Allon Guralnek

3

@Matt: Nếu 'full' không có nhược điểm so với 'pdb-only', mà chỉ có ưu điểm, thì tại sao 'pdb-only' lại tồn tại? Có lý do gì để sử dụng nó quá mức 'đầy đủ' không? Ngoài ra, bạn nên thêm phần sửa chữa vào bài viết MSDN trong phần 'Nội dung Cộng đồng'.

— Allon Guralnek

9

@AllonGuralnek trích dẫn từ bài báo của John Robbins được liên kết: Lý do thực sự: lịch sử. Quay lại .NET 1.0 có sự khác biệt, nhưng trong .NET 2.0 thì không. Có vẻ như .NET 4.0 sẽ theo cùng một mô hình. Sau khi kiểm tra kỹ với Nhóm gỡ lỗi CLR, không có sự khác biệt nào cả.

— bentayloruk

5

Điều này không đúng. Bạn có thể tạo chỉ với pdb và vẫn đính kèm trình gỡ lỗi. Tôi chỉ làm điều đó chỉ để chắc chắn.

— Đánh dấu

2

"Tôi sẽ xây dựng chỉ với pdb. Bạn sẽ không thể đính kèm trình gỡ lỗi vào sản phẩm đã phát hành" Nguồn thông tin của bạn ở đây là gì? Như cả tôi và @Mark đã lưu ý, điều này có vẻ không đúng.

— MEMark

66

CẢNH BÁO Tài liệu MSDN cho / gỡ lỗi chuyển đổi (Trong Visual Studio, đó là Thông tin gỡ lỗi) có vẻ như đã lỗi thời! Đây là những gì nó có mà là không chính xác

Nếu bạn sử dụng / debug: full , hãy lưu ý rằng có một số tác động đến tốc độ và kích thước của mã được tối ưu hóa JIT và tác động nhỏ đến chất lượng mã với / debug: full . Chúng tôi đề xuất / gỡ lỗi: pdbonly hoặc không có PDB để tạo mã phát hành.

Một điểm khác biệt giữa / debug: pdbonly và / debug: full là với / debug: full trình biên dịch phát ra a DebuggableAttribute, được sử dụng để thông báo cho trình biên dịch JIT biết rằng thông tin gỡ lỗi có sẵn.

Sau đó, điều gì là sự thật bây giờ?

Chỉ dành cho Pdb - Trước .NET 2.0, nó đã giúp điều tra sự cố kết xuất từ sản phẩm đã phát hành (máy của khách hàng). Nhưng nó không cho phép đính kèm trình gỡ lỗi. Đây không phải là trường hợp của .NET 2.0. Đó là chính xác giống như đầy đủ .
Đầy đủ - Điều này giúp chúng tôi điều tra các bãi chứa sự cố và cũng cho phép chúng tôi đính kèm trình gỡ lỗi để phát hành bản dựng. Nhưng không giống như MSDN đã đề cập, nó không ảnh hưởng đến hiệu suất (kể từ .NET 2.0). Nó hoạt động giống hệt như chỉ Pdb .

Nếu chúng hoàn toàn giống nhau, tại sao chúng ta lại có những tùy chọn này? John Robbins (thần gỡ lỗi cửa sổ) đã phát hiện ra những điều này có vì lý do lịch sử.

Quay lại .NET 1.0 có sự khác biệt, nhưng trong .NET 2.0 thì không. Có vẻ như .NET 4.0 sẽ theo cùng một mô hình. Sau khi kiểm tra kỹ với Nhóm gỡ lỗi CLR, không có sự khác biệt nào cả.

Điều kiểm soát việc JITter có thực hiện xây dựng gỡ lỗi hay không là công tắc / tối ưu hóa. <…>

Điểm mấu chốt là bạn muốn xây dựng các bản phát hành của mình với / tối ưu hóa + và bất kỳ công tắc / gỡ lỗi nào để bạn có thể gỡ lỗi bằng mã nguồn.

sau đó anh ta tiếp tục chứng minh điều đó.

Bây giờ tối ưu hóa là một phần của một công tắc riêng biệt /optimize(trong studio trực quan, nó được gọi là Optimize code).

Tóm lại, không phân biệt DebugInfo đặt pdb-only hay full, chúng ta sẽ có kết quả giống nhau. Khuyến nghị là nên tránh Không vì nó sẽ khiến bạn mất khả năng phân tích kết xuất sự cố từ sản phẩm đã phát hành hoặc đính kèm trình gỡ lỗi.

— rpattabi
nguồn

3

Câu trả lời tuyệt vời! Các cuộc điều tra của riêng tôi (so sánh các tệp đã tạo) đều cho kết quả tương tự.

— MEMark

@rpattabi Bạn có thể chỉ định tham chiếu rằng pdbonly và full giống nhau không? Đó là năm 2019 và tài liệu vẫn chỉ ra rằng chúng khác nhau và đầy đủ sẽ bị giảm hiệu suất. Và VS2019 tạo dự án với loại Releasegỡ lỗi của cấu hình theo mặc định được đặt thành pdbonly.

— joe

@joe Có một cuộc thảo luận ở cuối tài liệu MSDN msdn.microsoft.com/en-us/library/8cw0bt21.aspx . Hãy nhìn vào nó. Một cộng tác viên đã chỉ vào github.com/dotnet/roslyn/blob/master/docs/compilers/CSharp/… để biết thông tin cập nhật trong đó pdbonly và đầy đủ được đề cập như nhau. (FYI. Tôi không sử dụng windows hoặc VS nữa. Vì vậy, tôi đã không theo dõi những gì đang xảy ra ở đó. Nhưng khi tôi xem xét, thông tin trong câu trả lời của tôi vẫn có liên quan và tài liệu MSDN vẫn không chính xác.)

— rpattabi

16

Bạn sẽ chỉ muốn PDB, nhưng bạn sẽ không muốn cung cấp các tệp PDB cho người dùng. Mặc dù vậy, việc có chúng cho chính bạn, cùng với các tệp nhị phân của bạn, mang lại cho bạn khả năng tải kết xuất lỗi vào trình gỡ lỗi như WinDbg và xem chương trình của bạn thực sự bị lỗi ở đâu. Điều này có thể khá hữu ích khi mã của bạn gặp sự cố trên máy mà bạn không có quyền truy cập.

Gỡ lỗi đầy đủ thêm thuộc tính [Có thể gỡ lỗi] vào mã của bạn. Điều này có ảnh hưởng rất lớn đến tốc độ. Ví dụ: một số tối ưu hóa vòng lặp có thể bị vô hiệu hóa để làm cho một bước dễ dàng hơn. Ngoài ra, nó có ảnh hưởng nhỏ đến quy trình JIT, vì nó bật theo dõi.

— thổi bay
nguồn

Có ý nghĩa. Tôi không thực sự phân phối DLL cho người dùng - đó là một ứng dụng ASP.NET. Nhưng bạn có thể nâng cao câu trả lời của mình và giải thích lý do tại sao bạn nên chọn "pdb-only" so với "full" không? Nó là một vấn đề hiệu suất?

— RationalGeek

@jkohlhepp: Tôi muốn nói thêm rằng việc gỡ lỗi các bản dựng phát hành hơi phức tạp vì bạn sẽ mất một số thông tin (do JIT). Hầu như luôn luôn, bạn sẽ không thể thấy giá trị của các đối số phương thức. Để giải quyết vấn đề này, bạn có thể tạm thời vô hiệu hóa tối ưu hóa JIT bằng cách sử dụng này .

— Ilian Pinzon

Cảm ơn blowdart, và cảm ơn Ilian Pinzon về thông tin bổ sung. Tôi biết bạn không thể gỡ lỗi hoàn hảo với mã phát hành nhưng có PDB thì tốt hơn là không có gì.

— RationalGeek

Sử dụng cài đặt "đầy đủ" không ảnh hưởng đến hiệu suất. Nó chỉ đơn giản là cho phép một trình gỡ lỗi được gắn vào một tiến trình đang chạy.

— Matt Dillard

1

Câu hỏi hay trên MSDN Matt, msdn.microsoft.com/en-us/library/8cw0bt21 , tôi đang chờ câu trả lời.

— Luke Hutton

4

Tôi đang trong quá trình viết trình xử lý ngoại lệ chưa xử lý và dấu vết ngăn xếp bao gồm số dòng khi chỉ pdb được sử dụng, nếu không, tôi chỉ nhận được tên của Sub / Function khi tôi chọn Không có.

Nếu tôi không phân phối .pdb, tôi không nhận được số dòng trong dấu vết ngăn xếp ngay cả với bản dựng chỉ pdb.

Vì vậy, tôi đang phân phối (triển khai XCOPY trên mạng LAN) pdb cùng với exe từ ứng dụng VB của tôi.

— người hùng biện
nguồn