.Pdb dosyaları oluşturmayı bırakın, neden?


264

Visual Studio 2005 .pdb, sürümde derlerken neden dosyaları oluşturur ? Bir sürüm derlemesinde hata ayıklamayacağım, neden üretiliyorlar?


18
Neden gerçek hayatta pdb üretiyoruz? Yani vahşi bir çökme raporu geldiğinde hata ayıklamak için bilgi var. Diğer değer, orijinal yazar yapmazsa müşterilerin hata ayıklayabilmesidir.
Ian Boyd

@IanBoyd: Bu yorumun ikinci cümlesi, PDB'leri konuşlandırdığınız anlamına gelir. Bu arzu edilmeyen vakaların büyük çoğunluğundadır.
IInspectable

3
@Ingpectable Veya arzu edilir
Ian Boyd

@IanBoyd: Vakaların büyük çoğunluğu işletim sistemi dağıtımlarını içermez. Ayrıca, bu PDB'ler, PDB'ler oluştururken varsayılan olarak dahil edilen özel simgeler içermez.
IInspectable

PBDlerin bırakmadan Öte yandan @IInspectable olan arzu. İdeal olarak, evet, herkes IL'ye derlenmiş kod yazacaktır, böylece sembol bilgisini kendimiz alabiliriz. Ancak yerel kod derleyicilerinin hala hata ayıklamayı desteklemede kolay bir yolu yoktur.
Ian Boyd

Yanıtlar:


416

Çünkü PDB dosyaları olmadan, bir "Release" derlemesinde adres düzeyinde hata ayıklama dışında herhangi bir şeyle hata ayıklamak imkansız olacaktır. Optimizasyonlar gerçekten kodunuzda bir sayı yapar, bir şeyler ters giderse suçluyu bulmayı çok zorlaştırır (bir istisna atılır). Kesme noktalarının ayarlanması bile son derece zordur, çünkü kaynak kod satırları üretilen derleme koduyla bire bir (hatta aynı sırayla) eşleştirilemez. PDB dosyaları size ve hata ayıklayıcıya yardımcı olarak ölüm sonrası hata ayıklamayı önemli ölçüde kolaylaştırır.

Yazılımınız piyasaya sürülmeye hazırsa, o zamana kadar tüm hata ayıklama işlemlerinizi yapmalısınız. Bu kesinlikle doğru olsa da, akılda tutulması gereken birkaç önemli nokta var:

  1. Ayrıca "Release" derlemesini kullanarak uygulamanızı (yayınlamadan önce) test etmeli ve hatalarını ayıklamalısınız. Bunun nedeni, optimizasyonların açılması ("Hata Ayıkla" yapılandırması altında varsayılan olarak devre dışı bırakılmış olmaları) bazen başka şekilde yakalamayacağınız küçük hataların görünmesine neden olabilir. Bu hata ayıklamayı yaparken PDB sembollerini istersiniz.

  2. Müşteriler genellikle sadece "ideal" koşullar altında ortaya çıkan uç vakaları ve hataları rapor eder. Bunlar, laboratuarda çoğaltılması neredeyse imkansız olan şeylerdir, çünkü bu kullanıcının makinesinin bazı kurnaz konfigürasyonuna güvenirler. Özellikle yararlı müşteriler iseler, atılan istisnayı rapor ederler ve size yığın takibi sağlarlar. Ya da yazılımınızı uzaktan hata ayıklamak için makinelerini ödünç almanıza bile izin verirler. Bu iki durumda da PDB dosyalarının size yardımcı olmasını istersiniz.

  3. Profilleme her zaman optimizasyonlar etkinken "Release" derlemelerinde yapılmalıdır. Ve bir kez daha PDB dosyaları kullanışlı oluyor, çünkü montaj talimatlarının gerçekten yazdığınız kaynak koduyla eşleştirilmesine izin veriyorlar.

Derlemeden sonra geri dönüp PDB dosyalarını oluşturamazsınız . * Yapım sırasında bunları oluşturmazsanız, fırsatınızı kaybettiniz. Onları oluşturmak hiçbir şeye zarar vermez. Bunları dağıtmak istemiyorsanız, onları ikili dosyalarınızdan çıkarabilirsiniz. Ama daha sonra onları istediğinize karar verirseniz, şansınız kalmaz. İhtiyacınız olması durumunda, bunları her zaman oluşturmak ve arşivlemek daha iyidir.

Onları gerçekten kapatmak istiyorsanız, bu her zaman bir seçenektir. Projenizin Özellikler penceresinde, değiştirmek istediğiniz yapılandırma için "Hata Ayıklama Bilgisi" seçeneğini "yok" olarak ayarlayın.

"Ayıklama" ve "Release" yapılandırmaları Ancak, not Do do hata ayıklama bilgilerini yayan için varsayılan kullanımı farklı ayarları tarafından. Bu ayarı korumak isteyeceksiniz. "Hata Ayıklama Bilgisi" seçeneği, bir Hata Ayıklama derlemesi için "tam" olarak ayarlanır; bu, PDB dosyasına ek olarak hata ayıklama sembol bilgilerinin derlemeye gömülü olduğu anlamına gelir. Ayrıca, düzenle ve devam et gibi harika özellikleri destekleyen semboller de alırsınız. Release modunda, göründüğü gibi, derlemenin içeriğini etkilemeden yalnızca PDB dosyasını içeren "yalnızca pdb" seçeneği seçilir. Bu nedenle, /bindizininizdeki PDB dosyalarının varlığı veya yokluğu kadar basit değildir . Ancak "yalnızca pdb" seçeneğini kullandığınızı varsayarsak PDB dosyası '

* As Marc Sherman yorumunda işaret kaynak kodu değişmedi (veya bir sürüm kontrol sisteminden orijinal kodu alabilirsiniz) sürece, bunu yeniden ve eşleşen PDB dosyası oluşturabilir. En azından, genellikle. Bu çoğu zaman iyi çalışır, ancak aynı kodu her derlediğinizde derleyicinin aynı ikili dosyaları üreteceği garanti edilmez , bu nedenle küçük farklılıklar olabilir . Daha da kötüsü, bu arada araç zincirinizde herhangi bir yükseltme yaptıysanız (Visual Studio için bir hizmet paketi uygulamak gibi), PDB'lerin eşleşmesi daha az olasıdır. Ex postfacto'nun güvenilir üretimini garanti etmekPDB dosyaları, sürüm kontrol sisteminizdeki kaynak kodu değil, aynı zamanda yapı ortamınızın yapılandırmasını tam olarak yeniden oluşturabilmenizi sağlamak için tüm yapı araç zincirinizin ikili dosyalarını da arşivlemeniz gerekir. PDB dosyalarını oluşturmanın ve arşivlemenin çok daha kolay olduğunu söylemeye gerek yok.


19
Msgstr "Derlemeden sonra PDB dosyalarını oluşturamazsınız." - Kaynak kodunuz değişmediyse, gerçek durumdan sonra kullanılabilir bir PDB oluşturmak için yeniden oluşturabilirsiniz. Varsayılan olarak, windbg bu PDB'yi yüklemez, ancak / i seçeneğini bu şekilde belirterek yüklemeye zorlayabilirsiniz .reload /i foo.dll. Foo.dll serbest bırakıldıktan sonra foo.pdb oluşturulmuş olsa bile foo.pdb yükler.
Marc Sherman

Her yeni derlemenin farklı özet özetine sahip olduğunu fark ettim, bu yüzden aynı ortamda bile her derlemede küçük farklılıklar var. PDB'lerin adresleri varyansla değişemez mi, dolayısıyla PDB'yi bu derlemeden tutma ihtiyacı olur mu? Sadece bir fikir olarak ortaya koymak çünkü PDB'lerin nasıl çalıştığını veya karmalar arasındaki yapılar neden değiştiğini gerçekten anlamıyorum.
thebunnyrules

1
Dipnotta , "C # derleyicisinin tasarım gereği asla iki kez aynı ikiliyi üretmediğini" açıklayan bir makaleye bağlandım . C # derleyicisi, her çalıştırdığınızda her derlemede yeni oluşturulmuş bir GUID yerleştirir, böylece iki derlemenin olmamasını sağlar hiç bit-bit-özdeş. " Bu, neden farklı bir karmaya ve dolayısıyla farklı bir PDB dosyasına sahip olduğunu açıklar. Bu bir onaltılık düzenleyici ile düzeltilebilir, ancak kullanıcı dostu değildir. Ve ayrıca bu cevabın kapsamı dışında.
Cody Gray

3
Roslyn'de deterministik yapılar adı verilen yeni bir özellik var. "/ Deterministic bayrağı, aynı girdiler verildiğinde derleyicinin aynı EXE / DLL, bayt için bayt yaymasına neden olur." Bunun anlamı, bu bayrakla orijinal olarak derlenmiş bir projedir, derlediğiniz kod aynı olduğu sürece aynı ikili dosyaya yeniden derlenebilir. Roslyn
K Smith'deki

92

PDB için Releaseolduğu gibi üretilebilir Debug. Bu (VS2010'da ancak VS2005'te benzer olmalıdır) olarak ayarlanır:

Proje → Özellikler → Oluştur → Gelişmiş → Hata Ayıklama Bilgisi

Sadece olarak değiştirin None.


2
Ama bunu neden yaptın? Yazılımınız piyasaya
sürülmeye hazırsa

4
Çünkü üretim sorunlarını ayıklayabilirsiniz. Bir kez yapmak zorundaydık.
Aliostad

21
Üretim kodu için PDB'lerin başlığının avantajı, .NET'in bu dosyaları istisna atarken kullanmasıdır. Genellikle çok kullanışlı olan dosya adları ve satır numaraları ile yığın izleri oluşturur!
Steven

6
@ m.edmondson: Evet, doğru. Hala atılan istisna neyi haberdar olacak idi (gibi FileNotFoundException), ancak bir yığın izleme görmek mümkün olmayacaktır. Bu , istisnanın hangi kod satırının atılmasına neden olduğunu tam olarak tespit etmeyi çok zorlaştırır .
Cody Gray

2
@ m.edmondson Sadece üretim kutularınızdaki sorunlardan birinde hata ayıklamak için bir araç arıyorsanız eklemek için Windows SDK, uzaktan hata ayıklamayı destekleyen WinDbg adlı çok ünlü bir araçla birlikte gelir. Lütfen aşağıda belirtilen bağlantıya bir göz atın. Bu yardımcı olur umarım! msdn.microsoft.com/en-in/library/windows/hardware/…
RBT

8

.Pdb dosyaları olmadan üretim koduna adım atmak neredeyse imkansızdır; masraflı ve zaman alıcı olabilecek diğer araçlara güvenmeniz gerekir. Örneğin izleme veya windbg kullanabileceğinizi anlıyorum, ancak gerçekten ne elde etmek istediğinize bağlı. Belirli senaryolarda, belirli davranışı gözlemlemek için üretim verilerini kullanarak uzaktan kodda (hata veya istisna olmadan) adım atmak istersiniz ve bu .pdb dosyalarının kullanışlı olduğu yerdir. Onlar olmadan bu kodda hata ayıklayıcıyı çalıştırmak imkansızdır.


7

Sürüm sürümlerinde hata ayıklamayacağınızdan neden bu kadar eminsiniz? Bazen (umarım nadiren olur ama olur), bir nedenden dolayı hata ayıklama sürümünde yeniden üretilemeyen bir müşteriden bir hata raporu alabilirsiniz (farklı zamanlamalar, küçük farklı davranışlar veya her neyse). Bu sorun sürüm derlemesinde yeniden oluşturulabilir gibi görünüyorsa, eşleşen pdb'ye sahip olmaktan memnuniyet duyarsınız.


5
@ m.edmondson RDP, Webex vb. kullanarak uzak makineye erişin ve oraya windbg'yi yükleyin. Sembol yolunu ayarla ve bam, sen altınsın!
Marc Sherman

Daha ayrıntılı bir rehberin bağlantısı daha faydalı olabilirdi. Bu tek satırlık nasıl yapılırsa insanlar (benim gibi) yanlış yolda ilerleyebilir. Çoğu .NET geliştirici örneğin Windbg hakkında hiçbir şey bilmiyor.
nuzzolilo

1
@ m.edmondson - Visual Studio'nun bazı sürümleri uzaktan hata ayıklama gerçekleştirebilir. Hata ayıklama menüsünden, uzak makinedeki "işleme ekleyin".
Matthew

Bir üretim uygulaması örneğinde uzaktan hata ayıklama yapmak iyi bir fikir mi? Hata ayıklama sırasında iş parçacıklarının paralel yürütülmesini bozmayacak ve bunları seri olarak çalışmaya zorlamayacak mı?
Kaveh Hadjari

4

Ayrıca, yazılımınızda hata ayıklamak için çökme dökümlerini kullanabilirsiniz. Müşteri bunu size gönderir ve daha sonra kaynağınızın tam sürümünü tanımlamak için kullanabilirsiniz - ve Visual Studio, çökme dökümünü kullanarak doğru hata ayıklama simgeleri kümesini (ve doğru şekilde ayarlandığınızda kaynağı) bile çeker. Microsoft'un Symbol Stores hakkındaki belgelerine bakın .


2

.PDB dosyası "Program Veritabanı" nın kısa adıdır. Hata ayıklayıcı için hata ayıklama noktası ve kullanılan veya başvurulan kaynaklar hakkında bilgiler içerir. Hata ayıklama modu olarak oluşturulduğunda oluşturulur. Uygulamanın çalışma zamanında hata ayıklamak için izin verir.

Hata ayıklama modunda .PDB dosyasının boyutu artar. Uygulamamızı test ederken kullanılır.

PDB dosyası için iyi bir makale.

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


1
Birisi bu sürümde bir kilitlenme yaşadığı ve onlardan aldığınız kilitlenme raporunda kullanılabilir bir yığın izlemesi olmadığı sürece "serbest bırakıldığında veya dağıtıldığında bu dosyaya gerek yok ..." herşey.
Nyerguds

Doğru değil. .Pdb dosyaları olmadan, tam yığın izlemesi alırsınız, ancak kaynak dosya adları olmadan. Çökme raporu aldıktan sonra kurum içinde kurtarabilirsiniz. Fikri haklarınızı önemsiyorsanız ve kaynakları gizlerseniz, .pdb dosyalarını kaydetmeniz gerekir, ancak bunları dağıtmamanız gerekir.
TOP KEK

1

Çok projeli bir çözümde, genellikle hiç PDB veya XML dosyası oluşturmayan bir yapılandırmaya sahip olmak istersiniz. Debug InfoHer projenin özelliğini değiştirmek yerine, noneyalnızca belirli bir yapılandırmada çalışan bir post-build olayı eklemenin daha uygun olacağını düşündüm.

Ne yazık ki, Visual Studio farklı yapılandırmalar için farklı oluşturma sonrası olaylar belirtmenize izin vermez. Bu yüzden csproj, başlangıç ​​projesinin dosyasını düzenleyerek ve aşağıdakileri ekleyerek (mevcut herhangi bir PostBuildEventetiket yerine ) manuel olarak yapmaya karar verdim :

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

Ne yazık ki, bu post-build olay metin kutusunu boş yapacak ve içine bir şey koymak tahmin edilemeyen sonuçlar doğurabilir.


4
Bu TÜM *.xmldosyaları silecektir , buna dikkat edin.
Mariusz Jamro

0

Hata ayıklama sembolleri ( .pdb) ve XML doc ( .xml) dosyaları toplam boyutun büyük bir yüzdesini oluşturur ve normal dağıtım paketinin bir parçası olmamalıdır. Ancak ihtiyaç duyulması halinde bunlara erişmek mümkün olmalıdır.

Olası bir yaklaşım: TFS oluşturma sürecinin sonunda, bunları ayrı bir yapıya taşıyın.


-1

Aslında PDB dosyaları ve sembolik bilgileri olmadan başarılı bir kilitlenme raporu (bellek dökümü dosyaları) oluşturmak imkansız olurdu ve Microsoft sorunun nedenini tam olarak göremezdi.

Ve böylece PDB'ye sahip olmak çökme raporlamasını geliştirir.


Ancak .pdb dosyaları olmadan tam olarak ne eksik olacak?
TOP KEK

Derlemeden sonra PDB dosyalarını oluşturamazsınız. Bu nedenle, ne olduğunu doğru bir şekilde anlamak için major.minor [.build [.revision]] yazılımının her sürümü Microsoft'a kaydedilmiş olmalı, ancak hepsi bu değil.
prosti

Aynı kodu her derlediğinizde derleyicinin aynı ikili dosyaları üreteceği garanti edilmez.
prosti

Soru, kilitlenme raporlarında nelerin eksik olacağı ve kilitlenme raporlamasının nasıl etkileneceği idi. .NET pdb dosyaları yalnızca özel değişken adları ve kaynak dosya adları içerir. Diğer her şey (yöntem adları, imzalar vb.) Meta veri bilgilerinden yığın izinde olacaktır.
TOP KEK

Hiçbir PDB dosyası özel olmayan veriler de içermez: github.com/microsoft/microsoft-pdb .
prosti
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.