Ad, XAML'deki ad alanı hatasında mevcut değil

VS2012'yi bir VB.NET WPF uygulaması üzerinde çalışırken kullanma. WPF'yi öğrenmek için kullandığım basit bir MusicPlayer öğretici uygulamam var. Öğreticinin bir C # sürümünü adım adım VB.NET'e dönüştürüyorum.

Uygulamada her ikisi de aynı ad alanı altında olan 2 sınıfı vardır. XAML'deki ad alanına başvurabiliyorum ancak XAML'deki sınıf nesnesine başvurmaya çalıştığımda bir hata alıyorum ve derleme yapamıyorum.

Garip olan şey, IntelliSense'in hem ad alanına xmlns: c = etiketi aracılığıyla başvururken hem de Sınıf nesnesini <c: Ancak kullanarak yazarken iyi çalışmasıdır . Nesnenin altı çizilir ve tasarımcıda oluşturmaya veya çalışmaya çalışırken hatalar üretilir.

.Vb sınıfı dosyaları \ Controls adlı bir klasörde bulunur. Ana proje Kök Ad Alanı kasıtlı olarak boş bırakılmıştır. Sınıf şu şekilde kodlanmıştır ...

Namespace MusicPlayer.Controls
    Public Class UpdatingMediaElement
       .... code here
    End Public
End Namespace

Xaml şuna benzer

( <Window >etikette tanımlı ad alanı

xmlns:c="clr-namespace:MusicPlayer.Controls"

(a'da tanımlanan nesne <Grid>)

  <c:UpdatingMediaElement Name="MyMediaElement" />

(hata görüntülenir) "UpdatingMediaElement" adı, "clr-namespace: MusicPlayer.Controls" ad alanında mevcut değil.

Neyin yanlış olduğundan veya nasıl düzeltileceğinden emin değil misiniz?

Wpf kodunuzu yazarken ve VS'ye "ABCDE adı clr-isim alanında mevcut değil: ABC" deyin. Ancak projenizi tamamen başarılı bir şekilde kurabilirsiniz, sadece küçük bir rahatsızlık vardır çünkü UI tasarımını göremezsiniz (veya sadece kodu temizlemek istersiniz).

Şunları yapmayı deneyin:

• VS'de, Çözüm -> Özellikler -> Yapılandırma Özellikleri'ne sağ tıklayın

• Yeni bir iletişim kutusu açılır, proje yapılandırmalarını Debug'dan Release'e veya tam tersi olarak değiştirmeyi deneyin.

Bundan sonra çözümünüzü yeniden oluşturun. Sorununuzu çözebilir.

Derleme, sınıfınızın bulunduğu ad alanından farklıysa, açıkça belirtmeniz gerekir.

örn: -

xmlns:Local="clr-namespace:MusicPlayer.Controls;assembly=MusicPlayer"

Xaml Design Shadow Cache'i temizleyerek bu sorunun ortadan kalktığını gördüm. Visual Studio 2015 Güncelleştirme 1 ile ilgili sorun yaşadım.

Visual Studio 2015'te, Önbellek burada bulunur:

%localappdata%\Microsoft\VisualStudio\14.0\Designer\ShadowCache

Süreci:

1. Çözüm Gezgini'nde çözüme sağ tıklayın ve "Temiz Çözüm" ü seçin
2. Visual Studio'yu kapatın
3. ShadowCache klasörünü silin
4. Visual Studio projesi yeniden açıldı
5. Çözümü yeniden oluşturun

Ve artık ad alanı hatası yok.

Benim durumumda bunun nedeni diğer derleme hatalarıydı . Diğer hatalar çözüldüğünde, görünüşte ilgili olan bu hata da listeden kaldırıldı. Özellikle hata listesinin altındaki ve son değiştirdiğiniz sayfalardaki hatalar.

Bu yüzden doğrudan bu hataya dikkat etmeyin ve ilk başta diğer hatalara odaklanın .

Derleme hedef platformunu x86 olarak değiştirmeyi ve projeyi oluşturmayı deneyin.

Subversion aracılığıyla, proje derleme Platform hedefini x64 olarak değiştirdiğimi fark ettim. Yaptığım tek değişiklik buydu. Bu değişikliği yaptıktan sonra, kod, yaşadığınız aynı hatayı göstermeye başlamadan önce kısa bir süre çalışıyordu. Test etmek için platform hedefini x86 olarak değiştirdim ve aniden tasarımcım yeniden çalışmaya başladı. Daha sonra x64 olarak değiştirdim ve sorun tamamen ortadan kalktı. Tasarımcının x32'de bir tür önbelleğe alınmış kod oluşturduğundan ve x64 oluşturma platformunun değiştirilmesinin kod değişiklikleri yaptığınızda onu kırdığından şüpheleniyorum.

Dunno eğer bu başkasına yardım edecekse

WPF'de yeniyim ve hala VB.net'te acemiyim - bu yüzden bu hatayı almanın zirvede aptalca yapmamdan kaynaklandığını varsayıyordum ........ farz edelim ki gerçekten! Projemi bir ortak sürücüden yerel sürücülerimden birine taşıyarak ondan kurtulmayı başardım. Hata ortadan kalktı, proje henüz mükemmel bir şekilde başka sorunlara yer vermiyor. Görünüşe göre VS2015, ortak drive'da tutulan projelerle ilgili hâlâ sorunlar yaşıyor.

Belki proje derlendiğinde ancak XAML hatası gösterildiğinde başka bir çözüm:

1. Çözüm araştırmasında, xaml içeren proje düğümünde
2. Projeye sağ tıklayın ve 'Projeyi Kaldır'ı seçin
3. Projeye sağ tıklayın ve 'Projeyi Yeniden Yükle'yi seçin. Projenizin hala "başlangıç ​​projesi" olarak seçildiğinden emin olun. Değilse:
4. Projeye sağ tıklayın ve 'Başlangıç ​​projesi olarak ayarla'yı seçin

Görsel stüdyoyu yeniden inşa etmeye veya kapatmaya gerek yok.

Tanrım ... Bu, beş yıl sonra Visual Studio 2017'de hala bir sorundur. WPF'de yeniyim, sorunun bir şekilde ben olduğumdan emindim, ama hayır, her şey doğru derlendi ve çalıştı.

Yeniden oluşturmayı, temizlemeyi ve yeniden oluşturmayı, x86 / x64 çıktısı arasında geçiş yapmayı, Windows'u yeniden başlatmayı, ShadowCache klasörünü temizlemeyi, XML ad alanı bildirimine "; assembly = {ana derleme adım}" eklemeyi denedim, hiçbir şey işe yaramadı! Yaptığı tek şey:

Statik Komutlar sınıfımı (benim durumumda anlaşma tasarımın WPF Komutlarımı keşfetmesini sağlamaktı) ayrı montajına koyun ve bunun yerine montaj adını onun yerine değiştirin.

Aynı sorunu yaşadım ve benim durumumda Biçimlendirme Tasarım Görünümü benden çözümü yeniden oluşturmamı istedi ve şu mesajla form düzenini göstermedi:, Design view is unavailable for x64 and ARM target platformsveya Build the Project to update Design view.

Çözümü yeniden oluşturarak çözülmez (ne tasarım görünümü ne de "Ad, ad alanında mevcut değil" hatası)

Sanırım bunun nedeni Çözüm -> Özellikler> Yapılandırma Özellikleri ayarlarıyla oynamış olmamdı.

Sonunda sorunu 2 işte çözdüm:

1. Sayfanın Oluşturma Sütunu üzerindeki tüm onay kutularının işaretlenmesi: Çözüm -> Özellikler -> Yapılandırma Özellikleri
2. Gelen çözelti yapılandırmaları değiştirme ayıklama için Release veya tam tersi.

Visual Studio2012 Update 2'de bir hata olduğunu düşünüyorum.

Aynı sorun Visual Studios 2013, Service Pack 4'ü de rahatsız ediyor. Aynı sonuçlarla Visual Studios 2015 Preview ile de denedim.

Bu, Visual Studios ekibinin düzeltmediği WPF görselleştiricisinin yalnızca bir sınırlaması. Bunun kanıtı olarak, x86 modunda oluşturmak görselleştiriciyi etkinleştirir ve x64 modunda oluşturmak onu devre dışı bırakır.

Garip bir şekilde intellisense, Visual Studios 2013, Service Pack 4 için çalışıyor.

Bu sorunu yakın zamanda .NET 4.6.2'deki WPF projem için VS 2015 Update 3 kullanırken yaşadım. Projemin kopyası bir ağ klasöründeydi , onu yerel olarak taşıdım ve bu sorunu çözdü.

Bu, VS 2015'in ağ yollarını sevmediği gibi göründüğü için başka tür sorunları da çözebilir. Onlar için büyük bir sorun olan diğer bir sorun, projem bir ağ yolundaysa, git depolarını senkronize etmektir, bu da yerel olarak taşınarak çözülür.

Görünüşe göre bu problem çeşitli "hilelerle" çözülebilir.

Benim durumumda, sadece çözüm dahilinde üzerinde çalıştığım proje yerine tüm çözümü inşa ediyor / yeniden inşa ediyor / temizliyordum. "[Projemi] oluştur" u tıkladığımda hata mesajı kayboldu.

Montaj referanslarınızı doğrulamayı deneyin. Proje referanslarında sarı bir ünlem işaretiniz varsa, orada bir sorun var ve her türlü hatayı alacaksınız.

Proje referansının doğru olduğunu biliyorsanız, Hedef çerçevesini kontrol edin. Örneğin, 4.5 çerçevesini kullanan bir projeye sahip olmak, 4.5.2 çerçevesine sahip bir projeye sahip olmak iyi bir kombinasyon değildir.

Benim için çözüm, derleme DLL'lerinin engelini kaldırmaktı. Aldığınız hata mesajları bunu göstermez, ancak XAML tasarımcısı "korumalı alanlı" derlemeler olarak adlandırdığı şeyi yüklemeyi reddeder. Bunu oluşturduğunuzda çıktı penceresinde görebilirsiniz. İnternetten indirilen DLL'ler engellenir. Üçüncü taraf derleme DLL'lerinizin engelini kaldırmak için:

1. Windows Gezgini'nde DLL dosyasına sağ tıklayın ve Özellikler'i seçin.
2. Genel sekmesinin altında "Engellemeyi Kaldır" düğmesini veya onay kutusunu tıklayın.

Not: DLL'lerin engellemesini yalnızca güvenli olduklarından eminseniz kaldırın.

Benim durumumda, kullanıcı kontrolü ana projeye eklendi. Yukarıdaki çeşitli çözümleri boşuna denedim. Ya Geçersiz İşaretleme alırdım ama çözüm derleyip çalışır ya da xmlns: c = "clr-namespace: Projem; derleme = Projem" eklerdim ve sonra işaretleme gösterilirdi, ancak bir derleme hatası alırdım. XML ad alanında etiketi mevcut değil.

Son olarak çözüme yeni bir WPF Kullanıcı Kontrol Kitaplığı projesi ekledim ve kullanıcı kontrolümü ana projeden bu projeye taşıdım. Referans eklendi ve montajı yeni kütüphaneye işaret edecek şekilde değiştirildi ve sonunda işaretleme çalıştı ve proje hatasız derlendi.

Tüm cevapları gözden geçirdim ve hiçbiri bana yardımcı olmadı. Sonunda kendi başıma çözebildim, bu yüzden yanıtı başkalarına yardımcı olabileceği gibi sunarak.

Benim durumumda, çözümün iki projesi vardı, biri modelleri içeren (örneğin proje ve montaj adı Modellerdi ) ve diğeri görünümleri ve görünüm modellerini (bizim kuralımıza göre : proje, montaj adı ve varsayılan ad alanı Modellerdi. ) . Models.Monitor, Modeller projesine atıfta bulundu.

Models.Monitor projesinde, xaml'den birinde şu ad alanını ekledim: xmlns: monitor = "clr-namespace: Models.Monitor"

MsBuild ve Visual Studio'nun daha sonra 'Modeller' derlemesinde bir 'Monitör' türü bulmaya çalışırken hata yaptığından şüpheleniyorum . Çözmek için aşağıdakileri denedim:

1. xmlns: monitor = "clr-namespace: Models.Monitor; assembly =" - bu, ad alanı ile aynı derlemede ise geçerlidir https://msdn.microsoft.com/en-us/library/ms747086(v=vs .110) .Aspx
2. ayrıca açık ad alanı bildirimini denedi: xmlns: monitor = "clr-namespace: Models.Monitor; assembly = Models.Monitor"

Yukarıdakilerin hiçbiri işe yaramadı.

Sonunda pes ettim ve bir çalışma sırasında UserControl başka bir ad alanına kullanmaya çalışıyordum: 'ModelsMonitor' . Bundan sonra iyi derleyebildim.

Benim durumumda bir ad alanım vardı ve sınıf tamamen aynı şekilde yazıldığından, örneğin ad alanlarımdan biri

firstDepth.secondDepth.Fubar

kendi sınıflarını içeren (örn. firstDepth.secondDepth.Fubar.someclass)

ama aynı zamanda ad alanında bir ' Fubar ' sınıfım vardı

firstDepth.secondDepth

metin olarak yukarıdaki Fubar ad alanıyla aynı şekilde çözümlenir.

Bunu yapma

Benim durumumda sorun, projenin obj dizini altındaki bazı hayalet dosyalardan kaynaklanıyordu. Aşağıdaki sorun benim için çözüldü:

• Temiz proje
• VS'den çık
• rm -rf / obj / *
• VS'yi çağırın ve yeniden oluşturun

Ben de bununla çok sorun yaşıyorum! Intellisense, ad alanını ve her şeyi tamamlamama yardımcı oluyor, ancak derleyici ağlıyor. Bu ve diğer başlıklarda bulduğum her şeyi denedim. Ancak benim durumumda sonunda yardımcı olan şey şöyle bir şey yazmaktı:

xmlns:util="clr-namespace:LiveSpielTool.Utils;assembly="

Derleme adını boş bırakmak. Neden olduğuna dair hiçbir fikrim yok. Ama burada bahsedildi. Bir montaj geliştirdiğimi eklemeliyim, böylece assembly niteliği mantıklı olabilir. Ancak montaj adını girmek işe yaramadı. Çok garip.

VB.NET, C # 'da olduğu gibi klasör yapısına dayalı olarak Ad alanı bilgisini otomatik olarak eklemez. Sanırım sizinle aynı öğreticiden geçiyorum (24 Saat İçinde WPF'yi Kendinize Öğretin) ve aynı dönüşümü VB'ye yapıyorum.

Kitapta açıklandığı gibi Ad Alanlarını kullanabilmek için Ad Alanı bilgilerini hem XAML Sınıfına hem de XAML.VB koduna manuel olarak eklemeniz gerektiğini fark ettim. O zaman bile, VB, VB'de olduğu gibi, Ad Alanını Montaj'a otomatik olarak atamaz.

Burada, bunu proje şablonlarınıza nasıl dahil edeceğinizi gösteren başka bir makale var, böylece Ad Alanı bilgilerini otomatik olarak oluşturabilir - Yeni öğe eklerken ad alanını otomatik olarak ekleyin

Çözüm özelliği sayfasında, "UpdatingMediaElement" içeren derlemenin platformunu ve "UpdatingMediaElement" alt sınıflarını veya uyguladığı üst sınıfları ve arabirimleri içeren montajları kontrol edin. Görünüşe göre tüm bu derlemelerin platformu "AnyCPU" olmalıdır.

Başka bir olası neden: Bir derleme sonrası olayı, proje DLL'sini yapı klasöründen kaldırıyor.

Netleştirmek için: WPF tasarımcısı bildirebilir "adı XXX ad alanında yok ...", adı ad alanında var mıdır ve proje gayet güzel oluşur ve çalışır bile eğer post-build olay gelen proje DLL kaldırır derleme klasörü (bin \ Debug, bin \ Release, vb.). Bu konuda Visual Studio 2015'te kişisel deneyimim var.

Tamam, maalesef bu ipuçlarından hiçbiri benim için işe yaramadı. Sonunda sorunu çözmeyi başardım. Görünüşe göre Visual Studio ağ sürücüleriyle iyi oynamıyor. Bu sorunu, projeyi ortak drive'dan yerelime taşıyarak çözdüm ve yeniden derledim. Daha fazla hata yok.

Yığına ekleniyor.

Benimki WPF uygulamasının derleme adı başvurulan bir dll ile aynı derleme adıydı. Bu nedenle, projelerinizin hiçbirinde yinelenen montaj adlarına sahip olmadığınızdan emin olun.

Çözümü bir ağ paylaşımında sakladım ve her açtığımda güvenilmeyen kaynaklarla ilgili uyarı alıyordum. Onu yerel bir sürücüye taşıdım ve "ad alanı yok" hatası da ortadan kalktı.

Ayrıca proje-> özelliklerinize sağ tıklamayı deneyin ve Platform hedefini Herhangi bir CPU olarak değiştirip yeniden oluşturun, daha sonra çalışacaktır. Bu benim için çalıştı

Bu soruna, başvurduğunuz montaj aslında inşa edilmemişse de neden olabilir. Örneğin, xaml'iniz Assembly1'deyse ve Assembly1'de de bir sınıfa başvuruyorsanız, ancak bu derlemede hatalar var ve derleme oluşturulmuyorsa, bu hata gösterilecektir.

Bu konuda kendimi aptalca hissediyorum, ama benim durumumda bir kullanıcı kontrolünü parçalıyordum ve sonuç olarak ilgili sınıflarda her türlü hata oluştu. Tüm bunları düzeltmeye çalışırken, söz konusu hatalarla başladım, xaml'ın bu referansları bulmak için yerleşik derlemelere dayandığını fark etmedim (daha siz yapmadan önce bile çalıştırabilen c # / vb kodunun aksine).

Derlemeyi bir proje olarak ekledim - ilk önce özellikle dll referanslarına eklenen ddl'yi sildim - bu yaptı.

Bu sorunu her zaman alıyorum. Görünümlerim bir WPF Özel Kontrol Kitaplığı projesinde (Sınıf Kitaplığı üzerinde bir varyant). Önceden oluşturulmuş derlemelere başvurabilirim, ancak aynı çözümün başka bir projesindeki herhangi bir koda başvuruda bulunamıyorum. Kodu xaml ile aynı projeye taşıdığım anda tanınır.

Benim durumumda, bu sorun wpf programının mimarisi bağımlılıkla tam olarak aynı olmadığında ortaya çıkacaktır. X64 olan bir bağımlılığınız olduğunu ve diğerinin AnyCPU olduğunu varsayalım. Daha sonra x64'ü seçerseniz, AnyCPU dll'deki tür "mevcut değildir", aksi takdirde x64 dll'deki tür "mevcut olmaz". Sadece ikisini de emile edemezsiniz.