CS0433 "Type 'X' hem A.dll hem de B.dll'de zaten var" hatası nereden geliyor?

Dahili web sunucusunu (IIS değil) kullanarak Visual Studio 2008 SP1'den bir web uygulaması çalıştırdığımda, yukarıda belirtilen hatayı alıyorum.

Tam hata (kaynak dosyası Default.aspx.cs ):

Derleyici Hata İletisi: CS0433: 'WebApplication3.Site1' türü hem 'c: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Temporary ASP.NET Files \ root \ aa563bcf \ 59deedc0 \ App_Web_site1.cdcab7d2'de mevcuttur. muczzy9v.dll 've' c: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Temporary ASP.NET Files \ root \ aa563bcf \ 59deedc0 \ assembly \ dl3 \ 44c3a3cf \ 80dd34ed_6968ca01 \ WebApplication3.DLL '

Önceki tam uyarı:

Uyarı: CS0436: 'c: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Temporary ASP.NET Files \ root \ aa563bcf \ 59deedc0 \ App_Web_default.aspx.cdcab7d2._tlkwdos.0'da' WebApplication3._Default 'türü. cs 'c: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Temporary ASP.NET Files \ root \ aa563bcf \ 59deedc0 \ assembly \ dl3 \ 44c3a3cf \ e096e61c_6568ca01 \ WebApplication3 içindeki içe aktarılan' WebApplication3._Default 'türüyle çakışıyor .DLL '. 'C: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Temporary ASP.NET Files \ root \ aa563bcf \ 59deedc0 \ App_Web_default.aspx.cdcab7d2._tlkwdos.0.cs' içinde tanımlanan türü kullanarak.

Bir ara dosyaya işaret eden uyarı kaynağı App_Web_default.aspx.cdcab7d2._tlkwdos.0.cs :

Line 162:    
Line 163:    [System.Runtime.CompilerServices.CompilerGlobalScopeAttribute()]
Line 164:    public class default_aspx : global::WebApplication3._Default, System.Web.IHttpHandler {
Line 165:        
Line 166:        private static bool @__initialized;

ve sorum: bu nereden geliyor?

Web uygulamasında (web sitesi değil!) Bir Default.aspx ve bir Site1.Master vardır , bağımlılık yoktur. asp:LabelSayfada bir ile neredeyse boşlar . Daha önce bu web uygulaması iyi çalışıyordu. Default.aspx.cs'deki herhangi bir referansı ana dosyaya kaldırdığımda, her şey yolunda gidiyor. Usta yalnızca bazı kodlara sahiptir.

Aslında bu, birçok küçük ateş ve unut test web uygulamasından biridir, bu yüzden umrumda değil. Ama bunu daha önce görmemiştim ve şimdi ne yapacağımı merak ediyorum, sonra kodu yeni bir projeye kopyalamak (temizleme çözümü yardımcı olmuyor).

Not: Okuduğum ettik bu yazı ve bazı diğerleri, bunlar geçerli değildir.

Teori

Bu sorun olduğunda değil uygulama (örn yinelenen sınıf adı) bir hata nedeniyle:

Bu sorun, uygulamanın projesinde yeni bir yapıya (örneğin, kod / başvuru / kaynak değişikliği) neden olan bir değişiklik yapıldıktan sonra ortaya çıkıyor gibi görünüyor. Sorun, bu yeni yapının çıktısında yatıyor gibi görünüyor: Çeşitli nedenlerle Visual Studio, uygulamanızın obj / bin klasörlerinin tüm içeriğini değiştirmiyor . Bu, uygulamanızın bin klasörünün içeriğinin en azından bir kısmının güncel olmamasıyla sonuçlanır.

Söz konusu sorun oluştuğunda, "Temporary ASP.NET Files" klasörünün temizlenmesi tek başına sorunu çözmez. Uygulamanızın bin klasörünün eski içeriği, uygulamanıza bir sonraki erişiminizde "Temporary ASP.NET Files" klasörüne geri kopyalanarak sorunun devam etmesine neden olduğundan sorunu çözemez. Önemli olan, var olan tüm dosyaları kaldırmak ve Visual Studio'yu her nesneyi yeniden oluşturmaya zorlamaktır, böylece uygulamanıza bir sonraki erişildiğinde yeni bin dosyaları "Geçici ASP.NET Dosyaları" klasörüne kopyalanacaktır.

Çözüm

1. Visual Studio'yu kapatın
2. İisreset gerçekleştirin
3. "Temporary ASP.NET Files" klasöründeki tüm klasörleri ve dosyaları silin (yol, hata mesajında ​​belirtilir)
4. Sorun teşkil eden uygulamanın "obj" ve "bin" klasörlerini silin
5. Visual Studio'yu yeniden başlatın ve çözümü açın
6. Bir "Temiz Çözüm" ve ardından bir "Yeniden Oluşturma Çözümü" gerçekleştirin

Açıklama

• Adım 1-2: Silmemiz gereken klasörlerden / dosyalardan kaynak kilitlerini kaldırın.
• Adım 3-4: Tüm eski yapı dosyalarını kaldırın
• Adım 5-6: Derleme dosyalarının yeni sürümlerini oluşturun

W3svc'yi kapatın ve her şeyi silin c:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\

katma

• Windows 7'de

  c:\Users\{username}\AppData\Local\Temp\Temporary ASP.NET Files\root\

• üzerinde IIS sunucuları (64 bit) bu da oluşabilir. Aramak:

  C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root

  (sunucunuzda daha yeniyse, v4.0.30319'u kullandığınız çerçeve sürümüyle değiştirin)

Bu, .cs dosyalarını App_Code'a yerleştirirseniz ve derleme eylemini bir Web Uygulaması Projesi'nde derlemek için değiştirirseniz gerçekleşebilir.

İçerik olarak App_Code'daki .cs dosyaları için derleme eylemine sahip olun veya App_Code adını başka bir şeye değiştirin. Intellisense, içerik olarak işaretlenen .cs dosyalarını düzeltmeyeceği için adını değiştirdim.

Daha fazla bilgi http://vishaljoshi.blogspot.se/2009/07/appcode-folder-doesnt-work-with-web.html adresinde

Tüm aspx sayfalarınızın ve ana sayfalarınızın Devralma etiketine bakın. Muhtemelen aynı ada sahip iki kısmi sınıf vardır. Birini değiştirin ve yeniden derleyin.

İşte biraz daha bilgi:

http://blogs.msdn.com/b/carloc/archive/2007/06/12/compiler-error-message-cs0433-in-asp-net-2-0.aspx

Tüm bu önerilerden sonra hala sorun yaşadım. App_Code içindeki bazı sınıflar iki DLL'ye derleniyordu. Bunun gibi bir şey (basitleştirilmiş):

warning CS0436: The type 'HcmDbGeographyModelBinder' in 

'<user_profile_dir>\AppData\Local\Temp\Temporary ASP.NET Files\temp\3b1ed8ee\11405e8e\App_Code.oqr0kusq.0.cs' 

conflicts with the imported type 'HcmDbGeographyModelBinder' in 

'<user_profile_dir>\AppData\Local\Temp\Temporary ASP.NET Files\temp\3b1ed8ee\11405e8e\assembly\dl3\ea0aa3ee\6022e6d5_2cc8cf01\HCM.Web.Backoffice.DLL'.

"App_Code" klasörünü "Kod" olarak yeniden adlandırdım. Bu bir MVC5 projesidir, dolayısıyla .cs dosyalarının web projesinin kökü içinde sunulmasında bir sorun olmamalıdır.

Sınıf dosyalarını App_Codeklasörden kaldırıp doğrudan web sitesinin altına yerleştirmek bu sorunu benim için çözdü.

Bu, ASPX dosyanızda yinelenen TagPrefix varsa da olabilir.

Bu, bu hataya neden olur ...

<%@ Register Src="Control1.ascx" TagName="Control1" TagPrefix="uc1" %>

<%@ Register Src="Control2.ascx" TagName="Control2" TagPrefix="uc1" %>

Bunu, 2. "uc1" i "uc2" olarak değiştirerek düzeltebilirsiniz.

Sabit...

<%@ Register Src="Control1.ascx" TagName="Control1" TagPrefix="uc1" %>

<%@ Register Src="Control2.ascx" TagName="Control2" TagPrefix="uc2" %>

Referans: https://support.microsoft.com/en-in/help/2028526/building-an-asp-net-project-in-visual-studio-results-in-compiler-error

Visual Studio kullanarak bir ASP.NET projesi oluştururken, rastgele aşağıdakine benzer bir hata iletisi görebilirsiniz:

Derleyici Hata Mesajı: CS0433: 'ASP.summary_common_controls_notes_ascx' türü hem 'c: \ Windows \ Microsoft.NET \ Framework64 \ v2.0.50727 \ Temporary ASP.NET Files \ Book_Details \ abc12345 \ def8910 \ App_Web_msftx123.dll' hem de ' c: \ Windows \ Microsoft.NET \ Framework64 \ v2.0.50727 \ Geçici ASP.NET Dosyaları \ Book_Details \ abc12345 \ def8910 \ App_Web_msfty456.dll '

Açıklama: Bu isteğe hizmet vermek için gereken kaynağın derlenmesi sırasında bir hata oluştu. Lütfen aşağıdaki belirli hata ayrıntılarını inceleyin ve kaynak kodunuzu uygun şekilde değiştirin.

Kaynak Hatası: Satır 100: Satır 101:
Yeni Notlar Satır 102:
Satır 103:
1450 Satır 104:

Özet.

Kaynak Dosya: d: \ http \ post \ publisher \ default.aspx Satır: 102

Bu hatanın ortaya çıkabileceği yaygın senaryolar aşağıda tartışılmıştır.

Senaryo 1

Açıklama: Yaygın bir neden, aynı web uygulaması bin klasöründe iki sınıf tanımı içeren ancak aynı sınıf adına sahip iki derlemenin olmasıdır. Bu, birden fazla Default.aspx tek bir derlemede derlenmişse gerçekleşebilir. Bu genellikle Ana sayfa (Default.master) ve Varsayılan ASPX sayfası (Default.aspx) bir _Default sınıfı bildirdiğinde oluşur. Çözüm: Ana sayfanın sınıf adını değiştirin (çoğu durumda _Default'tan) ve projeyi yeniden oluşturun. Sınıflar arasındaki herhangi bir adlandırma anlaşmazlığını çözmek önemlidir.

Senaryo 2

Açıklama: Visual Studio'daki Referans Yolları, proje tarafından kullanılan montaj referansları için klasör yolunu belirtmek için kullanılır. Yolun aynı sınıf adını içeren bir derleme içermesi olasıdır. Bir adlandırma çakışmasına neden olan aynı derlemeye (muhtemelen farklı sürüm veya ad) eklenmiş birden fazla Referans olabilir.
Çözüm: Eski sürüm referansını kaldırın. Bunu yapmak için, Visual Studio'da web sitenize sağ tıklayın ve özelliklerdeki "Referanslar" ı kontrol edin.

3. Senaryo

Açıklama: Varsayılan olarak, bir ASP.NET Web uygulaması derlendiğinde, derlenen kod Temporary ASP.NET Files klasörüne yerleştirilir. Varsayılan olarak erişim izinleri, derlenmiş koda erişmek için gereken yüksek güven izinlerine sahip olan ASP.NET yerel kullanıcı hesabına verilir. Varsayılan izinlerde sürüm çakışmalarına neden olan bazı değişiklikler olabilir. Diğer bir olasılık, anti-virüs yazılımının bir düzeneği yanlışlıkla kilitliyor olması olabilir. Çözüm: Tüm içeriğin Geçici ASP.NET Dosyaları Klasörünü temizleyin.

Senaryo 4

Açıklama: web.config dosyasındaki batch özniteliği True olarak ayarlandığında, bir dosyaya ilk kez eriştiğinizde gereken derlemenin neden olduğu gecikmeyi ortadan kaldırır. ASP.NET, tüm derlenmemiş dosyaları toplu iş modunda önceden derler ve bu da dosyaların ilk derlenmesinde gecikmelere neden olur. Toplu derlemenin kapatılması, uygulamada var olabilecek ancak rapor edilmeyen maskelenmiş derleme hatalarını ortaya çıkarabilir. Ancak bu sorun için daha da önemlisi, ASP.NET'e tek tek .aspx / .ascx dosyalarını tek bir derleme yerine ayrı derlemelerde dinamik olarak derlemesini söyler. Çözüm: web.config bölümünde batch = false değerini ayarlayın. Derleme bölümünde batch = false ayarının Visual Studio'daki uygulama için derleme süreleri üzerinde önemli bir performans etkisi olduğu için bu geçici bir çözüm olarak düşünülmelidir.

Senaryo 5

Açıklama: Bir ASP.NET uygulaması için web.config dosyasını değiştirmek veya bin klasöründeki bir dosyayı değiştirmek (ekleme, silme veya yeniden adlandırma gibi) AppDomain'in yeniden başlatılmasına neden olur. Bu gerçekleştiğinde tüm oturum durumu kaybolur ve web sitesi yeniden başlatılırken önbelleğe alınan öğeler önbellekten kaldırılır. Sorunun web uygulamasındaki tutarsız bir durumdan kaynaklanması mümkündür. Çözüm: web.config dosyasına dokunarak (düzenleyerek) bir AppDomain yeniden başlatmayı tetikleyin.

6. Senaryo

Açıklama: Kaynak kodunu App_Code klasöründe saklayabilirsiniz ve çalışma zamanında otomatik olarak derlenecektir. Ortaya çıkan derlemeye Web uygulamasındaki herhangi bir başka kod tarafından erişilebilir. Bu nedenle App_Code klasörü, derlenmiş kod yerine kaynak kodunu saklayabilmeniz dışında Bin klasörüne çok benzer şekilde çalışır. Kaynak dosyada bir değişiklik olduğunda sınıf yeniden derlenecektir. Güncel olmayan bir derlemeden kaynaklanan bir çakışma varsa, yeniden derlemeye zorlamak sorunu çözebilir. Çözüm: Tam bir yeniden derlemeyi tetiklemek için Bin veya App_Code klasörlerindeki bir dosyaya dokunun.

Bu, Web.Config konsolumdaki bir hata nedeniyle başıma geldi

<add assembly="System.Web.Abstractions, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
<add assembly="System.Web.Helpers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
<add assembly="System.Web.Routing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
<add assembly="System.Web.Mvc, Version=5.1.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
<add assembly="System.Web.WebPages, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>

Sytem.Web.Helpers(MVC 3 Bu projede kullanılan) 1.0.0.0 yerine 3.0.0.0 işaret edilmiştir.

IIS referansı yerel klasörde bulamadığından GAC'ye baktı ve iki farklı sürüm buldu. IIS, doğru referansa işaret ettikten sonra yerel dll'yi buldu ve GAC'de arama yapmak yerine onu kullandı.

Bu, aynı sınıf adı birden fazla .aspx.csdosyada belirtildiğinde , yani iki sayfa farklı dosya adıyla oluşturulduğunda ancak yanlışlıkla aynı sınıf adına sahip olduğunda meydana gelebilir .

// file a.aspx
public partial class Test1: System.Web.UI.Page

// file b.aspx
public partial class Test1: System.Web.UI.Page

Web uygulamasını oluştururken bu bir uyarı verir, ancak uygulama çalışır, ancak uygulama yayınlandıktan sonra artık çalışmaz ve OP'nin sorusunda belirtildiği gibi istisnayı atar.

İki sınıf adının çakışmadığından emin olmak sorunu çözer.

Başka bir neden buldum: araç kutusundaki simgeler ve projedeki referanslar için kullanılan farklı sürümler. Nesneleri bir biçimde ekledikten sonra hata başladı.

"Temiz Çözüm" ve ardından "Çözümü Yeniden Oluştur" da sorunu çözüyor gibi görünüyor.

Sayfa işaretlemesinde MasterType'a nasıl başvurulduğunu değiştirdim.

Ben değiştim: <%@ MasterType VirtualPath="~/x/y/MyMaster.Master" %> olarak<%@ MasterType TypeName="FullyQualifiedNamespace.MyMaster" %>

Ayrıntılar için buraya bakın.

Umarım bu birine yardım eder.

En azından benim için bu, bir derlemeye yönelik bir referansı kaldırdığımda ve onun farklı bir ada sahip olan daha yeni bir sürümüne bir referans eklediğimde oldu. Bu durumda, eski derleme bin ve obj klasöründe kalmış ve Visual Studio'dan temiz çözüm işlemi ile kaldırılmamış gibi görünüyor (belki de artık projenin bir parçası olmadığı için). Bu durumda, hatanın meydana geldiği projenin bin ve obj klasörlerinin içeriğini Windows Gezgini'nden (veya bir dosya yönetimi aracından) silmek yeterliydi . Ardından, Visual Studio'dan çözümü temizleyin ve yeniden oluşturun.

Bizim durumumuzda bunun nedeni, IIS'deki sitelerin .dll sürümlerindeki farklılıktı. IIS'de birbirlerinin altına yerleştirilirler ve diğerine bir alt alan üzerinden erişmenize izin verir. İlk web.config'den devralır ve bunu sonraki web.config ile birleştirerek, mvc.dll'nin farklı sürümlerine sahip olarak başarısız oldu.

Ben de benzer bir sorun yaşadım. Benim çözüm: özelliği gerektiren izole sınıfları koyun [Build Action]olarak grubu [Compile]dışında bir klasöre App_Codegibi Application_Codeyana App_Codeklasör 2 düzeneklerde derlenen aynı sınıf olan, ayrı bir ünite olarak derlenmiş olacaktır.

Aynı sınıf adına sahip iki ascx kontrolüyle aynı sorunu yaşadım:

Control1: <% @ Control Language = "C #" ClassName = " myClassName " AutoEventWireup = "true ...> Control2: <% @ Control Language =" C # "ClassName =" myClassName "AutoEventWireup =" true ...>

Sınıf adını yeniden adlandırarak düzelttim:

Control1: <% @ Control Language = "C #" ClassName = " myClassName1 " AutoEventWireup = "true ...> Control2: <% @ Control Language =" C # "ClassName =" myClassName2 "AutoEventWireup =" true ...>

Çözümü kapatın ve yeniden açın, ardından ikiye katlamak için proje referanslarını kontrol edin :

NuGet kullanıyorsanız ve DLL başvuru konumunu değiştirdiyseniz bu durum oluşabilir . Düzeltmek için proj dosyasını girişleri kaldırarak manuel olarak düzenlemeniz gerekir, örneğin:

  <Import Project="..\packages\CefSharp.WinForms.53.0.0\build\CefSharp.WinForms.targets" Condition="Exists('..\packages\CefSharp.WinForms.53.0.0\build\CefSharp.WinForms.targets')" />

Bu "<İçe Aktarma" referansları proje dosyasında farklı noktalarda görünebileceğinden dikkatli olun.

Çok hızlı ve kullanışlı bir çözüm, geçici olarak bir yerde sınıfa atıfta bulunarak Visual Studio'nun inanılmaz zekasını kötüye kullanmaktır.

Misal:

System.Runtime.CompilerServices.ExtensionAttribute x = null;

İmleci satırın üzerinde oluştururken veya fareyle gezdirirken aşağıdaki hatayı görebilirsiniz:

'System.Runtime.CompilerServices.ExtensionAttribute' her iki 'C: \ Program Files \ Reference Assemblies \ Microsoft \ Framework \ v3.5 \ System.Core.dll' içinde mevcuttur

Bu size hemen çatışmaya neden olan iki kaynağı söyler.

System.Core.dll saklamak istediğiniz .dll dosyasıdır, bu nedenle diğerini silin.

Benimkini bindizinde buldum , ancak projenin başka bir yerinde olabilir.

Aslında bu akılda bintutulmaya değerdir, çünkü dizin TFS değişiklik kümesinin bir parçası olarak dahil edilmeyebileceğinden, değişikliklerinizi kontrol etmenin neden ekibinizin diğer üyeleri için sorunu çözmediğini açıklayabilir.

Eski bir asp.net (v 1 veya 2) web sitesini .net 4.5 altında çalışacak şekilde web uygulaması olarak dönüştürüyorum.

Çözümüm, soruna neden olan kullanıcı denetimi olay işleyicisi temsilcilerini ayrı bir fiziksel dosyaya taşımaktı:

//move this line to a new physical file:
public delegate void LocationSearchedEventHandler( object sender );

public partial class controls_Drives_LocationAddPanel : UserControl
{
    public event LocationAddedEventHandler LocationAdded;
    protected virtual void OnLocationAdded(LocationAddEventArg e)
    {

Bunun pek çok nedeni var. Ve yukarıda bahsedilenlerin çoğu farklı senaryolar için geçerlidir. Dikkat ettiğim şey, hatanın YALNIZCA kimlik doğrulama 'Hiçbiri' dışında bir şeye ayarlandığında ortaya çıktığıdır. Test amaçlarım için bunu ayarlayacağım ve işe yarıyor.

Ben hata URL'ye tıklandığında yeniden yönlendirilmiş burada ilk olarak Google tıklandığında isabet var CS0433, özellikle

The type 'Package' exists in both 'Windows... Version=N.N.N.N, Culture=neutral, PublicKeyToken=null, ContentType=Windows...' and 'Windows..., Version=255.255.255.255, Culture=neutral, PublicKeyToken=null, ContentType=Windows...'

Düzeltmek için yaptığım her şeyin ana hatlarını çizmek yerine, size onu kıran ne yaptığımı söyleyeyim. Kod güncellemesi gerektiren bir depo için NuGet paketlerini güncellemeye gittim. Paketler oldukça eskiydi (1 yıl kadar) ve başlangıçta yapmaya çalıştığım tek şey bir C # projesi için güncellemekti.

Bu işlemi başlatmakla bu hatayla karşılaşmak arasında bir süre, o SLN'deki C ++ projelerinin sürümünü hedeflemek için bir şekilde düşürdüm 15063. Ben de hem C # projesi olduğunu fark TargetPlatformMinVersionve TargetPlatformVersionyeni ayarlı10.0.17134.0

"Düzeltmek" için yapmam gereken tek şey , C # projesinden TargetPlatformMinVersiondaha yüksek bir sürüme TargetPlatformMinVersiongeçmekti. C ++ projesini herhangi bir sürüme değiştirmek, davranışı değiştirmedi. Bunun neden birdenbire çalışmayı bıraktığından emin değilim ama umarım benzer şekilde engellenen biri benzer stratejiler kullanarak turşudan çıkabilir.

2Toad'un cevabını denemeye ek olarak, Visual Studio'yu kapatmak ve .vs klasörümü silmek zorunda kaldım. Bundan sonra her şey doğru inşa edildi.

Bu arada, karşılaştığım hata Temp klasörümü hiç belirtmiyordu, ancak açıkça sistem tarafından oluşturulmuş başka bir şeye atıfta bulunuyordu. Belirli bir hatayı kaydetmeyi ihmal ettim: \

başka bir çözüm işe yaramadıysa, bu sorunun miras sınıfını yeniden adlandırarak aspx dosyası ve aspx.cs dosyasını yeni bir adla yeniden adlandırın, ardından çözümü yeniden oluşturun. o zaman sorun kesin olarak çözülecektir. bu sadece benim için çalıştı.

Örneğin :

aspx dosyasında aşağıdakileri yapın, devralınan sınıf adını Defaultnew olarak değiştirin

<%@ Page Title="" Language="C#"  MasterPageFile="~/Main.master" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="Defaultnew" %>

aspx.cs dosyasında, sınıfı aspx dosyasında kullanılanla aynı şekilde yeniden adlandırın

using System;
using System.Collections.Generic;
using System.Web;

public partial class Defaultnew : System.Web.UI.Page
{