Phát hành tạo tập tin .pdb, tại sao?


264

Tại sao Visual Studio 2005 tạo các .pdbtệp khi biên dịch trong bản phát hành? Tôi sẽ không gỡ lỗi bản dựng phát hành, vậy tại sao chúng được tạo?


18
Tại sao tạo pdb trong realease? Vì vậy, khi một báo cáo sự cố xuất hiện từ tự nhiên, bạn có thông tin để gỡ lỗi nó. Giá trị khác là khách hàng có thể gỡ lỗi khi tác giả gốc sẽ không.
Ian Boyd

@IanBoyd: Câu thứ hai của nhận xét đó ngụ ý rằng bạn triển khai PDB. Điều này là trong phần lớn các trường hợp không mong muốn.
IInspectable

3
@IInspectable Hoặc là mong muốn
Ian Boyd

@IanBoyd: Phần lớn các trường hợp không bao gồm triển khai hệ điều hành. Ngoài ra, các PDB đó không chứa các ký hiệu riêng, được bao gồm theo mặc định, khi bạn tạo PDB.
IInspectable

@IInspectable Mặt khác, phát hành PBDs mong muốn. Lý tưởng nhất là có, mọi người sẽ viết mã được biên dịch cho IL, để chúng ta có thể tự lấy thông tin biểu tượng. Nhưng trình biên dịch mã gốc vẫn không có cách dễ dàng để hỗ trợ gỡ lỗi trong trường.
Ian Boyd

Câu trả lời:


416

Bởi vì không có các tệp PDB, sẽ không thể gỡ lỗi bản dựng "Phát hành" bởi bất kỳ thứ gì khác ngoài gỡ lỗi ở cấp địa chỉ. Tối ưu hóa thực sự làm một số trên mã của bạn, làm cho rất khó tìm ra thủ phạm nếu có sự cố xảy ra (giả sử, một ngoại lệ được đưa ra). Ngay cả việc thiết lập các điểm dừng là vô cùng khó khăn, bởi vì các dòng mã nguồn không thể khớp với từng điểm một với (hoặc thậm chí theo cùng thứ tự) mã lắp ráp được tạo. Các tệp PDB giúp bạn và trình gỡ lỗi thoát ra, giúp việc gỡ lỗi sau khi chết dễ dàng hơn đáng kể.

Bạn đưa ra quan điểm rằng nếu phần mềm của bạn đã sẵn sàng để phát hành, thì bạn nên thực hiện tất cả các sửa lỗi của mình trước đó. Mặc dù điều đó chắc chắn đúng, có một số điểm quan trọng cần ghi nhớ:

  1. Bạn cũng nên kiểm tra và gỡ lỗi ứng dụng của mình (trước khi phát hành ứng dụng) bằng cách sử dụng bản dựng "Phát hành". Đó là bởi vì bật tối ưu hóa (chúng bị tắt theo mặc định trong cấu hình "Gỡ lỗi") đôi khi có thể khiến các lỗi tinh vi xuất hiện mà bạn không thể bắt được. Khi bạn thực hiện việc sửa lỗi này, bạn sẽ muốn các biểu tượng PDB.

  2. Khách hàng thường xuyên báo cáo các trường hợp và lỗi chỉ xuất hiện trong điều kiện "lý tưởng". Đây là những thứ gần như không thể sao chép trong phòng thí nghiệm vì chúng dựa vào một số cấu hình kỳ quặc của máy người dùng đó. Nếu họ là khách hàng đặc biệt hữu ích, họ sẽ báo cáo ngoại lệ được ném và cung cấp cho bạn dấu vết ngăn xếp. Hoặc họ thậm chí sẽ cho bạn mượn máy của họ để gỡ lỗi phần mềm của bạn từ xa. Trong một trong những trường hợp đó, bạn sẽ muốn các tệp PDB hỗ trợ bạn.

  3. Cấu hình phải luôn luôn được thực hiện trên các bản dựng "Phát hành" với kích hoạt tối ưu hóa. Và một lần nữa, các tệp PDB có ích, bởi vì chúng cho phép các hướng dẫn lắp ráp được định hình để được ánh xạ trở lại mã nguồn mà bạn thực sự đã viết.

Bạn không thể quay lại và tạo các tệp PDB sau khi biên dịch. * Nếu bạn không tạo chúng trong quá trình xây dựng, bạn đã mất cơ hội. Nó không làm tổn thương bất cứ điều gì để tạo ra chúng. Nếu bạn không muốn phân phối chúng, bạn chỉ cần bỏ qua chúng từ các tệp nhị phân của mình. Nhưng nếu sau này bạn quyết định bạn muốn họ, bạn đã hết may mắn. Tốt hơn là luôn tạo chúng và lưu trữ một bản sao, chỉ trong trường hợp bạn cần chúng.

Nếu bạn thực sự muốn tắt chúng, đó luôn là một lựa chọn. Trong cửa sổ Thuộc tính của dự án, đặt tùy chọn "Thông tin gỡ lỗi" thành "không" cho bất kỳ cấu hình nào bạn muốn thay đổi.

Do lưu ý, tuy nhiên, "Debug" và "phát hành" cấu hình làm bằng cách sử dụng thiết lập mặc định khác nhau cho phát thông tin gỡ lỗi. Bạn sẽ muốn giữ cài đặt này. Tùy chọn "Thông tin gỡ lỗi" được đặt thành "đầy đủ" cho bản dựng Gỡ lỗi, có nghĩa là ngoài tệp PDB, thông tin ký hiệu gỡ lỗi được nhúng vào cụm. Bạn cũng nhận được các biểu tượng hỗ trợ các tính năng thú vị như chỉnh sửa và tiếp tục. Trong chế độ Phát hành, tùy chọn "chỉ pdb" được chọn, giống như âm thanh, chỉ bao gồm tệp PDB, mà không ảnh hưởng đến nội dung của cụm. Vì vậy, nó không hoàn toàn đơn giản như sự hiện diện hay vắng mặt của các tệp PDB trong /binthư mục của bạn . Nhưng giả sử bạn sử dụng tùy chọn "chỉ pdb", tệp PDB '

* Như Marc Sherman chỉ ra trong một nhận xét , miễn là mã nguồn của bạn không thay đổi (hoặc bạn có thể truy xuất mã gốc từ hệ thống kiểm soát phiên bản), bạn có thể xây dựng lại và tạo tệp PDB phù hợp. Ít nhất, thông thường. Điều này hoạt động tốt hầu hết thời gian, nhưng trình biên dịch không được đảm bảo để tạo các nhị phân giống hệt nhau mỗi khi bạn biên dịch cùng một mã , do đó có thể có sự khác biệt tinh tế. Tồi tệ hơn, nếu bạn đã thực hiện bất kỳ nâng cấp nào cho chuỗi công cụ của mình trong thời gian này (như áp dụng gói dịch vụ cho Visual Studio), các PDB thậm chí còn ít có khả năng khớp. Để đảm bảo thế hệ đáng tin cậy của exfactoCác tệp PDB, bạn sẽ cần lưu trữ không chỉ mã nguồn trong hệ thống kiểm soát phiên bản của mình, mà cả các tệp nhị phân cho toàn bộ chuỗi công cụ xây dựng của bạn để đảm bảo rằng bạn có thể tạo lại chính xác cấu hình của môi trường xây dựng của mình. Không cần phải nói rằng việc tạo và lưu trữ các tệp PDB sẽ dễ dàng hơn nhiều.


19
"Bạn không thể tạo các tệp PDB sau khi biên dịch." - Nếu mã nguồn của bạn không thay đổi thì bạn có thể xây dựng lại để tạo PDB có thể sử dụng được sau thực tế. Theo mặc định, Windbg sẽ không tải PDB này nhưng bạn có thể buộc nó tải bằng cách chỉ định tùy chọn / i như thế này .reload /i foo.dll. Điều đó sẽ tải foo.pdb ngay cả khi foo.pdb được tạo sau khi phát hành foo.dll.
Marc Sherman

Tôi nhận thấy rằng mỗi trình biên dịch mới có thông báo băm khác nhau, do đó, có sự khác biệt nhỏ với mỗi bản dựng ngay cả trong cùng một môi trường. Các địa chỉ cho các PDB không thể thay đổi theo phương sai, do đó cần phải giữ PDB khỏi bản dựng đó? Chỉ đưa ra ý tưởng này vì tôi không thực sự hiểu cách thức hoạt động của PDB hoặc lý do băm thay đổi giữa các bản dựng.
thebunnyrules

1
@the Trong phần chú thích, tôi đã liên kết với một bài viết giải thích rằng "trình biên dịch C # theo thiết kế không bao giờ tạo ra cùng một nhị phân hai lần. Trình biên dịch C # nhúng một GUID mới được tạo trong mỗi hội đồng, mỗi khi bạn chạy nó, do đó đảm bảo rằng không có hai hội đồng nào là giống hệt nhau từng chút một. " Điều đó giải thích tại sao nó có hàm băm khác nhau và do đó, tệp PDB khác nhau. Điều này có thể sửa được với trình soạn thảo hex, nhưng không thân thiện với người dùng. Và cũng nằm ngoài phạm vi của câu trả lời này.
Cody Grey

3
Có một tính năng mới trong Roslyn được gọi là bản dựng xác định. "Cờ / quyết định làm cho trình biên dịch phát ra cùng một EXE / DLL, byte cho byte, khi được cung cấp cùng một đầu vào." Điều này có nghĩa là một dự án được biên dịch theo nguyên tắc với cờ này, có thể được biên dịch lại thành cùng một nhị phân, miễn là mã bạn đang biên dịch giống nhau. Một lời giải thích dài hơn có thể được tìm thấy tại các bản dựng Xác định ở Roslyn
K Smith

92

PDB có thể được tạo ra Releasecũng như cho Debug. Điều này được đặt tại (trong VS2010 nhưng trong VS2005 phải tương tự):

Dự án → Thuộc tính → Xây dựng → Nâng cao → Thông tin gỡ lỗi

Chỉ cần thay đổi nó thành None.


2
Nhưng tại sao bạn lại làm vậy? Nếu phần mềm của bạn đã sẵn sàng để phát hành thì bạn nên thực hiện tất cả các sửa lỗi của mình trước đó
m.edmondson

4
Bởi vì bạn có thể gỡ lỗi các vấn đề sản xuất. Một khi chúng tôi phải làm điều đó.
Aliostad

21
Lợi thế của tiêu đề PDB cho mã sản xuất là .NET sẽ sử dụng các tệp này khi đưa ra các ngoại lệ. Nó tạo ra dấu vết ngăn xếp với tên tệp và số dòng, thường rất tiện dụng!
Steven

6
@ m.edmondson: Vâng, đúng rồi. Bạn vẫn sẽ được thông báo ngoại lệ ném là gì (như thế nào FileNotFoundException), nhưng bạn sẽ không thể thấy dấu vết ngăn xếp. Điều đó làm cho rất khó để xác định chính xác dòng mã nào đã gây ra ngoại lệ.
Cody Grey

2
@ m.edmondson Chỉ cần thêm nếu bạn đang tìm kiếm một công cụ để gỡ lỗi từ xa một trong những vấn đề trong hộp sản xuất của bạn thì Windows SDK đi kèm với một công cụ rất nổi tiếng có tên WinDbg hỗ trợ gỡ lỗi từ xa. Xin vui lòng xem các liên kết được đề cập dưới đây. Hi vọng điêu nay co ich! msdn.microsoft.com/en-in/l Library / windows / hardware / từ
RBT

8

Không có các tệp .pdb, hầu như không thể thực hiện được thông qua mã sản xuất; bạn phải dựa vào các công cụ khác có thể tốn kém và mất thời gian. Tôi hiểu rằng bạn có thể sử dụng theo dõi hoặc Windbg chẳng hạn nhưng nó thực sự phụ thuộc vào những gì bạn muốn đạt được. Trong một số trường hợp nhất định, bạn chỉ muốn chuyển qua mã từ xa (không có lỗi hoặc ngoại lệ) bằng cách sử dụng dữ liệu sản xuất để quan sát hành vi cụ thể và đây là nơi các tệp .pdb trở nên tiện dụng. Không có họ chạy trình gỡ lỗi trên mã đó là không thể.


7

Tại sao bạn chắc chắn rằng bạn sẽ không gỡ lỗi bản dựng phát hành? Đôi khi (hy vọng hiếm khi xảy ra) bạn có thể nhận được báo cáo lỗi từ khách hàng không thể sao chép trong phiên bản gỡ lỗi vì một số lý do (thời gian khác nhau, hành vi nhỏ khác nhau hoặc bất cứ điều gì). Nếu vấn đề đó dường như có thể tái tạo trong bản phát hành, bạn sẽ rất vui khi có pdb phù hợp.


5
@ m.edmondson Truy cập vào máy từ xa bằng RDP, Webex, v.v. và cài đặt Windbg ở đó. Thiết lập đường dẫn biểu tượng của bạn và bam, bạn là vàng!
Marc Sherman

Một liên kết đến một hướng dẫn chi tiết hơn sẽ hữu ích hơn. Cách làm một dòng này có thể khiến mọi người (như bản thân tôi) đi sai đường. Hầu hết các nhà phát triển .NET sẽ không biết gì về Windbg chẳng hạn.
nuzzolilo

1
@ m.edmondson - Một số phiên bản của Visual Studio có khả năng thực hiện gỡ lỗi từ xa. Từ menu gỡ lỗi, bạn "đính kèm để xử lý" trên máy từ xa.
Matthew

Đó có phải là một ý tưởng tốt để gỡ lỗi từ xa một ví dụ ứng dụng sản xuất? Nó sẽ không phá vỡ sự thực thi song song của các luồng và buộc chúng chạy nối tiếp trong khi gỡ lỗi?
Kaveh Hadjari

4

Ngoài ra, bạn có thể sử dụng các bãi đổ vỡ để gỡ lỗi phần mềm của bạn. Khách hàng gửi nó cho bạn và sau đó bạn có thể sử dụng nó để xác định phiên bản chính xác của nguồn của mình - và Visual Studio thậm chí sẽ lấy đúng bộ ký hiệu gỡ lỗi (và nguồn nếu bạn được thiết lập chính xác) bằng cách sử dụng kết xuất sự cố. Xem tài liệu của Microsoft về Cửa hàng Biểu tượng .


2

Tệp .PDB là tên viết tắt của "Cơ sở dữ liệu chương trình". Nó chứa thông tin về điểm gỡ lỗi cho trình gỡ lỗi và tài nguyên được sử dụng hoặc tham chiếu. Nó được tạo ra khi chúng ta xây dựng như chế độ gỡ lỗi. Nó cho phép ứng dụng để gỡ lỗi trong thời gian chạy.

Kích thước là tăng tệp .PDB trong chế độ gỡ lỗi. Nó được sử dụng khi chúng tôi đang thử nghiệm ứng dụng của chúng tôi.

Bài viết tốt của tập tin pdb.

http://www.codeproject.com/Articles/37456/How-To-Inspect-the-Content-of-a-Program-Database-P


1
"Không cần tệp này khi phát hành hoặc triển khai" ngoại trừ khi ai đó gặp sự cố trong phiên bản đã phát hành đó và báo cáo sự cố bạn nhận được từ họ không chứa dấu vết ngăn xếp có thể sử dụng ... sau đó bạn sẽ muốn bạn đưa nó vào sau tất cả.
Nyerguds

Không đúng. Không có tệp .pdb, bạn sẽ nhận được đầy đủ stacktrace, nhưng không có tên tệp nguồn. Bạn có thể khôi phục nó trong nhà sau khi nhận được báo cáo sự cố. Nếu bạn quan tâm đến quyền sở hữu trí tuệ và các nguồn gây khó chịu, bạn phải lưu tệp .pdb nhưng không được triển khai chúng.
HÀNG ĐẦU HÀNG TUẦN

1

Trong một giải pháp đa dự án, bạn thường muốn có một cấu hình không tạo ra các tệp PDB hoặc XML nào cả. Thay vì thay đổi thuộc Debug Infotính của mọi dự án thành none, tôi nghĩ sẽ tốt hơn nếu thêm một sự kiện hậu xây dựng chỉ hoạt động trong một cấu hình cụ thể.

Thật không may, Visual Studio không cho phép bạn chỉ định các sự kiện hậu xây dựng khác nhau cho các cấu hình khác nhau. Vì vậy, tôi quyết định thực hiện việc này một cách thủ công, bằng cách chỉnh sửa csprojtệp của dự án khởi động và thêm các mục sau (thay vì bất kỳ PostBuildEventthẻ hiện có nào ):

  <PropertyGroup Condition="'$(Configuration)' == 'Publish'">
    <PostBuildEvent>
        del *.pdb
        del *.xml
    </PostBuildEvent>
  </PropertyGroup>

Thật không may, điều này sẽ làm cho hộp văn bản sự kiện xây dựng bài viết trống và đặt bất cứ điều gì vào nó có thể có kết quả không thể đoán trước.


4
Điều này sẽ xóa TẤT CẢ *.xmlcác tập tin, hãy cẩn thận với điều đó.
Mariusz Jamro

0

Các tệp biểu tượng gỡ lỗi ( .pdb) và tài liệu XML ( .xml) chiếm tỷ lệ lớn trong tổng kích thước và không phải là một phần của gói triển khai thông thường. Nhưng nó có thể truy cập chúng trong trường hợp cần thiết.

Một cách tiếp cận khả thi: khi kết thúc quá trình xây dựng TFS, hãy chuyển chúng sang một tạo phẩm riêng biệt.


-1

Trên thực tế nếu không có tệp PDB và thông tin tượng trưng họ có thì sẽ không thể tạo báo cáo sự cố thành công (tệp kết xuất bộ nhớ) và Microsoft sẽ không có bức tranh hoàn chỉnh gây ra sự cố.

Và do đó, có PDB cải thiện báo cáo sự cố.


Nhưng chính xác những gì sẽ thiếu nếu không có tập tin .pdb?
HÀNG ĐẦU HÀNG TUẦN

Bạn không thể tạo các tệp PDB sau khi biên dịch. Vì vậy, mọi phiên bản của phần mềm Major.minor [.build [.revision]] nên được lưu tại Microsoft để hiểu chính xác những gì đã xảy ra, nhưng đây không phải là tất cả.
prosti

Trình biên dịch không được đảm bảo để tạo các nhị phân giống hệt nhau mỗi khi bạn biên dịch cùng một mã.
prosti

Câu hỏi đặt ra là những gì sẽ thiếu trong các báo cáo sự cố và cách báo cáo sự cố sẽ bị ảnh hưởng. Tệp .NET pdb chỉ chứa tên biến riêng và tên tệp nguồn. Mọi thứ khác (tên phương thức, chữ ký, v.v.) sẽ nằm trong stacktrace từ thông tin siêu dữ liệu.
HÀNG ĐẦU HÀNG TUẦN

Không có tệp PDB nào cũng chứa dữ liệu không riêng tư: github.com/microsoft/microsoft-pdb .
prosti
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.