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

81

内部Webサーバー（IISではない）を使用してVisual Studio 2008 SP1からWebアプリを実行すると、上記のエラーが発生します。

完全なエラー（ソースファイル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（ウェブサイトではありません！）には、1つのDefault.aspxと1つのSite1.Masterがあり、依存関係はありません。それらはほとんど空でasp:Label、ページにがあります。以前は、このWebアプリは正常に機能していました。Default.aspx.cs内のマスターへの参照を削除すると、すべてうまくいきます。マスターにはいくつかのコードしかありません。

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

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

c#  asp.net  master-pages 
— アベル
ソース
PS：私の主な考えは、何かが一時ディレクトリをねじ込んだことです。ここでの私の主な方法は、単に手動で一時ディレクトリを削除して再構築することです。誰かがここでより深い洞察を持っている場合に備えて、まだ試されていません（「証拠」を削除します）。
— アベル

回答:

120

理論

この問題の原因がアプリケーションのバグ（クラス名の重複など）ではない場合：

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

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

解決

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

説明

  • 手順1〜2：削除する必要のあるフォルダ/ファイルからリソースロックを削除します。
  • 手順3〜4：古いビルドファイルをすべて削除する
  • 手順5〜6：ビルドファイルの新しいバージョンを作成する
— 2ヒキガエル
ソース
3
この投稿は、元の受け入れられた回答を明確に補強します。良い説明と明確な手順、ありがとう！
— アベル
1
@Abelはこれを答えにすることを検討してください。ASP.NETの一時フォルダーをクリーンアップするだけでは役に立たないためです。
— Arin Ghazarian 2016年
2
これは、Web以外のプロジェクトで私に起こりました。binフォルダーとobjフォルダーを削除するだけで修正されました。
— マットH
1
@ArinGhazarian、まさに！このエラーをクリアするには、objとbinフォルダも削除する必要がありました。
— サントッシュ2018
素晴らしい説明と素晴らしい答え。ありがとうございました！
— カルロスロドリゲス
39

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

追加

  • Windows7の場合

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

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

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

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

— アレックスポルホフスキー
ソース
2
ええ、それはおそらくうまくいくでしょう（上記の私自身のコメントを参照してください）が、これがどこから来たのか、そしてそれを防ぐために（あるいはそれを再現可能にするために）何をすべきかについて少し洞察を深めたいと思いました。私はブルートフォースを解決することに反対していませんが、解決する前に、何が起こっているのかを理解したいと思います。
— アベル
これは過去に私に起こりました。デバッグセッションの後、または新しいセッションを開始する前にクリーンアップされないVSの問題だと思います。これが私に最後に起こったのは、数年前のVS2005でした。
— Alex Polkhovsky 2009年
3
これは解決策であるため、回答として受け入れました。しかし、それは「なぜ」を説明していません。より良い解決策または実際の理由を見つけた場合は、ライマンの回答を更新するか、独自の回答を追加します。
— アベル
実際、この答えは私にはうまくいきません。私のプロジェクトは数週間前はうまく機能していましたが、今日試してみたところ、上記の問題が示されています。上記のように（Windows 7の場合）一時ファイルを削除しましたが、同じ問題が解決しません。私はまだ疑問に思って、なぜ...
— Venugopal M
@VenugopalM他の解決策を見つけましたか、上記の解決策は私にはうまくいきませんでした
— Vbp
11

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

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

詳細については、http：//vishaljoshi.blogspot.se/2009/07/appcode-folder-doesnt-work-with-web.htmlをご覧ください。

— リリヤ
ソース
あなたが提供したリンクは私にとっての解決策でした。すべてのクラスをApp_Codeフォルダーから移動し、Classesという名前の新しいフォルダーに配置しました。次に、クラスの名前空間の名前を変更しました（名前空間の終わり= .App_Codeではなく.Classes）。そしてもちろん、すべてのusingステートメントとApp_Codeフォルダーへの参照を更新します。
— krlzlx 2015年
どうもありがとうございました。これは私を夢中にさせていました
— Sperick 2016
これで私も修正されました。ありがとう。
— JonH 2018
9

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

ここにいくつかのより多くの情報があります：

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

— NitroxDM
ソース
いい視点ね。その日のbackのコードが書き直されたので、それが役に立ったかどうかは確認できませんが、このエラーがある人にとっては、共有してくれてありがとう、これは間違いなく素晴らしいポインタになるでしょう。
— アベル
5

これらすべての提案の後、私はまだ問題を抱えていました。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ファイルを提供することに問題はないはずです。

— tggm
ソース
4

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

— ナビーンQ
ソース
3
それは実際には選択肢ではないのではないかと思います。ルートの直下にdllを配置することは、多くのセキュリティリスクによって考慮されます（App_Codeまたはbinは特別であり、IIS / ASP.NETからはアクセスできませんが、ルート内のdllは簡単にダウンロードでき、.NETアセンブリは簡単に逆アセンブルできます）。
— アベル
これも修正するために、ASP.NETMVC4プロジェクトのmodelsフォルダーにクラスを配置しました。
— DShook 2013
4

これは、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" %>
— ジェイソンガイガー
ソース
1
これは実際には問題ではありません。tagprefixはすべてのコントロールで同じである可能性があります
— Spyros
@Spyros問題が解決したので、同意しません。1年以上経ちましたが、これに関するすべてを思い出すわけではありませんが、他の人が読めるようにここに置いておく価値はあります。
— ジェイソンガイガー2014年
この答えは私の問題を解決しました。いくつかの展開の後でのみ、エラーが常に発生するとは限らなかったので、それは奇妙でした。Spyrosのように、これで問題が解決するとは思わなかったので、接続がわかりませんでした。これを投稿してくれたJasonGeigerに感謝します。
— vFein 2016年
その価値のために。これを引き起こしていたコントロールはすべて同じフォルダーにあり、複数の仮想アプリケーションから仮想ディレクトリとして参照されていました。
— vFein 2016年
コメントをスクラッチします。エラーはちょうどその醜い頭を再び示しました。ふりだしに戻る。
— vFein 2016年
4

参照 ： 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.NETFilesフォルダーに配置されます。既定では、アクセス許可はASP.NETローカルユーザーアカウントに付与されます。このアカウントには、コンパイルされたコードにアクセスするために必要な信頼性の高いアクセス許可があります。デフォルトの権限にいくつかの変更があり、バージョン管理の競合が発生した可能性があります。別の可能性は、アンチウイルスソフトウェアが誤ってアセンブリをロックしている可能性があることです。解決策：すべてのコンテンツの一時ASP.NETファイルフォルダーをクリアします。

シナリオ4

説明：web.configのbatch属性がTrueに設定されている場合、ファイルに初めてアクセスするときに必要なコンパイルによって引き起こされる遅延がなくなります。ASP.NETは、コンパイルされていないすべてのファイルをバッチモードでプリコンパイルします。これにより、ファイルが最初にコンパイルされるときに遅延が発生します。バッチコンパイルをオフにすると、アプリケーションに存在する可能性があるが報告されないマスクされたコンパイルエラーが発生する可能性があります。ただし、この問題でさらに重要なのは、ASP.NETに、個々の.aspx /.ascxファイルを単一のアセンブリではなく個別のアセンブリに動的にコンパイルするように指示することです。解決策：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フォルダー内のファイルをタッチして、完全な再コンパイルをトリガーします。

— Sandeep Kumar Narware
ソース
経験則として、私は通常、提供されている最も単純なソリューションを試すことから始めます。上記のシナリオ6の次の例で、問題が解決しました。「解決策：BinフォルダーまたはApp_Codeフォルダー内のファイルをタッチして、完全な再コンパイルをトリガーします。」
— cjo300 8020年
2

これは、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（MVC 3は、このプロジェクトで使用されている）1.0.0.0の代わりに3.0.0.0で指摘しました。

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

— mlapaglia
ソース
2

これは、同じクラス名が複数の.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つのクラス名が重複しないようにすることで、問題が解決します。

— ディーパック
ソース
これを調べてくれたTx。ただし、この例では、を使用しますpartial class。これは、実際には1つのクラスを複数のファイルに分割する一般的な方法（唯一の方法）です。この場合、同じ名前を使用する必要があります。
— アベル
これは、（アプリケーションではなく）Webサイトでの私の問題に近い結果になりました。Tempフォルダーのクリア、App_Codeからの移動、およびその他の提案は機能しませんでした。マスターページの.cs分離コードファイルを見るまで、ファイル名がクラス名と一致しないことに気づきましたMasterPage。これはまだデフォルトでした。右クリックメニューでクラスの名前を変更すると（すべての参照も更新されるため）、エラーは最終的に消えました。私のマスターページがSystem.Web.UI.MasterPageクラスと競合していたと推測することしかできません。
— アンドリューS
2

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

— ロジェリオシルバ
ソース
1

「CleanSolution」に続いて「RebuildSolution」も修正されているようです。

— ローマ人
ソース
質問で説明したように、少なくとも私の状況では、溶液を洗浄しても効果はありませんでした。それが役に立たない理由は、エラーが一時的なASP.NETファイル（1番目と2番目の回答で説明されている）によって引き起こされ、「クリーンソリューション」の実行時にクリーンアップされないためです。
— アベル
0

結局、ページマークアップでMasterTypeが参照される方法を変更しました。

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

詳細はこちらをご覧ください。

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

— クリス
ソース
0

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

— ギレルモグティエレス
ソース
0

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

— クリスチャンハーランド
ソース
0

私も同様の問題を抱えていました。これが私の解決策です。フォルダは別のアセンブリとしてコンパイルされ、同じクラスが2つのアセンブリでコンパイルされるため、like以外のフォルダに関してプロパティ[Build Action]セットを必要とする分離されたクラスを配置します。[Compile]App_CodeApplication_CodeApp_Code

— アリ・マフムーディ
ソース
0

同じクラス名を持つ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

ソリューションを閉じて再度開き、プロジェクトの参照が2倍になっていないか確認します。

ここに画像の説明を入力してください

これは、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')" />

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

— ジェレミー・トンプソン
ソース
0

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

例：

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変更セットの一部として含まれていない可能性があるため、変更をチェックインしてもチームの他のメンバーの問題が解決されない理由を説明できるからです。

— WonderWorker
ソース
0

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

私の解決策は、問題の原因となっているユーザー制御イベントハンドラーデリゲートを別の物理ファイルに移動することでした。

//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)
    {
— marcel_g
ソース
0

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

— チャグバート
ソース
0

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 ++プロジェクトをいずれかのバージョンに変更しても、動作は変わりませんでした。なぜこれが突然機能しなくなったのかはわかりませんが、同様にブロックされた誰かが同様の戦略を使用してピクルスから抜け出す可能性があることを願っています。

— kayleeFrye_onDeck
ソース
0

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

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

— ネイト
ソース
0

他の解決策が機能しなかった場合は、その問題の継承クラスの名前を変更して、aspxファイルとaspx.csファイルを新しい名前に変更してから、解決策を再構築します。その後、問題は確実に解決されます。これは私のためだけに働いた。

例：

aspxファイルで、次の手順を実行して、継承するクラス名をDefaultnewに変更します。

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

aspx.csファイルで、クラスの名前をaspxファイルで使用されているものと同じに変更します

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

public partial class Defaultnew : System.Web.UI.Page
{
— anandd360
ソース
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.