VS2008でソリューションを構築する際に問題が発生しました。通常、環境内で正常にコンパイルされます。時々、それは失敗します:
/xxx_WEB/secure/CMSManagedTargetPage.aspx(1): error ASPPARSE: Circular
file references are not allowed.
再構築すると正常に動作します。
ただし、現在、CruiseControl.NETシステムをセットアップしている最中であり、ビルドをCCに統合する前に、チェックアウトしたコードをMSBuildでテストしています。これで、MSBuildを実行するたびに、次のようになります。
"Q:\cc\xxx\checked out from svn\xxx.sln" (default target) (1) ->
(xxx_WEB target) ->
/xxx_WEB/secure/CMSManagedTargetPage.aspx(1): error ASPPARSE: Circular
file references are not allowed.
問題は、この参照がどこにあるのかわからないことです。
ソリューション全体で参照を検索しましたが、ページまたはそのコードビハインド、または文字列内以外の場所で、ページ自体(CMSManagedTargetPage)への参照を見つけることができませんでした。例:
C:\ dev2008\xxx\IWW.xxx.ASPNET\AspxHttpHandler.cs(82):inputFile = context.Server.MapPath( "〜/ secure/CMSManagedTargetPage.aspx"); C:\ dev2008\xxx\IWW.xxx.ASPNET\AspxHttpHandler.cs(83):virtualPath = "〜/ secure/CMSManagedTargetPage.aspx";
私のアセンブリの参照も問題ありません(私が知る限り)。私のWebアプリケーションは依存関係の「最上位」にあり、それを参照するものはないため、障害のあるページは循環参照を引き起こすことができません。もちろん、ページ自体が同じアセンブリ/ Webサイト内のUserControlなどを参照している場合もありますが、前述のように、CMSManagedTargetPageで検索しても結果が得られなかったため、これは発生しません。
Web.configでバッチ属性を変更しても、MSBuildには影響しませんでした。
VSで「時々」失敗し、MSBuildで常に失敗するのは非常に奇妙だと思います。微妙な点が欠けていますか?
再投稿元:
http://ellisweb.net/2009/12/fixing-the-circular-file-references-are-not-allowed-error-in-asp-net/
次の設定がある場合:/folder1/Control1.ascx>参照Control2 /folder2/Control2.ascx>参照Control3/folder1/Control3.ascxこれは、folder1dllがfolder2を参照することを意味します。再びfolder1dllを参照し、「循環ファイル参照」を引き起こすdll。
これは今日私を助けてくれました。ルート内の別のページを参照するフォルダー内のマスターページを参照するマスターページがルート内にありました。どのページがどのフォルダにあるかをシャッフルすることは魅力のように機能しました。
また、この問題が発生し、[固定の名前付けと単一ページのアセンブリを使用する]を選択することで、VisualStudio内から正常な発行を取得できました。何らかの理由で、循環参照があるとコンパイラーが考えるのを避けているようです。
同じ問題が発生したときに、あなたの投稿に遭遇しました。循環参照の問題にはおそらく百万の解決策がありますが、私のものはマスターページの直接の結果でした。
ネストされたフォルダーの外に、ネストされたマスターページを使用して誤ってページを作成しました。例:
Master1.Master
Page.aspx
(Folder1)
Master2.Master
Page.aspxがMaster2.Masterをマスターページとして参照している間、正常にビルドされ、「公開」するとエラーが発生します。
私も同様の問題を抱えていて、@ JBicfordの回答から密接な手がかりを得ました。別のフォルダーでMaster.masterを使用して、WebサイトのルートでDefault.aspxを使用していました。それがそれを引き起こす可能性があるかどうかわからない、まだこのソリューションをテストしていません。
しかし、公開の問題を解決することに関心がある人にとっては、以下のオプションはVS 2012で機能しますが、他のフォルダーやページへの依存関係が正しくないため、他のすべてのオプションは失敗します。
Visual Studioでページをバッチコンパイルすると、このエラーが発生することがわかりました。 web.configのコンパイル要素にbatch = "false"を設定することで、この問題を修正することができました。
具体的には、問題のあるページがあるディレクトリにweb.configを追加しました。そのweb.configファイルには、次のコンテンツのみが含まれています。
<?xml version="1.0"?>
<configuration>
<system.web>
<!-- Added to prevent error ASPPARSE: Circular file references are not allowed. -->
<compilation batch="false" />
</system.web>
</configuration>
そうすれば、必要に応じて、Visual Studio/MSBuildは影響を受けていない他のディレクトリをバッチコンパイルできます。
コンパイル要素とバッチ属性の詳細については、 msdn を参照してください。
私にとっては、マスターページにもaspxページを登録していました。
例(マスターページ内):
<%@ Register Assembly="MyPage" Namespace="MyPage" TagPrefix="MyPage" %>
...
<asp:ContentPlaceHolder id="MyPage" runat="server"></asp:ContentPlaceHolder>
そして、aspxページで:
<%@ Page Language="C#" MasterPageFile="~/MasterPage.master" AutoEventWireup="true"
CodeFile="MyPage.aspx.cs" Inherits="MyPage" Title="Untitled Page" %>
<asp:Content ID="SomeContent" ContentPlaceHolderID="MyPage" Runat="Server">
レジスターを削除すると修正されました。
私が好きな人のために、この問題を何度も繰り返しています。私は別の解決策があるかもしれないと信じています他のすべてが失敗することです。 MVCアプリケーションでこの問題が発生し、数週間かけてさまざまな提案を試みましたが、役に立ちませんでした。
私たちが見つけたのは、McAfee Virus Scanner V8.0を実行しているということでした。オンアクセススキャナーを無効にすると、VirusScanコンソールから問題なくビルドおよびデバッグできることがわかりました。
唯一のことは、この設定を無効にすると、15分ごとに自動的に再度有効になることです。
これは共有する価値があると感じました。
ありがとう、ディーン
編集:これは、マシンへのローカル管理者アクセス権がある場合にのみ機能します。セキュリティの観点から、AVスキャナーをオフにすることについては正当な懸念があります(当然のことながら)。実際、ネット管理者によって制御されている作業環境にいる場合は、それらからプッシュバックを受け取ることさえあります。これを行う別の方法があると確信していますが、今のところこれは私たちにとってはうまくいくようですが、別の回避策(つまりネット管理者に優しい)を見つけたら、ここで共有します。
マスターページ内に含まれているユーザーコントロール(ASCX)がある場合、この動作を経験します。
通常、エラーは2番目のビルド後に消えるので、単に無視します。
私はこの問題を抱えていましたが、どの提案もうまくいきませんでした。私はユニークなケースかもしれませんが、他の人が同じ問題に遭遇した場合に備えて:
私のはCircular References
とは何の関係もないようで、実際には私のビルド出力が原因でした。しばらくしてどこにも行かなくなった後、ロードできなかったコントロールにブレークポイントを設定し、ヒットしないことを通知する通知を受け取りました。
プロジェクトプロパティとソリューション構成設定の両方をAny CPU
用にビルドするように変更すると、問題が修正されました。
このバグはASP.NET4.0にまだ存在します。
私が得たエラーは次のとおりです。
/DirA/PageA.aspx(3): error ASPPARSE: Circular file references are not allowed.
/DirA/PageA.aspx(71): error ASPPARSE: Unknown server tag 'Controls:ControlA'.
ControlAは、PageA.aspx(3)で参照されているものと同じコントロールでした。このエラーを停止するには、ControlAをPageAと同じディレクトリに移動する必要があることがわかりました。
実際、この投稿では、なぜそれが発生するのか、そしてそれを修正する方法を説明しています: http://www.gitshah.com/2011/04/how-to-fix-circular-file-references-are.html
ASP.Netの「循環ファイル参照は許可されていません」エラーを修正する方法
.Netプロジェクトの1つで、興味深い問題に遭遇しました。私はそれを修正するのに数時間を無駄にしました。したがって、他の人が同じ問題を修正するために時間を無駄にする必要がないように、私は自分の調査結果を共有することにしました。
問題
問題は非常に単純で、アプリはビルドされませんでした。 MSBuildを使用してASP.NetWebプロジェクトをビルドしているときに発生したエラーは、次のとおりです。/someProject/Controls/A/ucA.ascx(2):エラーASPPARSE:循環ファイル参照は許可されていません。
もちろん、エラーは私のコードにある種の循環参照があることを示していました。誤って循環参照を作成した場合は、周りを見回して確認と再確認を行いました。ただし、循環参照がある場合、コードはコンパイルされません。コードは正常にコンパイルされていましたが、aspnet_compiler.exeを実行すると失敗していました。
ASP.Netコンパイルツール(aspnet_compiler.exe)を使用すると、ASP.Net Webアプリケーションをコンパイルできます。これにより、エンドユーザーはアプリケーションへの最初の要求で遅延が発生しないため、アプリケーションのパフォーマンスが向上します。
もう一度確認しましたが、循環依存に関連するコードは確かにありませんでした。なぜaspnet_compiler.exeが循環ファイル参照について不平を言っていたのでしょうか。
説明
少しグーグルすると、デフォルトで、Webサイトプロジェクトで、ASP.Netがフォルダーごとに1つのDLLを作成することがわかりました。したがって、次の設定がある場合:
ユーザーコントロールucA.ascxは、ディレクトリ「A」にあります。 ucA.ascxは、別のユーザーコントロールucB.ascxを参照します。ユーザーコントロールucB.ascxは、ディレクトリ「B」に存在します。 ucB.ascxは、別のユーザーコントロールucC.ascxを参照します。ユーザーコントロールucC.ascxは、ディレクトリ「A」にあります。
フォルダAのDLLはフォルダBのDLLを参照し、フォルダBのDLLは再びフォルダAのDLLを参照するため、「循環ファイル参照」が発生します。
これが、aspnet_compiler.exeが「循環ファイル参照」エラーで失敗する理由です。
修正
この問題を修正する方法は2つあります
ユーザーコントロール(またはMasterPages)を再配置して、循環参照を削除します。通常、これはユーザーコントロールを別々のディレクトリに移動することを意味します。この例では、ucC.ascxを新しいディレクトリ「C」に移動します(推奨される解決策)。 web.configファイルのコンパイルタグでbatch =” false”を使用します。これにより、サイト内のコントロール/ページごとに新しいDLLが作成されます。これでエラーは修正されますが、パフォーマンスが非常に悪いため、回避する必要があります。
UcC.ascxを別のディレクトリに移動しましたが、エラーはなくなりました。
ほとんどの場合、これはaspxページをコピーした後に発生します。 Inherits="MyPage"
と記載されているクラスがサイト全体で繰り返されていないことを確認してください。
大規模な開発のオーバーホール中に、これと同じエラーが発生しました。私の特定のケースでは、これは、未使用または名前が変更されたファイルをドラッグアンドドロップする「JUNK」フォルダを使用していたためです。ジャンクフォルダがコンパイルされていて、最近削除したファイルがこの問題の原因でした。
ジャンクフォルダ内の個々のファイルを除外することでこれを修正しました。
私にとってこれらのトリックはうまくいきませんでした
-batch = trueの設定-asp.net一時ファイルの削除とIISリセット-疑わしいascxファイルの置換
問題は、最近追加されたプロジェクトをソリューションに参照し、最終ビルド後にアンロードすることでした。この新しく追加されたライブラリへの参照を削除すると、問題が解決しました。
私が継承したいくつかのコードで同じ問題。
私の問題は、app_dataフォルダーにファイルがありましたが、その中にMyControlsの名前空間がありました。そのファイルをapp_dataフォルダーから移動し、新しいフォルダー「mycontrols」を作成しました。