Tại sao Visual Studio 2005 tạo các .pdb
tệ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?
Tại sao Visual Studio 2005 tạo các .pdb
tệ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?
Câu trả lời:
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ớ:
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.
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.
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 /bin
thư 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.
.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.
PDB có thể được tạo ra Release
cũ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
.
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ệ.
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ể.
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.
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 .
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
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 Info
tí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 csproj
tệp của dự án khởi động và thêm các mục sau (thay vì bất kỳ PostBuildEvent
thẻ 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.
*.xml
các tập tin, hãy cẩn thận với điều đó.
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.
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ố.