“Tür veya ad alanı adı bulunamadı” ancak her şey yolunda görünüyor mu?

Ben alıyorum:

tür veya ad alanı adı bulunamadı

VS2010 bir C # WPF uygulaması hatası. Bu kod alanı iyi derleme, ama aniden bu hatayı alıyorum. Proje Referansını kaldırmayı denedim veusing deyimi , VS2010 kapatılıyor ve yeniden başlatılıyor, ama yine de bu sorun var.

Bunun neden olabileceğine dair herhangi bir fikir, nerede doğru şeyi yapıyorum gibi görünüyor Referans & using ifade?

VS2010'da, bu ad alanı için intellisense'ın iyi çalıştığını da belirttim, bu yüzden VS2010'un proje referansına sahip olduğunu ve bir yandan ad alanını görüyor gibi görünüyor, ancak derleme sırasında görmüyor mu?

Bu, iki proje arasındaki .Net framework sürümü uyumsuzluğunun bir sonucu olabilir.

İki şekilde olabilir:

1. tam çerçeve projeye referans veren bir müşteri profili projesi; veya
2. daha yeni bir çerçeve sürümünü hedefleyen daha eski bir çerçeve sürümü

Örneğin, bir uygulama .Net 4 İstemci Profili çerçevesini hedefleyecek şekilde ayarlandığında ve başvurduğu proje tam .Net 4 çerçevesini hedefler.

Bunu daha açık hale getirmek için:

• Proje A, Müşteri Profili çerçevesini hedefliyor
• Proje A referansları Proje B
• B Projesi tam çerçeveyi hedefliyor

Bu durumda çözüm, uygulamanın çerçeve hedefini yükseltmek (Proje A) veya başvurulan derlemenin hedefini düşürmektir (Proje B). Tam çerçeve uygulamasının bir istemci profili çerçeve derlemesine başvurması / tüketmesi uygundur, ancak tam tersi değil (istemci profili tam çerçeve hedefli derlemeye başvuramaz).

Bu hatayı VS2012 veya VS2013'te (varsayılan çerçeve olarak .Net 4.5 kullanan) yeni bir proje oluşturduğunuzda da alabileceğinizi ve:

• referans projelerinde .Net 4.0 kullanılır (bu, VS2010'dan VS2012 veya VS2013'e geçiş yaptığınızda ve daha sonra yeni bir proje eklediğinizde yaygındır)

• başvurulan projeler daha büyük bir sürümünü kullanır, yani 4.5.1 veya 4.5.3 (mevcut projelerinizi en son sürüme yeniden hedeflediniz, ancak VS hala v4.5'i hedefleyen yeni projeler oluşturuyor ve daha sonra bu eski projeleri yeni proje)

Nuget paketlerini yeniden yüklemek benim için hile yaptı. .NET Framework sürümlerini tüm projeler için senkronize olacak şekilde değiştirdikten sonra, bazı nuget paketleri (özellikle Entity Framework) önceki sürümler için hala yüklendi. Packages Manager Console'daki bu komut, tüm çözüm için paketleri yeniden yükler:

Update-Package –reinstall

Bunun neden işe yaradığını bilmiyorum, ama VS2015'in bana bulamadığını söylediği proje referansını kaldırdım ve tekrar ekledim. Sorun çözüldü. Temizlik, bina ve VS boşuna denedim denedim.

Çözümü oluştururken aynı hatayı alıyordum (tür veya ad alanı '' bulunamadı). Altında "referansın çözümlenemediğini" ve "montajın diskte bulunduğundan" emin olmak için bir uyarı gördüm .

Benim DLL çok açıkça referans işaret ettiği yerde olduğu için çok karışıktı. Çözümü oluşturmaya çalışana kadar VS herhangi bir hatayı vurgulamıyordu.

Sonunda sorunu fark ettim (ya da en azından sorundan şüphelendiğim şey). Kütüphane dosyasını aynı çözümde inşa ediyordum. Bu yüzden diskte mevcut olmasına rağmen, o konumda yeniden inşa ediliyordu (bir şekilde kütüphanenin diğer projemi yeniden inşa etme sürecinde - aynı çözümde - kütüphaneye atıfta bulunan kütüphanenin var olmadığına karar vermesi gerekir)

Projeye sağ tıklayıp tüm çözümü yerine yalnızca onu oluşturduğumda hatayı alamadım.

Bu sorunu gidermek için kitaplığı, onu kullanan projeye bağımlılık olarak ekledim.

Bunu yapmak için:

1. Çözüm Gezgini'nde Çözümümü sağ tıklayıp "Özellikler" i seçtim
2. Sonra "Ortak Özellikler" de "Proje Bağımlılıkları" nı seçtim.
3. Sonra Projeler açılır menüsünde kütüphaneye dayanan projeyi seçtim ve
4. "Bağımlı" bölümünde bulunan kitaplığın yanındaki kutuyu işaretleyin

Bu, önce kütüphane projesinin inşa edilmesini sağlar.

İlk olarak, projenizin oluşturulan bilgilerinin bozuk olmadığını doğrularım. Temizleyin ve çözümünüzü yeniden oluşturun.

Bu işe yaramazsa, tasarımcı sorunları için geçmişte çalıştığım bir şey, bir Windows formları projesi açmak, sonra tekrar kapatmak. Bu biraz tavuk bağırsağı-ish, bu yüzden nefesinizi tutmayın.

Karşılaştığım daha zor bir durum şuydu: Birinci proje, Microsoft.Bcl.Asyncpaketin yüklü olduğu 4.0 tam çerçeveyi hedefliyor . İkinci proje 4.0 tam çerçevesini hedeflemektedir ancak bir Project tek sınıfına başvurulduğunda derlenmeyecektir.

İkinci projeye Async NuGet paketini yükledikten sonra iyi derlendi.

Benim durumumda, VisualStudio'daki referansın bir üçgen ve bir ünlem işareti olduğunu görüyorum,

sonra, sağ tıklayın ve dll referansını tekrar doğru bir şekilde ekleyin, sorun çözüldü.

Bu benim için çalıştı. Sınıf adının tanımlandığı sınıfınızda, örneğin: Genel sınıf ABC, bir karakteri kaldırın ve biraz bekleyin. Adı değiştirdiğiniz için hata listeniz artacaktır. Şimdi yazdığınız karakteri geri koyun. Bu benim için çalıştı, umarım senin için de çalışır. İyi şanslar!!!

Benzer bir sorun vardı: Derleyici aynı proje içindeki bir klasörü algılayamadı , bu nedenle o klasöre bağlantı direktifini kullanarak bir hata oluştu . Benim durumumda, sorun klasörü yeniden adlandırmaktan kaynaklandı . Bu klasördeki tüm sınıfların ad alanını güncellesem de proje bilgileri bir şekilde güncellenemedi. Her şeyi denedim: .suo dosyasını ve bin ve obj klasörlerini silmek, çözümü temizlemek, projeyi yeniden yüklemek - hiçbir şey yardımcı olmadı. Klasörü ve içindeki sınıfları silerek, yeni bir klasör oluşturarak ve bu yeni klasörde yeni sınıflar oluşturarak sorunu çözdüm (sadece sınıfları yeni klasörün içine taşımak yardımcı olmadı).

Not: Benim durumumda bir web uygulaması üzerinde çalışıyordum, ancak bu sorun farklı projelerde ortaya çıkabilir.

[Facepalm] Benim sorunum, bir şeyleri yapmak için C ++ tarzına bağımlılığı eklediğim oldu.

Oluşturulmayacak projeye gidin, Solution Explorer'da 'Başvurular' klasörünü açın ve bağımlılığınızın listelenip listelenmediğine bakın.

Değilse, 'Referans Ekle'yi seçebilir ve Projeler sekmesinden bağımlılığı seçebilirsiniz.

Boom Shankar.

Bu konuda garip bir durum yaşadık. Ana projede "using" ifadesinin önünde gizli / boşluk karakteri vardı. Bu proje iyi inşa edilecek ve web sitesi iyi çalışacaktı, ancak referans veren birim test projesi inşa edilemedi.

Mevcut projeleri VS2008'den VS2012'ye yükseltirken bu sorunla karşılaştım. İki projenin (sadece oluşturduğum iki proje) farklı .Net Frameworks (3.5 ve 4.0) hedeflediğini buldum. Her iki projenin de Hedef Çerçeve kutusunda ".NET Framework 4" olduğundan emin olarak projelerin Uygulama sekmesinde bu sorunu çözdüm.

Aynı hatalar vardı, benim hikayem şuydu: kötü birleştirme (git üzerinden) sonra .csproj dosyalarımdan biri compilegibi yinelenen girişler vardı :

<Compile Include="Clients\Tree.cs" />
<Compile Include="Clients\Car.cs" />
<Compile Include="Clients\Tree.cs" />        //it's a duplicate

Büyük bir çözüm ve hatalar penceresinde 300'den fazla mesajınız varsa, bu sorunu tespit etmek zor. Bu yüzden hasarlı .csproj dosyasını not defteri ile açtım ve yinelenen girişleri kaldırdım. Benim durumumda çalıştı.

Tartışılanla aynı problemim vardı: VS 2017 referans olarak verilen projede bir sınıfın hata olarak altını çiziyor, ancak çözüm tamam ve hatta akıllıca çalışıyor.

İşte bu issu çözmek için nasıl başardı:

1. Başvurulan projeyi kaldırın
2. VS'de .proj dosyasını açın (burada önerildiği gibi yinelenenleri arıyordum)
3. Projeyi tekrar yükle (Yinelenmediğim için projeyi değiştirmedim, hatta kaydetmedim)

Ayrıca , sorun yaşadığınızı düşündüğünüz kodu kaldırmayı ve kodla ilgili herhangi bir referans olmadan derlenip derlenmediğini görmeyi de deneyebilirsiniz . Değilse, tekrar derlenene kadar bir şeyleri düzeltin ve şüpheli sorun kodunuzu tekrar çalıştırın. Bazen derleyici başka bir şeyden hoşlanmadığı zaman bildiğim sınıflar veya yöntemler hakkında garip hatalar alıyorum. Gerçekten asıldığı şeyi düzelttiğimde, bu 'hayalet' hatalar ortadan kalkıyor.

Bunun ölü bir atı vurduğunu biliyorum ama bu hatayı ve çerçevelerin iyi olduğunu gördüm. Benim sorunum temelde bir arayüz bulunamadı, ancak inşa ve sadece iyi erişildiğini belirten oldu. Bu yüzden şunu düşünmeliyim: "Neden diğerleri sadece bu arayüz iyi çalışıyor?"

Aslında, Entity Sürüm 6'yı kullanan bir uç nokta arayüzü ile WCF kullanarak bir hizmete erişiyordum ve projelerin geri kalanı sürüm 5'i kullanıyordu. NuGet kullanmak yerine nuget paketlerini yeniden kullanmak için yerel bir depoya kopyaladım onları farklı listeledi.

Örneğin EntityFramework6.dll karşı EntityFramework.dll .

Sonra istemci proje ve pof referansları ekledim, benim hatam gitti. Çoğu insanın Entity Framework sürümlerini karıştırmayacağı için bunun önemli bir durum olduğunun farkındayım.

Karışıma benim çözümüm ekleniyor çünkü biraz farklıydı ve anlaması biraz zaman aldı.

Benim durumumda, bir projeye yeni bir sınıf ekledim, ancak sürüm denetim bağlarım ayarlanmadığı için dosyayı Visual Studio'nun dışında (VC aracılığıyla) yazılabilir hale getirmem gerekiyordu. Visual Studio'da kaydetme işlemini iptal ettim ama dosyayı VS dışında yazılabilir hale getirdikten sonra VS'de Save All'a tekrar vurdum. Bu, yanlışlıkla yeni sınıf dosyasının projeye kaydedilmemesine neden oldu ... her nasılsa ... Intellisense, dosyayı yeniden derlemeye çalıştığımda ve dosyayı bulamadığımda bile mavi ve referans projelerinde geçerli olduğunu gösterdi. tür bulunamadı hatası. Visual Studio'nun kapatılması ve açılması sorunu hala gösterdi (ancak not almış olsaydım, yeniden açıldığında sınıf dosyası eksikti).

Bunu fark ettiğimde, düzeltme basitti: proje dosyası yazılabilir olarak ayarlandığında, eksik dosyayı projeye okudum. Şimdi her şey yolunda.

Aynı sorunu yaşadım. Bir gece projem ertesi sabah ERRORS!

Sonunda visual studio'nun bazı referanslarımı "düzeltmeye" karar verdiğini ve onları başka bir yere yönlendirdiğini öğrendim. Örneğin:

System.ComponentModel.ISupportInitialize bir şekilde "blahblah.System.ComponentModel.ISupportInitialize" oldu

Eğer benim gibi vs yapmak için oldukça kaba bir şey

Olay, Visual Studio 2017'de gerçekleşir.

1. Visual Studio'yu yeniden başlat
2. Oluşturulamayan temiz proje.
3. Projeyi yeniden oluşturun.

Benim durumum burada tartışılanla aynıydı, ancak System.Corereferanslar listesinden referans kaldırılıncaya kadar hiçbir şey çözülmedi (Her şey onsuz iyi çalıştı)

umarım birine yardım eder çünkü bu konu oldukça sinir bozucu

Bu sorunu çözmek *.sln.DotSettingsiçin ilgili çözümün dosyasını silmek ve yeniden oluşturmak da yardımcı olabilir .

Benim durumumda, uygun kaynak klasöründe listelenen ancak Solution Explorer'da kayıtlı olmayan bir Sınıfım vardı. Ben proje> Mevcut öğeyi ekle sağ tıklayın ve el ile eksik olduğunu söyledi sınıfı seçmek zorunda kaldı. Sonra her şey iyi çalıştı!

Benim durumumda sorun, ad alanını başka bir projede olduğu gibi tam olarak aynı şekilde değiştirdikten sonra (kasıtlı olarak), derleme adının VS tarafından da değiştirilmiş olmasıydı, bu yüzden biri aynı adı taşıyan iki derleme vardı, biri diğerini geçersiz kıldı

Benim durumumda, harici bağımlılık (xsd2code) tarafından oluşturulan bir dosya vardı ve bir şekilde onun tasarımcı.cs dosyaları doğru VS tarafından işlenmedi. Visual Studio'da yeni bir dosya oluşturmak ve kodu yapıştırmak benim için hile yaptı.

Web sitelerini Azure'da yayınlamaya çalışırken bu hatayı alan herkese, yukarıdaki umut verici görünümlü çözümlerin hiçbiri bana yardımcı olmadı. Aynı gemideydim - çözümüm kendi başına iyi inşa edilmişti. Zorunda kaldım

1. Çözümümdeki tüm nuget paketlerini kaldır.
2. Çözümümü kapat ve yeniden aç.
3. Tüm nuget paketlerini yeniden ekleyin.

Biraz acı verici ama web sitemi Azure'da yayınlamamın tek yolu buydu.

Yerel makinemde çalışan bir Visual Studio Team Services derlemesi ile bir derleme yapmaya çalışırken bu hatayı aldım.

Benim normal çalışma alanında gayet iyi çalıştı ve yerel olarak ajan klasöründe SLN dosyasını açmayı başardı ve her şey tamam derlendi.

Söz konusu DLL, proje Lib/MyDLL.DLLiçinde ve bununla referanslar olarak csproj dosyasında saklandı:

<Reference Include="MYDLL, Version=2009.0.0.0, Culture=neutral, PublicKeyToken=b734e31dca085caa">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>Lib\MYDLL.dll</HintPath>
</Reference>

Sonuçta sadece ipucu yoluna rağmen dosyayı bulamadığı ortaya çıktı. Belki msbuild proje dosyası yerine SLN dosyasına göre bakıyordu düşünüyorum.

Her durumda, aldığınız ileti Could not resolve this reference. Could not locate the assemblyDLL sonra msbuild erişilebilir bir konumda olduğundan emin olun.

Ben tür hile ve Considered "Reference\bin\xxx.dll"dlls orada yerine kopyaladı dedi ve sadece bir mesaj bulundu .

Benim durumumda, referans olarak dll eklemek type or namespace name could not be foundhata verdi . Ancak, dll dosyasını doğrudan bin klasörüne kopyalayıp yapıştırmak hatayı çözdü.

Bunun neden işe yaradığı hakkında bir fikrim yok.

Bu iş parçasının eski olduğunu biliyorum ama yine de paylaşıyorum, ithal derlemenin tüm üçüncü bölüm bağımlılıklarını yüklemeliyim - ithal derleme Nuget paketi olarak dahil edilmediğinden bağımlılıkları eksikti.

Bu yardımı atla :)

Benim durumumda, bir çözümde iki projem vardı, başvurulan projeye bir alt ad alanı ekledim, ancak oluştururken, referans alınan proje derlemesinin başarısız olduğunu fark etmedi ve bu yeni ad alanı var, bu yüzden hata doğru değildi, bulunamadı çünkü mevcut değildi Çözüm açıkça başvurulan projedeki hataları düzeltmek oldu.

VS 2017 topluluk sürümü üzerinde çalışıyordum ve CefSharp nuget paketleriyle de aynı sorunu yaşadım.

Paketler başarıyla indirildi ve geri yüklendi, proje başarıyla oluşturulabilir ve çalıştırılabilir - yalnızca biçimlendirme, ad alanlarının tanınmadığını gösterdi.

Tek yapmam gereken Referencesbölümü açmak ve sarı ünlem işaretlerinden birine tıklamaktı.

Birkaç saniye sonra biçimlendirme hataları ortadan kalktı.