これはVS2015を使ったWebApiプロジェクトです。
再現する手順
Build Outputパスを "bin \"から "bin\Debug \"に変更するまで、すべてが完璧に機能しています。実際、 "bin \"以外の出力パスは機能しません。
もう1つ追加されていることは、 "bin \"にビルドを残している限り、どこかへの別の出力パスがあることでうまくいくということです。
これを解決するための解決策を提供するのを手伝ってください。実際の展開では問題になるでしょう。
プロジェクトにRoslyn referencesがあり、IIS serverにデプロイしている場合、多くのホスティングプロバイダがまだアップグレードしていないため、Webサイトに不要なエラーが発生する可能性があります。そのため、サーバーはRoslynをサポートしていません。
この問題を解決するには、プロジェクトテンプレートからRoslynコンパイラを削除する必要があります _です。 Roslynを削除してもコードの機能に影響はありません。それは私と私が働いていた他のプロジェクト(C#4.5.2)にはうまくいきました。
以下の手順を実行してください。
以下に示すコマンドラインを使用して、以下のNugetパッケージから削除します( またはルートプロジェクトソリューションを右クリックして削除し、 を使用するとNuget Package ManagerのGUIを使用できます)。
PM> Uninstall-package Microsoft.CodeDom.Providers.DotNetCompilerPlatform
PM> Uninstall-package Microsoft.Net.Compilers
次のコードをWeb.Configファイルとrestart IISから削除します。 ( 手順1で問題が解決しない場合のみ、この方法を使用してください。 )
<system.codedom>
<compilers>
<compiler language="c#;cs;csharp" extension=".cs" type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" warningLevel="4" compilerOptions="/langversion:6 /nowarn:1659;1699;1701" />
<compiler language="vb;vbs;visualbasic;vbscript" extension=".vb" type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.VBCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" warningLevel="4" compilerOptions="/langversion:14 /nowarn:41008 /define:_MYTYPE=\"Web\" /optionInfer+" />
</compilers>
この回答のアドバイスに注意してください。これは当面の問題を解決しますが、後日異なる問題を引き起こす可能性があります。
私は同じ問題を抱えています。どうやら.NETコンパイラはGAC
にロードされませんでした。私はそれを解決するためにしました:
まず、パッケージマネージャのコンソールで次のように入力します。
PM> Install-Package Microsoft.CodeDom.Providers.DotNetCompilerPlatform
さて、どういうわけかMicrosoftのNice紳士たちは私たちのためにGACにそれをインストールしないことに決めました。開発者コマンドプロンプトを開いて次のように入力して手動で実行できます。
gacutil -i "C:\*PATH TO YOUR APP CODE*\bin\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.dll"
Microsoftは、あなたがnugetシステムで偶発的に遭遇するバグなしで大丈夫かもしれない全力で全力を尽くすように皆に奨励しようとします。別のソリューションで同じプロジェクトを使用してみてください。誤って(またはしないで)それらの1つで使用している多くの核のうちの1つを更新してください。一方、GACにファイルを置くと、そこに置いたものを忘れてしまい、新しい環境を設定するときにこれらのファイルを含めるのを忘れてしまうため、将来の問題も発生する可能性があります。他の可能な解決策はファイルをサードパーティdllのための中央フォルダに置くことです(それはコンパイラサードパーティを呼ぶのは奇妙ですが)、それは新しい環境を設定するとき壊れた参照の問題を引き起こします。 GACにdllをインストールすることにした場合は、慎重に行ってください。そうでなければ、それぞれのプロジェクトのために再び小片をダウンロードして、それによって引き起こされているすべての厄介なバグを負ってください(少なくとも私がやっと病気になってファイルをGACに置いたときによく発生します)。どちらの方法でも頭痛がして問題が生じる可能性があります。どちらの問題に対処したいのかという問題です。マイクロソフトはnugetシステムを使用することを推奨しています。一般的には、SOTの未知のプログラマーよりもそれらに耳を傾けるほうが良いでしょう。あなたのために。
次のnugetパッケージをプロジェクトに追加するだけです - Microsoft.CodeDom.Providers.DotNetCompilerPlatform
。
同じ問題がありました。
私のアプリがVs2013で動作していたのと同じ問題がありますが、Vs2015に更新した後にエラーが発生します。
私はそれが古いスレッドであることを知っています、しかし、私はDotNetCompilerPlatform.dllの可能なバージョン問題を指摘したいです、f。例更新後。新しく生成されたWeb.configファイルが、リリースされたweb.configと異なるかどうか、特にsystem.codedom部分を確認してください。私の場合、それは1.0.7から1.0.8へのバージョン変更でした。新しいdllはすでにサーバーにコピーされていますが、私は古いweb.configを変更しませんでした(いくつかのサーバーの特別な設定で)。
<pre>
<system.codedom>
<compilers>
<compiler language="c#;cs;csharp" extension=".cs" type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=1.0.8.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" warningLevel="4" compilerOptions="/langversion:default /nowarn:1659;1699;1701" />
<compiler language="vb;vbs;visualbasic;vbscript" extension=".vb" type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.VBCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=1.0.8.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" warningLevel="4" compilerOptions="/langversion:default /nowarn:41008 /define:_MYTYPE=\"Web\" /optionInfer+" />
</compilers>
</system.codedom>
</pre>
2行を更新した後、エラーは消えました。
再現手順によると、アプリケーションのプロパティで出力パスを変更することが、アプリケーションを作成した後の唯一の変更であると想定しました。この変更による唯一のことは、Visual StudioにMSBuildの出力アセンブリを新しいフォルダに配置するように指示することです。しかし、実行時には、ASP.Netは\ binフォルダではなくこの新しいフォルダからアセンブリを読み込むべきであるとは考えていませんでした。
この answer はWebApiアプリケーションのビルド出力ディレクトリを変更する方法を示しています。この記事で示したものとまったく同じエラーを表示するには、web.configの<system.codedom>セクション全体をコメントアウトする必要があります。その後、指示に従って出力パスを変更できます。
アプリケーションの作業が終わったら、<system.codedom>セクションのコメントを外します。アプリケーションでC#6の新しい構文をまったく使用しない場合は、アプリケーションからMicrosoft.CodeDom.Providers.DotNetCompilerPlatformをアンインストールできます。それ以外の場合は、ビルド後のイベントに次のコマンドラインを追加します。
xcopy /Q /Y "$(TargetDir)roslyn\*.*" "$(TargetDir)..\roslyn\"
新しいCodeDomプロバイダーは、常に\ bin内の "\ roslyn"フォルダーを探します。上記のコマンドは回避策として機能し、新しい出力フォルダから\ roslynフォルダを\ binにコピーします。
ただし、私の実験では、Visual Studioの発行ツールは、出力パスの設定に関係なく、出力アセンブリを配置場所の\ binフォルダに発行しました。あなたのアプリケーションはまだ実際のデプロイで動作するはずです。
私の場合、これは私がアプリケーションフォルダとアカウントIIS_IUSRSの権限を変更したときに起こりましたが削除されました。私はアプリケーションフォルダにIIS_IUSRS(IISマネージャ - > YourWebApp - >編集権限 - > Add IIS_IUSRS)を再追加した後、それは働いた。
運用サーバーに公開した後に停止しました。それが私にこのエラーを示した理由はそれが sub フォルダに展開されたからです。 IISで私はサブフォルダを右クリックして "アプリケーションに変換"を実行し、その後これはうまくいきました。
私の場合は、4.5.2のWebアプリケーションと4.6.1の参照クラスライブラリを使用しているときにエラーが発生しました。 Webアプリケーションを4.5.2バージョンに更新したときに、エラーが消えました。
最近Microsoft.CodeDom.Providers.DotNetCompilerPlatform
パッケージをインストールまたは更新した場合は、プロジェクトで参照されているそのパッケージのバージョンが、そのパッケージの正しいバージョンと同じバージョンを指していることを再確認してください。
ProjectName.csproj
に、<Import>
のMicrosoft.CodeDom.Providers.DotNetCompilerPlatform
タグが存在し、正しいバージョンを指していることを確認してください。
ProjectName.csproj
では、<Reference>
のMicrosoft.CodeDom.Providers.DotNetCompilerPlatform
タグが存在し、Include
属性と子の<HintPath>
の両方に存在し、正しいバージョンを指していることを確認してください。
そのプロジェクトのweb.config
で、<system.codedom>
タグが存在し、その子<compiler>
タグのtype
属性のバージョンが同じであることを確認してください。
何らかの理由で、私の場合、このパッケージを1.0.5から1.0.8にアップグレードすると、the<Reference>
の.csproj
タグの古いバージョン1.0. 5 。0を指すInclude
が指定されていました(後で削除しました)。パッケージをアップグレードする)、しかし他のすべては新しいそして正しいバージョン1.0を指していた。 8 。0。
プロジェクトの "Microsoft.CodeDom.Providers.DotNetCompilerPlatform"および "Microsoft.Net.Compilers"パッケージを更新する必要があります。
ASP.NETは、他の種類のアプリケーションのようにアセンブリのbin/debug
またはbinの下のサブフォルダーを検索しません。次の設定を使用して、ランタイムに別の場所を探すように指示できます。
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-Microsoft-com:asm.v1">
<probing privatePath="bin;bin\Debug;bin\Release"/>
</assemblyBinding>
</runtime>
</configuration>
それから問題はもどった。 Microsoft.CodeDom.Providers.DotNetCompilerPlatformとUninstall-package Microsoft.Net.Compilersの両方をアンインストールしましたが、ヘルプが表示されません。それから助けをインストールしなかった。プロジェクトをきれいにし、助けを借りないでください。再起動したサーバーは何の助けにもならない。その時、プロジェクトが最新のものではなく、現在の1.0.5ではなく1.0.3が必要であることに気づいた。だから私は代わりにそのdllバージョンをインストールし、今それは動作します。
これがI 解決 itの方法です。
bin
フォルダを削除しました。Build Solution
をクリックしてください。 VS2017(管理者として実行)>ビルド>ソリューションのビルド 。アプリケーションプールユーザーがApplicationPoolIdentityに設定されているため、このエラーが発生しました。フォルダにアクセスできるユーザー/サービスアカウントに変更しましたが、エラーは消えました。
これが私の調査結果です。私も今日の朝この問題に直面しました。アプリケーションを実行していたアプリケーションプールに現在のユーザーを追加しました。
ステップ:
IISを開く
アプリケーションプールをクリック
問題が発生しているアプリケーションプールを選択します
右クリック - >詳細設定
アイデンティティ の横にある3つのドットアイコンをクリックしてください。
今すぐカスタムアカウントを選択してください
PCのユーザー名とパスワードを入力してください
保存する
アプリケーションを更新してください。そうすれば動作し始めます。 dllにアクセスするためにセキュリティ上の問題がありました。
私はソリューション内にいくつかのプロジェクトがあり、Webプロジェクト(このエラーを出している問題)はスタートアッププロジェクトとして設定されていませんでした。このWebプロジェクトをスタートアッププロジェクトとして設定し、メニュー項目[デバッグ] - > [デバッグ開始]をクリックして動作しました。デバッグをやめてもう一度試してみると、元に戻りました。変です。
CppCodeProviderアセンブリへの参照を追加します。
BIN
フォルダが完全にアップロードされているか、ファイルに見つからないかを確認します。
[出力]タブをクリックし、次のようなものがないことを確認してください。
==========すべて再構築:14成功、1失敗、0スキップ========
そしてbin
フォルダを開いて、それが最新のものかどうかを確認してください。
私は最初は無視していたTypeScriptエラーをたくさん持っていましたが、それらがビルドを壊していてDLLがコピーされていないことを忘れていました。
私はちょうど同じ問題を抱えていました、そしてそれは私がプロジェクトの場所を移動し、単に仮想ディレクトリを作り直す必要があったからです。
私が試したこのエラーに関して:
uninstall-package Microsoft.CodeDom.Providers.DotNetCompilerPlatform
uninstall-package Microsoft.Net.Compilers
を削除して、再度インストールします。これらはすべて有効な解決策のように見えますが、 新しいエラーのみを生成できました そして、最終的には、特定の参照/核種が欠落しているときにエラーが表示されるようです。
私の場合、最近Microsoft Officeを再インストールし、Microsoft.Office.Coreなどのアセンブリを参照していました。新しいインストールには必要なパッケージが含まれていないようだったため、ソリューションを正しくビルドできませんでした。
Microsoft.Officeを参照する必要がなくなるまでコードを修正することでこの問題を解決できましたが、必要なパッケージを検索し、それに応じてインストールすることで解決できました。
Visual Studioからの不明瞭なエラーメッセージのようです。
私の場合、私のWebプロジェクトは適切にロードされていませんでした(プロジェクトが利用できないことを示していました)、管理モードでビジュアルスタジオを開いた後にWebプロジェクトをリロードする必要があり、すべて正常に機能しました。
起動コマンドからinetmgrに移動しますIISマネージャコンソールで、[既定のWebサイト]の下のアプリケーションフォルダを選択し、そのフォルダを右クリックして[アプリケーションに変換]をクリックします
私たちが遭遇した例外はローカルではなくリモートサーバーでした、Azure CIはpackagesフォルダーからそれを読んでいましたが、上で言及されたコンパイラバージョンは見つかりませんでした。
これを修正するために、プロジェクトファイルを次のように変更しました。
ここでは環境変数を直接参照しているパッケージを参照していません。
これで問題は解決しましたが、私たちの場合は "package.config"から直接パッケージを使用するのではなく、チーム間でバージョンの整合性を維持するために別のフォルダーを使用します。