Olası Yükseltme Sorunlarına Genel Bakış (Visual C++)

Yıllar içinde, Microsoft C++ derleyicisi C++ dilinin kendisinde, C++ Standart Kitaplığında, C çalışma zamanında (CRT) ve MFC ve ATL gibi diğer kitaplıklarda yapılan değişikliklerle birlikte birçok değişikliğe uğramıştır. Sonuç olarak, visual studio'nun önceki bir sürümünden bir uygulamayı yükselttiğinizde, daha önce temiz bir şekilde derlenmiş kodda derleyici ve bağlayıcı hataları ve uyarıları görebilirsiniz. Özgün kod tabanı ne kadar eskiyse, bu tür hatalara yönelik olasılık o kadar artar. Bu genel bakış, görme olasılığınız olan sorunların en yaygın sınıflarını özetler ve daha ayrıntılı bilgilerin bağlantılarını sağlar.

Not

Geçmişte, Visual Studio'nun birkaç sürümüne yayılan yükseltmelerin tek seferde artımlı olarak bir sürüm gerçekleştirilmesi önerilir. Bu yaklaşımı artık önermeyiz. Kod tabanı ne kadar eski olursa olsun Visual Studio'nun en güncel sürümüne yükseltmenin neredeyse her zaman daha kolay olduğunu bulduk.

Yükseltme işlemiyle ilgili sorular veya açıklamalar adresine vcupgrade@microsoft.comgönderilebilir.

Kitaplık ve araç takımı bağımlılıkları

Not

Bu bölüm, Visual Studio 2013 ve önceki sürümlerle oluşturulmuş uygulamalar ve kitaplıklar için geçerlidir. Visual Studio 2015, Visual Studio 2017 ve Visual Studio 2019'da kullanılan araç kümeleri ikili uyumludur. Daha fazla bilgi için bkz . Visual Studio sürümleri arasında C++ İkili Uyumluluk.

Bir uygulamayı Visual Studio 2013'ten veya daha önceki bir sürümden daha yeni bir sürüme yükselttiğinızda, genellikle uygulamanın bağlantı olduğu tüm kitaplıkları ve DLL'leri yükseltmek hem önerilir hem de gereklidir. Kaynak koduna erişiminiz olması veya kitaplık satıcısının derleyicinin aynı ana sürümüyle derlenmiş yeni ikili dosyalar sağlaması gerekir. Bu koşullardan biri doğruysa, ikili uyumluluğun ayrıntılarıyla ilgilenen bu bölümü atlayabilirsiniz. Böyle bir durum söz konusu değilse, kitaplıklar yükseltilen uygulamanızda çalışmayabilir. Bu bölümdeki bilgiler, yükseltmeye devam edip etmeyeceğinizi anlamanıza yardımcı olacaktır.

Araç Takımı

.obj ve .lib dosya biçimleri iyi tanımlanmıştır ve nadiren değişir. Bazen bu dosya biçimlerine eklemeler yapılır, ancak bu eklemeler genellikle daha yeni araç kümelerinin eski araç kümeleri tarafından üretilen nesne dosyalarını ve kitaplıklarını kullanma becerisini etkilemez. En önemli özel durum, (Tüm Program İyileştirme) kullanarak /GL derlemenizdir. kullanarak /GLderlerseniz, sonuçta elde edilen nesne dosyasını yalnızca üretmek için kullanılan araç takımını kullanarak bağlayabilirsiniz. Bu nedenle, ile /GL bir nesne dosyası oluşturur ve Visual Studio 2017 (v141) derleyicisi kullanırsanız, Visual Studio 2017 (v141) bağlayıcısını kullanarak bağlamanız gerekir. Bunun nedeni, nesne dosyalarındaki iç veri yapılarının araç takımının ana sürümlerinde kararlı olmadığındandır. Daha yeni araç kümeleri eski veri biçimlerini anlamaz.

C++ kararlı bir uygulama ikili arabirimine (ABI) sahip değildir. Ancak Visual Studio, bir sürümün tüm ikincil sürümleri için kararlı bir C++ ABI tutar. Visual Studio 2015 (v140), Visual Studio 2017 (v141), Visual Studio 2019 (v142) ve Visual Studio 2022 (v143) araç kümeleri yalnızca ikincil sürümlerinde farklılık gösterir. Hepsi aynı ana sürüm numarasına sahiptir ve bu sayı 14'dür. Daha fazla bilgi için bkz . Visual Studio sürümleri arasında C++ İkili Uyumluluk.

C++ bağlantısına sahip dış sembolleri olan bir nesne dosyanız varsa, bu nesne dosyası araç takımının farklı bir ana sürümü tarafından üretilen nesne dosyalarıyla doğru bağlantı oluşturmayabilir. Birçok olası sonuç vardır: bağlantı tamamen başarısız olabilir (örneğin, ad düzenlemesi değiştiyse). Bağlantı başarılı olabilir, ancak uygulama çalışma zamanında başarısız olabilir (örneğin, tür düzenleri değiştiyse). Veya uygulamanız çalışmaya devam edebilir ve hiçbir sorun olmaz. Ayrıca, C++ ABI kararlı olmasa da, COM için gereken C++ ABI alt kümesinin ve C ABI'nin kararlı olduğunu unutmayın.

İçeri aktarma kitaplığına bağlanırsanız, çalışma zamanında ABI uyumluluğunu koruyan Visual Studio yeniden dağıtılabilir kitaplıklarının sonraki sürümleri kullanılabilir. Örneğin, Visual Studio 2015 Güncelleştirme 3 araç takımını kullanarak uygulamanızı derleyip bağlarsanız, daha sonra yeniden dağıtılabilir herhangi bir uygulamayı kullanabilirsiniz. Bunun nedeni 2015, 2017, 2019 ve 2022 kitaplıklarının geriye dönük ikili uyumluluğu korumasıdır. Tersi doğru değildir: Araç takımının önceki bir sürümü için kodunuzun herhangi bir bileşenini oluşturmak için kullandığınızdan daha eski bir sürümü için yeniden dağıtılabilir kullanamazsınız.

Kitaplıklar

#include Üst bilgi dosyalarının belirli bir sürümüne sahipseniz, sonuçta elde edilen nesne dosyasını kitaplıkların aynı sürümüne bağlamanız gerekir. Bu nedenle, örneğin kaynak dosyanızda Visual Studio 2015 Güncelleştirme 3 <immintrin.h>varsa, Visual Studio 2015 Güncelleştirme 3 vcruntime kitaplığıyla bağlantı oluşturmanız gerekir. Benzer şekilde, kaynak dosyanızda Visual Studio 2017 sürüm 15.5 <iostream>varsa, Visual Studio 2017 sürüm 15.5 Standart C++ kitaplığıyla msvcprtbağlantı oluşturmanız gerekir. Karıştırma ve eşleştirme desteklenmez.

C++ Standart Kitaplığı için, Visual Studio 2010'dan bu yana standart üst bilgilerde karıştırma #pragma detect_mismatch ve eşleştirme kullanımına açıkça izin verilmemiştir. Uyumsuz nesne dosyalarını bağlamaya çalışırsanız veya yanlış standart kitaplığa bağlanırsanız, bağlantı başarısız olur.

Eski CRT sürümü karıştırma ve eşleştirme hiçbir zaman desteklenmedi, ancak genellikle YALNıZCA API yüzeyi zaman içinde çok fazla değişmediği için çalıştı. Evrensel CRT geriye dönük uyumluluğu bozarak gelecekte geriye dönük uyumluluğu koruyabilmemizi sağlar. Gelecekte yeni, sürümlü Evrensel CRT ikili dosyalarını tanıtma planımız yok. Bunun yerine, mevcut Evrensel CRT artık yerinde güncelleştirilir.

Microsoft C Çalışma Zamanı üst bilgilerinin eski sürümleriyle derlenmiş nesne dosyaları (ve kitaplıkları) ile kısmi bağlantı uyumluluğu sağlamak için, legacy_stdio_definitions.libVisual Studio 2015 ve sonraki sürümleriyle bir kitaplığını sağlarız. Bu kitaplık, Evrensel CRT'den kaldırılan işlevlerin ve veri dışarı aktarmaların çoğu için uyumluluk simgeleri sağlar. tarafından legacy_stdio_definitions.lib sağlanan uyumluluk simgeleri kümesi, Windows SDK'sında yer alan kitaplıklardaki tüm bağımlılıklar dahil olmak üzere çoğu bağımlılığı karşılamak için yeterlidir. Ancak, uyumluluk simgeleri olmayan bazı simgeler Evrensel CRT'den kaldırıldı. Bu simgeler hem bazı işlevleri (örneğin, __iob_func) hem de bazı veri dışarı aktarmalarını (örneğin, __imp___iob, __imp___pctype, __imp___mb_cur_max) içerir.

C Çalışma Zamanı üst bilgilerinin eski bir sürümü kullanılarak oluşturulmuş bir statik kitaplığınız varsa, aşağıdaki eylemleri şu sırayla öneririz:

1. Visual Studio'nun yeni sürümünü ve Evrensel CRT üst bilgilerini kullanarak, Evrensel CRT ile bağlamayı desteklemek için statik kitaplığı yeniden oluşturun. Bu yaklaşım tam olarak desteklenir ve en iyi seçenektir.

2. Statik kitaplığı yeniden oluşturamıyorsanız (veya istemiyorsanız) ile legacy_stdio_definitions.libbağlamayı deneyebilirsiniz. Statik kitaplığınızın bağlantı zamanı bağımlılıklarını karşılarsa, statik kitaplığı ikili dosyada kullanıldığından kapsamlı bir şekilde test etmek istersiniz. Evrensel CRT'de yapılan davranış değişikliklerinden herhangi birinin olumsuz etkilenmediğinden emin olun.

3. Statik kitaplığınızın bağımlılıkları tarafından karşılanmamış legacy_stdio_definitions.lib olabilir veya davranış değişiklikleri nedeniyle kitaplık Evrensel CRT ile çalışmıyor olabilir. Bu durumda, statik kitaplığınızı Microsoft C Çalışma Zamanı'nın gerekli sürümüyle bağladığınız bir DLL'de kapsüllemenizi öneririz. Örneğin, statik kitaplık Visual Studio 2013 kullanılarak oluşturulduysa, bu DLL'yi Visual Studio 2013 araç takımını ve C++ kitaplıklarını kullanarak da derleyin. Kitaplığı bir DLL'ye oluşturarak, Microsoft C Çalışma Zamanı'nın belirli bir sürümüne bağımlılığı olan uygulama ayrıntılarını kapsüllersiniz. DLL arabiriminin hangi C Çalışma Zamanı'nı kullandığına ilişkin ayrıntıları sızdırmadığından, örneğin DLL sınırı boyunca bir FILE* döndürüyorsa veya mallocçağıranın kullanması gereken freebir ayrılmış işaretçiyse dikkatli olun.

Tek bir işlemde birden çok CRT kullanımı kendi içinde ve kendi içinde sorunlu değildir. (Aslında çoğu işlem birden çok CRT DLL'sini yükler. Örneğin, Windows işletim sistemi bileşenleri öğesine, msvcrt.dllCLR ise kendi özel CRT'sine bağlıdır.) Farklı CRT'lerden durum bilgisi aldığınızda sorunlar ortaya çıkar. Örneğin kullanarak bellek msvcr110.dll!malloc ayırmamalı ve kullanarak msvcr120.dll!freebu belleği serbest bırakmamalısınız ve kullanarak msvcr110!fopen bir FILE açmayı denememeli ve kullanarak msvcr120!freadbu DOSYADAN okumaya çalışmamalısınız. Farklı CRT'lerden durum bilgisi almadığınız sürece, tek bir işlemde birden çok CRT'nin güvenle yüklenmesini sağlayabilirsiniz.

Daha fazla bilgi için bkz . Kodunuzu Evrensel CRT'ye yükseltme.

Proje ayarlarından kaynaklanan hatalar

Yükseltme işlemine başlamak için Visual Studio'nun en son sürümünde eski bir proje/çözüm/çalışma alanı açın. Visual Studio, eski proje ayarlarına göre yeni bir proje oluşturur. Eski projenin kitaplık yolları olup olmadığını denetleyin veya standart olmayan konumlara sabit kodlanmış yollar ekleyin. Proje varsayılan ayarları kullandığında bu yollardaki dosyalar derleyici tarafından görülemez. Daha fazla bilgi için bkz . Bağlayıcı ÇıktıDosyası ayarı.

Genel olarak, proje bakımını basitleştirmek ve yükseltilen kodunuzun mümkün olan en kısa sürede derleştirilmesine yardımcı olmak için proje kodunuzu düzenlemek için harika bir zamandır. Kaynak kodunuz zaten iyi düzenlenmişse ve eski projeniz Visual Studio 2010 veya üzeri altında derleniyorsa, hem eski hem de yeni derleyicide derlemeyi desteklemek için yeni proje dosyasını el ile düzenleyebilirsiniz. Aşağıdaki örnekte hem Visual Studio 2015 hem de Visual Studio 2017 için nasıl derlenecek gösterilmektedir:

<PlatformToolset Condition="'$(VisualStudioVersion)'=='14.0'">v140</PlatformToolset>
<PlatformToolset Condition="'$(VisualStudioVersion)'=='15.0'">v141</PlatformToolset>

LNK2019: Çözümlenmemiş dış

Çözümlenmemiş simgeler için proje ayarlarınızı düzeltmeniz gerekebilir.

• Kaynak dosya varsayılan olmayan bir konumdaysa, projenin ekleme dizinlerinin yolunu eklediniz mi?

• Dış dosyada .lib tanımlanmışsa, proje özelliklerinde lib yolunu belirttiniz mi ve dosyanın orada bulunan doğru sürümü .lib mü?

• Visual Studio'nun farklı bir sürümüyle derlenmiş bir .lib dosyaya bağlanmaya mı çalışıyorsunuz? Öyleyse, kitaplık ve araç takımı bağımlılıkları ile ilgili önceki bölüme bakın.

• Çağrı sitesindeki bağımsız değişkenlerin türleri gerçekten işlevin mevcut aşırı yüklemesini eşleştirir mi? Hem işlevin imzasında hem de işlevi çağıran koddaki tür tanımları için temel türlerin beklediğiniz tür olduğunu doğrulayın.

Çözülmemiş simge hatalarını gidermek için ikili bir dosyada tanımlanan sembolleri incelemek için kullanabilirsiniz dumpbin.exe . Kitaplıkta tanımlanan simgeleri görüntülemek için aşağıdaki komut satırını deneyin:

dumpbin.exe /LINKERMEMBER somelibrary.lib

/Zc:wchar_t (wchar_t Yerel türdür)

(Microsoft Visual C++ 6.0 ve önceki wchar_t sürümlerinde yerleşik tür olarak uygulanmadı. içinde wchar.h için unsigned shortbir tür tanımı olarak bildirildi.) C++ standardı bunun yerleşik bir tür olmasını wchar_t gerektirir. typedef sürümünün kullanılması taşınabilirlik sorunlarına neden olabilir. Visual Studio'nun önceki sürümlerinden yükseltme yaparsanız ve kod örtük olarak 'wchar_tunsigned shorta dönüştürmeye çalıştığından derleyici hatası C2664'ü görürseniz, hatasını düzeltmek için ayarı /Zc:wchar_t-yerine kodu değiştirmenizi öneririz. Daha fazla bilgi için bkz /Zc:wchar_t . (wchar_t Yerel Türdür).

Bağlayıcı seçenekleri /NODEFAULTLIB, /ENTRYve ile yükseltme /NOENTRY

/NODEFAULTLIB Bağlayıcı seçeneği (veya Tüm Varsayılan Kitaplıkları Yoksay bağlayıcı özelliği), bağlayıcıya CRT gibi varsayılan kitaplıklara otomatik olarak bağlanmaması gerektiğini bildirir. Bu, her kitaplığın tek tek giriş olarak listelenmiş olması anlamına gelir. Bu kitaplık listesi, Proje Özellikleri iletişim kutusunun Bağlayıcı bölümündeki Ek Bağımlılıklar özelliğinde verilmiştir.

Bu seçeneği kullanan projeler, bazı varsayılan kitaplıkların içeriği yeniden düzenlendiğinden yükseltme sırasında bir sorun oluşturur. Her kitaplığın Ek Bağımlılıklar özelliğinde veya bağlayıcı komut satırında listelenmesi gerektiğinden, kitaplık listesini tüm geçerli adları kullanacak şekilde güncelleştirmeniz gerekir.

Aşağıdaki tabloda, Visual Studio 2015'den başlayarak içeriği değişen kitaplıklar gösterilmektedir. Yükseltmek için ikinci sütundaki yeni kitaplık adlarını ilk sütundaki kitaplıklara eklemeniz gerekir. Bu kitaplıklardan bazıları içeri aktarma kitaplıklarıdır, ancak bu önemli değildir.

Kullanıyorsanız:	Şu kitaplıkları kullanmanız gerekir:
libcmt.lib	libcmt.lib, libucrt.lib, libvcruntime.lib
libcmtd.lib	libcmtd.lib, libucrtd.lib, libvcruntimed.lib
msvcrt.lib	msvcrt.lib, ucrt.lib, vcruntime.lib
msvcrtd.lib	msvcrtd.lib, ucrtd.lib, vcruntimed.lib

Aynı sorun, varsayılan kitaplıkları atlamanın da etkisi olan seçeneğini veya /NOENTRY seçeneğini kullanırsanız /ENTRY da geçerlidir.

Geliştirilmiş dil uyumluluğu nedeniyle oluşan hatalar

Microsoft C++ derleyicisi yıllar içinde C++ standardına uyumluluğunu sürekli geliştirmiştir. Önceki sürümlerde derlenen kod, Visual Studio'nun sonraki sürümlerinde derlenemiyor olabilir. Bunun nedeni, derleyicinin daha önce yoksaydığı veya açıkça izin verilen bir hatayı doğru şekilde işaretlemesidir.

Örneğin, /Zc:forScope anahtar MSVC tarihinin başlarında tanıtıldı. Döngü değişkenleri için uyumsuz davranışa izin verir. Bu anahtar artık kullanım dışıdır ve gelecekteki sürümlerde kaldırılabilir. Kodunuzu yükseltirken bu anahtarı kullanmamanızı kesinlikle öneririz. Daha fazla bilgi için bkz /Zc:forScope- . kullanım dışı bırakıldı.

Yükseltme sırasında görebileceğiniz yaygın bir derleyici hatasına örnek olarak const olmayan bir bağımsız değişken const parametresine geçirilir. Derleyicinin eski sürümleri her zaman hata olarak işaretlemedi. Daha fazla bilgi için bkz . Derleyicinin daha katı dönüştürmeleri.

Belirli uyumluluk geliştirmeleri hakkında daha fazla bilgi için bkz. Visual Studio'da Visual C++ değişiklik geçmişi 2003 - 2015 ve C++ uyumluluk geliştirmeleri.

İntegral türleriyle ilgili <stdint.h> hatalar

<stdint.h> Üst bilgi, yerleşik tam sayı türlerinden farklı olarak tüm platformlarda belirtilen uzunlukta olması garanti edilen tür tanımlarını ve makroları tanımlar. Bazı örnekler ve int64_tşeklindediruint32_t. Üst <stdint.h> bilgi Visual Studio 2010'a eklendi. 2010'tan önce yazılmış olan kod, bu türler için özel tanımlar sağlamış olabilir. Ve bu tanımlar her zaman tanımlarla <stdint.h> tutarlı olmayabilir.

Hata C2371 ise ve bir stdint tür söz konusuysa, büyük olasılıkla türün kodunuzda veya üçüncü taraf kitaplık dosyanızda bir üst bilgide tanımlandığı anlamına gelir. Yükseltme sırasında, türlerin <stdint.h> özel tanımlarını ortadan kaldırmanız, ancak yeni sorunlar yaşamadığınızdan emin olmak için önce özel tanımları geçerli standart tanımlarla karşılaştırmanız gerekir.

Söz konusu türün nerede tanımlandığını görmek için F12 (Tanıma Git) tuşuna basabilirsiniz.

/showIncludes Derleyici seçeneği burada yararlı olabilir. Projenizin Özellik Sayfaları iletişim kutusunda, Yapılandırma Özellikleri>C/C++>Gelişmiş sayfasını seçin ve İçeriği Göster'i Evet olarak ayarlayın. Ardından projenizi yeniden oluşturun. Çıkış penceresinde dosya listesini #include görürsünüz. Her üst bilgi, bunu içeren üst bilginin altında girintili olarak gösterilir.

CRT işlevleriyle ilgili hatalar

Yıllar içinde C çalışma zamanında birçok değişiklik yapılmıştır. İşlevlerin birçok güvenli sürümü eklendi ve bazıları kaldırıldı. Ayrıca, bu makalenin önceki bölümlerinde açıklandığı gibi, Microsoft'un CRT uygulaması Visual Studio 2015'te yeni ikili dosyalar ve ilişkili .lib dosyalar halinde yeniden düzenlenmişti.

Bir CRT işleviyle ilgili bir hata varsa, bu makalelerin ek bilgi içerip içermediğini görmek için Visual Studio'da Visual C++ değişiklik geçmişi 2003 - 2015 veya C++ uyumluluk geliştirmelerini arayın. Hata LNK2019, işlevin kaldırılmadığından emin olun. Aksi takdirde, işlevin hala mevcut olduğundan ve çağıran kodun doğru olduğundan eminseniz projenizin kullanıp kullanmadığını /NODEFAULTLIBdenetleyin. Bu durumda, yeni evrensel (UCRT) kitaplıkları kullanmak için kitaplık listesini güncelleştirmeniz gerekir. Daha fazla bilgi için yukarıdaki Kitaplık ve bağımlılıklar bölümüne bakın.

Hata veya scanfiçeriyorsaprintf, dahil etmeden stdio.hher iki işlevi de özel olarak tanımlamadığınızdan emin olun. Öyleyse, özel tanımları kaldırın veya bağlantısına bağlanın legacy_stdio_definitions.lib. Bu kitaplığı, Ek Bağımlılıklar özelliğindeki Yapılandırma Özellikleri>Bağlayıcı>Girişi altındaki Özellik Sayfaları iletişim kutusunda ayarlayabilirsiniz. Windows SDK 8.1 veya önceki bir sürüme bağlantı verirseniz ekleyin legacy_stdio_definitions.lib.

Hata, biçim dizesi bağımsız değişkenlerini içeriyorsa, bunun nedeni büyük olasılıkla derleyicinin standardı zorunlu tutma konusunda daha katı olmasıdır. Daha fazla bilgi için değişiklik geçmişine bakın. Güvenlik riskini temsil etme olasılığı olduğundan buradaki hatalara çok dikkat edin.

C++ standardında yapılan değişikliklerin neden olduğu hatalar

C++ standardının kendisi, her zaman geriye dönük uyumlu olmayan yollarla gelişti. C++11, taşıma semantiği, yeni anahtar sözcükler ve diğer dil ve standart kitaplık özelliklerini kullanıma sunar. Bu değişiklikler derleyici hatalarının ve hatta farklı çalışma zamanının davranışına neden olabilir.

Örneğin, eski bir C++ programı üst bilgiyi içerebilir iostream.h . Bu üst bilgi C++ geçmişinin başlarında kullanım dışı bırakıldı ve sonunda Visual Studio'dan tamamen kaldırıldı. Bu durumda kodunuzu kullanmanız <iostream> ve yeniden yazmanız gerekir. Daha fazla bilgi için bkz . Eski iostream kodu güncelleştirme.

C4838: daraltma dönüştürme uyarısı

C++ standardı artık işaretsiz olandan imzalı tam sayı değerlerine dönüştürmelerin daraltma dönüştürmeleri olduğunu belirtiyor. Derleyici bu uyarıyı Visual Studio 2015'den önce tetiklemiyor. Daraltma işleminin kodunuzun doğruluğunu etkilemediğinden emin olmak için her oluşumu inceleyin.

Güvenli CRT işlevlerini kullanma uyarıları

Yıllar içinde C çalışma zamanı işlevlerinin güvenli sürümleri kullanıma sunulmuştur. Eski, güvenli olmayan sürümler hala kullanılabilir olsa da, kodunuzu güvenli sürümleri kullanacak şekilde değiştirmeniz önerilir. Derleyici, güvenli olmayan sürümlerin kullanımı için bir uyarı yayımlar. Bu uyarıları devre dışı bırakabilir veya yoksayabilirsiniz. Çözümünüzdeki tüm projeler için uyarıyı devre dışı bırakmak için Özellik Yöneticisini Görüntüle'yi>açın, uyarıyı devre dışı bırakmak istediğiniz tüm projeleri seçin, ardından seçili öğelere sağ tıklayın ve Özellikler'i seçin. Yapılandırma Özellikleri>C/C++>Gelişmiş altındaki Özellik Sayfaları iletişim kutusunda Belirli Uyarıları Devre Dışı Bırak'ı seçin. Açılan oku ve ardından Düzenle'yi seçin. Metin kutusuna 4996 girin. ('C' ön ekini eklemeyin.) Daha fazla bilgi için bkz . Güvenli CRT kullanmak için taşıma.

Windows API'lerindeki veya eski SDK'lardaki değişikliklerin neden olduğu hatalar

Yıllar içinde Windows API'leri ve veri türleri eklendi ve bazen değiştirildi veya kaldırıldı. Ayrıca, çekirdek işletim sistemine ait olmayan diğer SDK'lar da geldi ve gitti. Eski programlar artık mevcut olmayan API'lere çağrılar içerebilir. Bunlar, artık desteklenmeyen diğer Microsoft SDK'larındaki API'lere yönelik çağrılar da içerebilir. Eski Microsoft SDK'larından eksik Windows API'leri veya API'leriyle ilgili hatalar görebilirsiniz. API'ler daha yeni ve daha güvenli işlevler tarafından kaldırılmış veya yerini alınmış olabilir.

Windows API belgelerinde desteklenen en düşük veya en yüksek işletim sistemleri listelenir. Belirli bir Windows API'si hakkında bilgi için, masaüstü Windows uygulamaları için API Dizini'nde arayın.

Windows sürümü

Windows API'sini doğrudan veya dolaylı olarak kullanan bir programı yükseltirken, desteklenmesi gereken en düşük Windows sürümüne karar vermeniz gerekir. Çoğu durumda Windows 7 iyi bir seçimdir. Daha fazla bilgi için bkz . Üst bilgi dosyası sorunları. Makro, WINVER programınızın çalışmak üzere tasarlandığı en eski Windows sürümünü tanımlar. MFC programınız 0x0501 (Windows XP) olarak ayarlıysa WINVER , derleyici araç takımının kendisi XP moduna sahip olsa bile MFC artık XP'yi desteklemediğinden bir uyarı alırsınız. Windows XP için derleyici araç takımı desteği Visual Studio 2017'de sona erdi.

Daha fazla bilgi için bkz . Hedef windows sürümünü güncelleştirme ve Diğer güncel olmayan üst bilgi dosyaları.

ATL / MFC

ATL ve MFC görece kararlı API'lerdir, ancak zaman zaman değişiklikler yapılır. Daha fazla bilgi için bkz. Visual C++ değişiklik geçmişi 2003 - 2015, Visual Studio'da Visual C++ için yenilikler ve Visual Studio'da C++ uyumluluğu geliştirmeleri.

LNK 2005 _DllMain@12 MSVCRTD.lib içinde zaten tanımlanmış

Bu hata MFC uygulamalarında oluşabilir. CRT kitaplığı ile MFC kitaplığı arasında bir sıralama sorunu olduğunu gösterir. MFC'nin ve delete işleçlerini new sağlaması için önce bağlanması gerekir. Hatayı düzeltmek için Şu varsayılan kitaplıkları yoksay: MSVCRTD.lib ve mfcs140d.libanahtarını kullanın/NODEFAULTLIB. Ardından bu kitaplıkları ek bağımlılıklarla ekleyin.

32 ile 64 bit karşılaştırması

Özgün kodunuz 32 bit sistemler için derlenmişse, yeni bir 32 bit uygulama yerine (veya buna ek olarak) 64 bit bir sürüm oluşturma seçeneğiniz vardır. Genel olarak, önce programınızı 32 bit modunda derledikten sonra 64 bit'i denemeniz gerekir. 64 bit için derleme basittir, ancak bazı durumlarda 32 bit derlemeler tarafından gizlenen hataları ortaya çıkarabilir.

Ayrıca, ve işlevlerindeki işaretçi boyutu, zaman ve boyut değerleri ve boyuta özgü biçim tanımlayıcılarıyla ilgili olası derleme zamanı ve scanf çalışma zamanı sorunlarına da printf dikkat etmeniz gerekir. Daha fazla bilgi için bkz . 64 bit, x64 hedefleri ve Yaygın Visual C++ 64 bit geçiş sorunları için Visual C++ yapılandırma. Daha fazla geçiş ipucu için bkz . 64 bit Windows için programlama kılavuzu.

Unicode ve MBCS/ASCII karşılaştırması

Unicode standartlaştırılmadan önce, birçok program ASCII karakter kümesine dahil olmayan karakterleri temsil etmek için Çok Baytlı Karakter Kümesi'ni (MBCS) kullandı. Eski MFC projelerinde varsayılan ayar MBCS'ydi. Böyle bir programı yükselttiğiniz zaman, bunun yerine Unicode kullanılmasını öneren uyarılar görürsünüz. Unicode'a dönüştürmenin geliştirme maliyetine değeceğine karar verirseniz, uyarıyı devre dışı bırakabilir veya yoksayabilirsiniz. Bunu çözümünüzdeki tüm projelerde devre dışı bırakmak için Özellik Yöneticisini Görüntüle'yi>açın, uyarıyı devre dışı bırakmak istediğiniz tüm projeleri seçin, ardından seçili öğelere sağ tıklayın ve Özellikler'i seçin. Özellik Sayfaları iletişim kutusunda Yapılandırma Özellikleri>C/C++>Gelişmiş'i seçin. Belirli Uyarıları Devre Dışı Bırak özelliğinde açılan oku açın ve düzenle'yi seçin. Metin kutusuna 4996 girin. ('C' ön ekini eklemeyin.) Özelliği kaydetmek için Tamam'ı ve ardından değişikliklerinizi kaydetmek için Tamam'ı seçin.

Daha fazla bilgi için bkz . MBCS'den Unicode'a taşıma. MBCS ve Unicode hakkında genel bilgi için bkz. Visual C++ ve Uluslararasılaştırma'da Metin ve Dizeler .

Ayrıca bkz.

Visual C++'ın önceki sürümlerinden projeleri yükseltme
Visual Studio’deki C++ uyumluluk geliştirmeleri