私は小さなWPFアプリケーションを持っています。これは以前はうまくコンパイルされていましたが、もうありません。どの時点で構築が停止したのか、本当に言えません。ある日はうまくいきましたが、次の日はうまくいきませんでした。
プロジェクトの構造は次のとおりです。
標準の.net dlls以外のプロジェクトまたは外部参照はありません。
以下は、問題の発生元のユーザーコントロールです。
<UserControl x:Class="TimeRecorder.HistoryUserControl"
xmlns="http://schemas.Microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.Microsoft.com/winfx/2006/xaml"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
xmlns:d="http://schemas.Microsoft.com/expression/blend/2008"
xmlns:local="clr-namespace:TimeRecorder.ViewModel"
xmlns:framework="clr-namespace:TimeRecorder.Framework"
mc:Ignorable="d" Height="Auto" Width="Auto" Padding="5">
<UserControl.Resources>
<local:HistoryViewModel x:Key="ViewModel"/>
<framework:BoolToColorConverter x:Key="ColorConverter"/>
</UserControl.Resources>
<StackPanel DataContext="{StaticResource ViewModel}">
そして、ここに私が得るエラーがあります:
これはスクリーンショットの1つのファイルだけではなく、このプロジェクトのすべてのユーザーコントロール/ウィンドウファイルのxamlに同様の方法で追加するすべての参照です。
したがって、ファイルはそこにあり、ファイルの名前空間は正しいです。xamlファイルの名前空間/クラス名は(私の理解では)正しいです。 xamlを入力するとインテリセンスが得られるので、ファイルは正常に検出されますが、コンパイル時には検出されません。
他の投稿でこれに対する最も一般的なソリューションは、.netフレームワークバージョンです。現在、メインプロジェクトとテストプロジェクトの両方で.Net Framework 4に設定されています。クライアントプロファイルではなくフルバージョン。
私が台無しにしたと思うもの:構成マネージャーでは、両方のプロジェクトのプラットフォームが任意のCPUに設定されていますが、これを解決しようとすると、メインプロジェクトがx86に設定され、テストプロジェクトは任意のCPUに設定されました。そのため、構成マネージャーのメインプロジェクトに任意のCPUを手動で追加しました。しかし、私は正直に、これを正しく行ったかどうか、あるいはそれを行うべきかどうかも知りません。それでは、追加の質問として、構成マネージャーをデフォルト状態にリセットする方法はありますか?これは主な問題について何か言いたいことがありますか?メインプロジェクトが常にx86に設定されているかどうか、またはどういうわけかx86に変更してから壊れたかどうかはわかりません。前述のように、このプロジェクトはしばらくの間うまくコンパイルされていました。
助言がありますか?ここでとりとめのない代わりに、コードやその他の質問に関する詳細な質問に答えます。
それが私に起こるたびに、私はちょうどビジュアルスタジオを再起動し、ソリューションを再構築し、それはうまく機能しました..理由を言うことはできません
「ネームスペースに存在しません」というメッセージに加えて、x64およびARMターゲットのウィンドウを表示できませんでした。
ビルドをx86モードに切り替え、再構築ソリューションを実行し、x64モードに切り替えてから再構築すると、[両方の]問題が修正されることがわかりました。
X64ソリューションを再構築するだけでは何もしませんでした。
これは、Visual Studio 2012(Update 3)で私にとってうまくいったことです。
xmlns:framework="clr-namespace:TimeRecorder.Framework;Assembly=MyAssembly
Build
-> Build Solution
私がそれが助けたとわかったこと(特にこのエラーがApp.xaml
)はトラブルを引き起こす参照をコメントアウトし、再構築してからコメント解除します Ithinkwhatこれにより、エラーでビルドを停止するのではなく、プロジェクト全体を実際にビルドできます。
私が収集できるものから、アプリは特定の順序でファイルを構築しようとしているので、App.xaml
またはおそらく参照内の他のクラスファイルエラー、エラーの原因となっているファイルが正しくコンパイルされていないため、その名前空間でファイルが見つからない理由。
ソリューションを再構築します(場合によってはクリーンにしてから、より適切にビルドできます)。次に、エラーリストを見て、一番下までスクロールすると、アセンブリをコンパイルできないエラーを示している可能性が高く、XAMLコンパイラは、おそらく新しいバージョンではなく、キャッシュバージョンのアセンブリを使用しています構築することを意味します。
同様の問題がありました。私の場合、私は次のことをしなければなりませんでした
<local:HistoryViewModel x:Key="ViewModel"/>
)HistoryViewModel
クラスを含むファイル)上記の方法はうまくいきました。
私のために働いたもの:-ソリューション構成をデバッグからリリースに切り替える-構成をリリースからデバッグに切り替える
ターゲットフレームワーク「.Net Framework 4.5」のアプリケーションを「.Net Framework 4.6」に変更し、機能しました!
どのソリューションも私にとってはうまくいきませんでした。このように修正しました:
同様の奇妙な例を次に示します。
<UserControl x:Class="Gtl.Ui.Controls.WaitControl"
xmlns="http://schemas.Microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.Microsoft.com/winfx/2006/xaml"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
xmlns:d="http://schemas.Microsoft.com/expression/blend/2008"
xmlns:controls="clr-namespace:Gtl.Ui.Controls"
mc:Ignorable="d"
d:DesignHeight="120" d:DesignWidth="120"
Background="Transparent">
...
</UserControl>
コンパイルします(VS2013)。
<UserControl x:Class="Gtl.Ui.Controls.WaitControl"
xmlns="http://schemas.Microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.Microsoft.com/winfx/2006/xaml"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
xmlns:d="http://schemas.Microsoft.com/expression/blend/2008"
xmlns:controls="clr-namespace:Gtl.Ui.Controls"
mc:Ignorable="d"
d:DesignHeight="120" d:DesignWidth="120"
Background="Transparent"
IsVisibleChanged=onIsVisibleChanged>
...
</UserControl>
「Gtl.Ui.GtlにタイプUiが見つかりません」というエラーを生成します(コードビハインドにハンドラーメソッドが存在することを確認します)。回避策は、クラスコンストラクターにハンドラーを追加することです。
Xamlで名前空間を呼び出そうとしたときに、同じ問題に直面しました。クラスが名前空間で利用できないことを示していました。よく検索しました。最後に、この問題がVSにあることがわかりました。私はVS 2013を使用しています。以下の手順を試しました。
変化する
xmlns:VM="clr-namespace:MyFirstAppViewModel"
に
xmlns:VM="clr-namespace:MyFirstAppViewModel;Assembly=ViewModel"
この問題が数時間無駄になって循環していた。別のユーザーコントロールdllをプロジェクトに移動したので、dllは参照されず、プロジェクトでコンパイルされました。これによりプロジェクト全体が壊れたため、すべてのネームスペース、パス、およびファイル名を詳細に確認しました。 objファイルを削除して、リリースとデバッグ、x86とAnyCPUの間で変更を試みました。すべてを保存して開き、まだ再コンパイルしない喜び。
以前に同様の問題を抱えていたことを覚えておいてください、VS2013でフラグ付けされたエラーは、XAMLを変更する必要がある場所に直接関連していませんでしたが、
x:Name="myControl"
すべてのコントロールで、代わりに
Name="myControl"
それを修正しました。
「コード分析の実行」コマンドを実行すると、すべてが再構築され、ほとんどの場合、問題が修正されます(プロジェクトを右クリック>分析>コード分析を実行)。これにより、通常、リソースファイルも再構築され、文字列などが検出されます。
このスレッドですべてのソリューションを試しましたが、どれも機能しませんでした。ソリューションの構成が原因であることが判明しました。私のWPFアプリは、それを必要とするいくつかのネイティブな依存関係のためにX64用にビルドするように設定されましたが、ソリューション構成はプロジェクトのAnyCPUに設定されたままでした。ソリューション構成マネージャーでプロジェクトの新しいX64構成を作成すると、XAMLデザイナーは最終的に自分のタイプと名前空間を認識することができました。
x:Key="ViewModel"
多分グリッチがあるlocal:
と入力すると、VSはHistoryViewModel
を表示しますか?Class
がpublic
かどうかも確認しますVisual Studio 2017 Community Editionで今日この問題に挑戦してください。ここですべての提案を試してみました(VS 2017をリセットし、x64からx32に変更し、再び元に戻したなど)、他のソースからは利用できませんでした。 Intellisenseはすべてが揃っていることを知っていますが、毎回同じエラーが発生していました。
とにかく、私の修正は非常に簡単であることが判明しました...あなたが問題に数時間を費やしたとき、彼らはいつもそうではありません!
基本的に、私は次のことをしました...
ビルドを成功させるには、VSやアセンブリ内の「何か」をリセットする必要があるようです。ビルドが成功したら、コードをもう一度挿入してください。
これが誰かを助けることを願っています:)
このエラーは通常、最後のビルド中にプロジェクトが正常にビルドされなかったときに発生します。
ステップ-1)まず、XAMLまたは.csファイルからコードの原因となっているエラーをすべて削除し、F5キーを押してプロジェクトをビルドおよび開始します。
ステップ2)XAMLのコードを引き起こすエラーを1つずつ追加します。
ビルドメニューからコード分析を実行するだけです
問題は、x86ターゲットを作成すると、特定のプロジェクトの出力パスがbin\x86\Debugに設定されることです。エクスプレッションブレンドはこれをまったく好まないようです。 bin\Debugの内容にのみ関心があるようです。
たとえば、x86プロジェクトの出力パスをbin\debugに変更した場合、きっと動作するはずです。まあ、とにかく私のために働く:)
これは私にとって繰り返し起こる問題です。 [警告]タブを調べるソリューションを見つけたときの1つ。 。NET frameworkバージョンの問題であり、次のように述べていました。
警告9プライマリ参照「myDll」は、「。NETFramework、Version = v4.5.2」フレームワークに対して構築されたため、解決できませんでした。これは、現在ターゲットになっているフレームワーク「.NETFramework、Version = v4.0」よりも高いバージョンです。
追加する.dllファイルのターゲットフレームワークは、アプリのターゲットフレームワークと同じである必要があります。
私は.xamlのヘッダーでxmlns:local = "using:MyRootNamespace.ChildNamespace"を使用していましたが、それをxmlns:local = "clr-namespace:MyRootNamespace.ChildNamespace"に変換しました。仕事、そしてそれは働いた。
オブジェクトのレイアウトのバッファリングに不具合があります。何かが名前変更または移動されると、失われます。私にとって一般的に機能するのは、完全に新しいクラスを作成し、すべての古いコードをコピーし、それを新しいクラスで動作させてから元のクラスを削除することです。新しいクラス名で起動して実行した後、元の名前に戻すことができます(通常はそうではありません)