web-dev-qa-db-ja.com

エラーCS0433「タイプ 'X'はA.dllとB.dllの両方に既に存在します」はどこから来ますか？

内部Webサーバー（IISではなく）を使用してVisual Studio 2008 SP1からwebappを実行すると、上記のエラーが表示されます。

完全なエラー（ソースファイルDefault.aspx.cs）：

コンパイラエラーメッセージ：CS0433：タイプ 'WebApplication3.Site1'は、 'c：\ Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\aa563bcf\59deedc0\App_Web_site1.master.cdcab7d2の両方に存在しますmuczzy9v.dll 'および' c：\ Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\aa563bcf\59deedc0\Assembly\dl3\44c3a3cf\80dd34ed_6968ca01\WebApplication3.DLL '

前述の完全な警告：

警告：CS0436： 'c：\ Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\aa563bcf\59deedc0\App_Web_default.aspx.cdcab7d2._tlkwdos.0のタイプ' WebApplication3._Default ' csは、「c：\ Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\aa563bcf\59deedc0\Assembly\dl3\44c3a3cf\e096e61c_6568ca01\WebApplication3のインポートされたタイプ「WebApplication3._Default」と競合します.DLL '。 「c：\ Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\aa563bcf\59deedc0\App_Web_default.aspx.cdcab7d2._tlkwdos.0.cs」で定義されているタイプを使用します。

警告のソースは中間ファイルを指します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;

そして私の質問：これはどこから来たのですか？

Webapp（Webサイトではありません！）には、1つDefault.aspxと1つSite1.Master、依存関係なし。それらはほとんど空で、asp:Labelページ。以前は、このwebappは正常に機能していました。 Default.aspx.csからマスターへの参照を削除すると、すべてうまくいきます。マスターにはいくつかのコードのみがあります。

これは、実際には多くの小さなWebアプリケーションの1つであり、あまり気にすることはできませんでした。しかし、私はこれを前に見たことがありませんでしたし、今、私は何をすべきか興味があります、それ以外はコードを新しいプロジェクトにコピーします（クリーニングソリューションは役に立たない）。

注：私は この投稿 を読みましたが、他のいくつかは適用されません。

c#asp.netmaster-pages
75
Abel

理論

この問題がアプリケーションのバグ（たとえば、クラス名の重複）によってnotである場合：

この問題は、アプリケーションのプロジェクトに変更が加えられ、新しいビルドが発生した後に発生するようです（例：コード/参照/リソースの変更）。問題はこの新しいビルドの出力内にあるように見えます：さまざまな理由で、Visual Studioはアプリケーションのobj/binフォルダーのentireコンテンツを置き換えません。これにより、アプリケーションのbinフォルダーのコンテンツの少なくとも一部が古くなっています。

上記の問題が発生した場合、「Temporary ASP.NET Files」フォルダをクリアするだけでは問題は解決しません。アプリケーションのbinフォルダーの古いコンテンツが次回アプリケーションにアクセスしたときに「Temporary ASP.NET Files」フォルダーにコピーされ、問題が解決しないため、問題を解決できません。重要なのは、既存のファイルをすべて削除し、Visual Studioですべてのオブジェクトを再構築することです。そのため、次回アプリケーションにアクセスすると、新しいbinファイルが「Temporary ASP.NET Files」フォルダーにコピーされます。

ソリューション

  1. Visual Studioを閉じます
  2. Iisresetを実行する
  3. 「Temporary ASP.NET Files」フォルダー内のすべてのフォルダーとファイルを削除します（パスはエラーメッセージで参照されます）
  4. 問題のあるアプリケーションの「obj」および「bin」フォルダーを削除します
  5. Visual Studioを再起動し、ソリューションを開きます
  6. 「クリーンソリューション」に続いて「リビルドソリューション」を実行します

説明

  • 手順1-2：削除する必要があるフォルダー/ファイルからリソースロックを削除します。
  • ステップ3-4：古いビルドファイルをすべて削除します
  • ステップ5〜6：ビルドファイルの新しいバージョンを作成する
109
2Toad

W3svcをシャットダウンし、c:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\からすべてを削除します

追加

  • windows 7で

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

  • on IISサーバー（64ビット）これも発生する可能性があります。探す：

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

    （サーバーで新しい場合は、使用しているフレームワークのバージョンでv4.0.30319を置き換えます）

39
Alex Polkhovsky

これは、.csファイルをApp_Codeに配置し、ビルドアクションをWebアプリケーションプロジェクトでコンパイルするように変更した場合に発生する可能性があります。

コンテンツとしてApp_Codeの.csファイルのビルドアクションを使用するか、App_Codeの名前を別の名前に変更します。 intellisenseはコンテンツとしてマークされた.csファイルを修正しないため、名前を変更しました。

詳細は http://vishaljoshi.blogspot.se/2009/07/appcode-folder-doesnt-work-with-web.html

10
Lilja

すべてのaspxページとマスターページのInheritsタグを見てください。同じ名前の部分クラスが2つある可能性があります。 1つを変更して再コンパイルします。

詳細は次のとおりです。

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

9
NitroxDM

App_Codeフォルダーからクラスファイルを削除し、Webサイトの下に直接配置すると、この問題は解決しました。

4
Naveen Q

これは、ASPXファイルにTagPrefixが重複している場合にも発生する可能性があります。

これにより、このエラーが発生します...

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

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

これを修正するには、2番目の「uc1」を「uc2」に変更するだけです。

一定...

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

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

これらすべての提案の後、私はまだ問題を抱えていました。 App_Code内の一部のクラスは、2つのDLLにコンパイルされていました。このようなもの（簡略化）：

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」フォルダーの名前を「Code」に変更しました。これはMVC5プロジェクトであるため、Webプロジェクトのルート内で.csファイルを提供することに問題はないはずです。

3
tggm

参照： https://support.Microsoft.com/en-in/help/2028526/building-an-asp-net-project-in-visual-studio-results-in-compiler-error

Visual Studioを使用してASP.NETプロジェクトをビルドすると、次のようなエラーメッセージがランダムに表示される場合があります。

コンパイラエラーメッセージ：CS0433： 'ASP.summary_common_controls_notes_ascx'タイプは 'c：\ Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files\Book_Details\abc12345\def8910\App_Web_msftx123.dll'と ' c：\ Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files\Book_Details\abc12345\def8910\App_Web_msfty456.dll '

説明：この要求を処理するために必要なリソースのコンパイル中にエラーが発生しました。次の特定のエラーの詳細を確認し、ソースコードを適切に変更してください。

ソースエラー：行100：行101：
新しいメモ行102：
103行目：
1450行104：

概要。

ソースファイル：d：\ http\post\publisher\default.aspx行：102

このエラーが発生する一般的なシナリオについては、以下で説明します

シナリオ1

説明：一般的な原因は、2つのクラス定義を含む同じWebアプリケーションbinフォルダーに2つのアセンブリがあり、それらのクラス名が同じである場合です。これは、複数のDefault.aspxが単一のアセンブリにコンパイルされた場合に発生する可能性があります。通常、これは、マスターページ（Default.master）とデフォルトASPXページ（Default.aspx）の両方が_Defaultクラスを宣言するときに発生します。解決策：マスターページのクラス名を変更し（ほとんどの場合_Defaultから）、プロジェクトを再ビルドします。クラス間の名前の競合を解決することが重要です。

シナリオ2

説明：Visual Studioの参照パスを使用して、プロジェクトで使用されるアセンブリ参照のフォルダーパスを指定します。パスに同じクラス名を含むアセンブリが含まれている可能性があります。同じアセンブリ（バージョンまたは名前が異なる可能性があります）に複数の参照が追加され、名前の競合が発生している可能性があります。
解決策：古いバージョンの参照を削除します。これを行うには、Visual StudioでWebサイトを右クリックし、プロパティの「参照」を確認します。

シナリオ3

説明：デフォルトでは、ASP.NET Webアプリケーションがコンパイルされると、コンパイルされたコードはTemporary ASP.NET Filesフォルダーに配置されます。既定では、アクセス許可はASP.NETローカルユーザーアカウントに与えられます。これは、コンパイルされたコードにアクセスするために必要な信頼性の高いアクセス許可を持っています。バージョン管理の競合の原因となるデフォルトの許可に変更があった可能性があります。別の可能性としては、ウイルス対策ソフトウェアが誤ってアセンブリをロックしている可能性があります。解決策：すべてのコンテンツの一時ASP.NETファイルフォルダーをクリアします。

シナリオ4

説明：web.configのバッチ属性がTrueに設定されている場合、初めてファイルにアクセスするときに必要なコンパイルに起因する遅延がなくなります。 ASP.NETは、コンパイルされていないすべてのファイルをバッチモードでプリコンパイルします。これにより、ファイルが初めてコンパイルされるときに遅延が発生します。バッチコンパイルを無効にすると、アプリケーションに存在する可能性があるが報告されないマスクされたコンパイルエラーが公開される場合があります。ただし、この問題にとってより重要なことは、個々の.aspx/.ascxファイルを単一のアセンブリではなく個別のアセンブリに動的にコンパイルするようにASP.NETに指示します。解決策：web.configのセクションでbatch = falseを設定します。コンパイルセクションでbatch = falseを設定すると、Visual Studioのアプリケーションのビルド時間に大きなパフォーマンスの影響があるため、これは一時的なソリューションと見なす必要があります。

シナリオ5

説明：ASP.NETアプリケーションのweb.configファイルを変更するか、binフォルダー内のファイルを変更（追加、削除、名前変更など）すると、AppDomainが再起動します。これが発生すると、すべてのセッション状態が失われ、Webサイトの再起動時にキャッシュされたアイテムがキャッシュから削除されます。この問題は、Webアプリケーションの一貫性のない状態が原因である可能性があります。解決策：web.configファイルをタッチ（編集）して、AppDomainの再起動をトリガーします。

シナリオ6

説明：ソースコードをApp_Codeフォルダーに保存すると、実行時に自動的にコンパイルされます。結果のアセンブリは、Webアプリケーションの他のコードからアクセスできます。したがって、App_CodeフォルダーはBinフォルダーとほとんど同じように機能しますが、コンパイルされたコードの代わりにソースコードを格納できる点が異なります。ソースファイルに変更があった場合、クラスは再コンパイルされます。古いアセンブリに起因する競合がある場合は、再コンパイルを強制すると問題が解決する場合があります。解決策：BinまたはApp_Codeフォルダー内のファイルをタッチして、完全な再コンパイルをトリガーします。

3
Sandeep Kumar Narware

私は別の理由を見つけました：ツールボックスのアイコンとプロジェクトの参照に使用される異なるバージョン。何らかの形式でオブジェクトを挿入した後、エラーが発生しました。

2
Rogério Silva

これは、同じクラス名が複数の.aspx.csファイル、つまり、2つのページが異なるファイル名で作成されたが、誤って同じクラス名を持つ場合。

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

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

Webアプリケーションの構築中に警告が表示されますが、アプリケーションは実行されますが、アプリケーションの公開後は動作せず、OPの質問に記載されているように例外がスローされます。

2つのクラス名が重複しないことを確認すると、問題が解決します。

2
Deepak

これは、Web.Configのエラーのために私に起こりました

<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は3.0.0.0ではなく1.0.0.0を指していました（MVC 3はこのプロジェクトで使用されています）。

IISはローカルフォルダーで参照を見つけることができなかったため、GACで検索し、2つの異なるバージョンを見つけました。正しい参照を指した後、IISが見つかりましたローカルdllを使用し、GACを検索する代わりにそれを使用しました。

2
mlapaglia

「ソリューションのクリーン」に続いて「ソリューションの再構築」も同様に修正されるようです。

2
Roman

私たちの場合、その理由はIISのサイトの.dllバージョンの違いでした。これらはIIS内で相互に配置され、サブドメインを介して他のユーザーにアクセスできます。最初のweb.configを継承し、それを次のweb.configと組み合わせて、mvc.dllの異なるバージョンを使用して失敗しました。

0
Christian Haaland

少なくとも私にとっては、アセンブリへの参照を削除し、別の名前の新しいバージョンへの参照を追加したときに発生しました。この場合、古いアセンブリはbinおよびobjフォルダーに残り、Visual Studioからのクリーンソリューション操作では削除されなかったようです（おそらくもうプロジェクトの一部です）。この場合、エラーが発生したプロジェクトのbinおよびobjフォルダーの内容をWindowsエクスプローラー（またはファイル管理ツール）から削除するだけで十分でした。次に、Visual Studioからソリューションをクリーンアップして再構築します。

0
Guillermo Gutiérrez

同じクラス名を持つ2つのascxコントロールで同じ問題が発生しました。

Control1：<％@ Control Language = "C＃" ClassName = "myClassName" AutoEventWireup = "true ...> Control2：<％@ Control Language =" C＃ "ClassName =" myClassName "AutoEventWireup =" true ...>

クラス名を単に変更することで修正しました：

Control1：<％@ Control Language = "C＃" ClassName = "myClassName1" AutoEventWireup = "true ...> Control2：<％@ Control Language =" C＃ "ClassName =" myClassName2 "AutoEventWireup =" true ...>

0
kunalbabre

ソリューションを閉じて再度開き、プロジェクトの参照でdoubling upを確認します。

enter image description here

これはNuGetを使用でDLLの参照場所を変更した場合に発生する可能性があります。修正するには、projファイルを手動で編集してエントリを削除する必要があります。例：

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

これらの「<Import」参照は、projファイルのさまざまな場所に表示される可能性があるので注意してください。

0
Jeremy Thompson

古いasp.net（v 1または2）Webサイトを.net 4.5でWebアプリケーションとして実行するように変換しています。

私の解決策は、問題を引き起こしていたユーザーコントロールイベントハンドラーデリゲートを別の物理ファイルに移動することでした。

//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)
    {
0
marcel_g

これには多くの理由があります。また、上記のほとんどはさまざまなシナリオに適用されます。私が指摘したのは、認証が「なし」以外に設定されている場合にのみエラーが発生することです。私のテスト目的のために、私はこれをオフに設定し、動作します。

0
Chagbert

同様の問題がありました。これは私の解決策です：[Build Action]フォルダーは2つのアセンブリでコンパイルされた同じクラスを持つ別のアセンブリとしてコンパイルされるため、[Compile]のようなApp_Code以外のフォルダーにApplication_Codeとして設定されたプロパティApp_Codeを必要とする分離クラスを配置します.

0
ali mahmoodi

CS0433のエラーURLをクリックして最初のGoogleヒットをクリックすると、ここにリダイレクトされました。具体的には、

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...'

それを修正するために私がしたすべてのことを概説する代わりに、私がそれを破ったことを教えてください。コードの更新が必要なリポジトリのNuGetパッケージを更新しました。パッケージはかなり古く（1年ほど）、私が最初にやろうとしたのは、C＃プロジェクト用に更新することだけでした。

そのプロセスを開始してからこのエラーが発生するまでの間に、SLNのC++プロジェクトのバージョンを何らかの方法で15063にダウングレードしました。また、C＃プロジェクトのTargetPlatformMinVersionとTargetPlatformVersionの両方が10.0.17134.0に新たに設定されていることにも気付きました。

「修正」するために私がしなければならなかったのは、C＃プロジェクトのTargetPlatformMinVersionをTargetPlatformMinVersionよりも高いバージョンに変更することだけでした。 C++プロジェクトをいずれかのバージョンに変更しても、動作は変わりませんでした。これが突然機能しなくなった理由はわかりませんが、同様にブロックされた誰かが同様の戦略を使用してピクルスから抜け出すことを願っています。

0
kayleeFrye_onDeck

最終的に、ページマークアップでのMasterTypeの参照方法を変更しました。

私が変更され： <%@ MasterType VirtualPath="~/x/y/MyMaster.Master" %>から<%@ MasterType TypeName="FullyQualifiedNamespace.MyMaster" %>

詳細については、 here を参照してください。

これが誰かの助けになることを願っています。

0
Chris

2Toadの答えを試すことに加えて、Visual Studioを閉じて.vsフォルダーを削除する必要がありました。その後、すべてが正しく構築されました。

ちなみに、私が遭遇したエラーは、Tempフォルダーをまったく指定しませんでしたが、明らかにシステムによって生成された他の何かを参照していました。特定のエラーを保存するのを怠りました：\

0
Nate

非常に迅速で便利な修正は、一時的にクラスをどこかで参照することにより、Visual Studioの信じられないほどのインテリセンスを悪用することです。

例：

System.Runtime.CompilerServices.ExtensionAttribute x = null;

カーソルをライン上に構築またはホバーすると、次のエラーが表示される場合があります。

「System.Runtime.CompilerServices.ExtensionAttribute」は「C：\ Program Files\Reference Assemblies\Microsoft\Framework\v3.5\System.Core.dll」の両方に存在します

これにより、競合の原因となっている2つのソースがすぐにわかります。

System.Core.dllは保持する.dllファイルなので、もう1つを削除します。

私はbinディレクトリに座っているのを見つけましたが、プロジェクトの他の場所にある可能性があります。

binディレクトリはTFS変更セットの一部として含まれていない可能性があるため、実際に変更をチェックインしても問題が解決しない理由を説明できるため、これは留意する価値があります。チームの他のメンバー。

0
Knickerless-Noggins