名前空間が認識されない（存在するにもかかわらず）

このエラーが発生しています：

タイプまたは名前空間名 'AutoMapper'が見つかりませんでした（usingディレクティブまたはアセンブリ参照がありませんか？）

面白いのは、自分のプロジェクトにすでにその参照があることです。

そしてこれは私のコードです：

using System.Collections.Generic;
using DataContract;
using SelectorDAL;
using AutoMapper;

namespace SpecimenSelect
{
    public class SpecimenSelect : ISpecimenSelect
    {
        public SpecimenSelect()
        {
            SetupMaps();
        }

        private static void SetupMaps()
        {
            Mapper.CreateMap<SpecimenDetail, SpecimenDetailContract>();
        }

もう1つの奇妙なことは、AutoMapperを使用し、まったく同じAutoMapper.dllファイルを参照している2つのプロジェクトがソリューションにあることです。どちらも完璧に機能します。

これは、1つのスクリーンショットです。

そして、これがそのコードです（うまくコンパイルされます）：

using System.Collections.Generic;
using AutoMapper;
using DataContract;
using SelectorDAL;

namespace PatientSelect
{

    public class PatientSelect : IPatientSelect
    {
        public PatientSelect()
        {
            SetupMaps();
        }

        private void SetupMaps()
        {
            Mapper.CreateMap<Patient, PatientContract>();
            Mapper.CreateMap<OrderedTest, OrderedTestsContract>();
            Mapper.CreateMap<Gender, GenderContract>();
        }

両方の参照のプロパティページに同じデータがあるようです。

何が欠けていますか？

私は試した：

1. Visual Studioの再起動
2. usingステートメントなしの参照（つまりAutoMapper.Mapper.CreateMap）
3. クリーンと再構築

他のアイデアはありますか？

プロジェクトが.NET Framework 4クライアントプロファイルを使用するように設定されていないことを確認してください。

これを確認/変更するには、ソリューションではなくプロジェクトを右クリックし、[ プロパティ] -> [ アプリケーション] -> [ ターゲットフレームワーク]を選択します。ターゲットフレームワークは、そのページのドロップダウンです。

これはVisual Studioの問題です（バグと呼んでもかまいません）。AutoMapperには、.NET Framework 4クライアントプロファイルから除外されたアセンブリが必要です。プロジェクトはそのバージョンのフレームワークを使用しているため、機能しなくなります。

参照しているプロジェクトの.NET Frameworkバージョンが参照しているプロジェクトよりも高い場合、同様のエラーがビルドプロセスに伝播します。つまり、4.5.1を対象とするプロジェクトを参照する4.5を対象とするプロジェクトは、同じエラーを返します。

エラーメッセージは、明確に参照したアセンブリを参照するように指示するため、ビルドされない理由に関する合理的な説明がないため、これが発生した場合は、より適切なエラーメッセージが必要です。

愚かな質問をさせてください：2つのautomapper.dllファイルが存在する可能性がありますか？一つAutoMapperのない名前空間と1？両方のプロジェクトのパスを確認します。

また、usingコマンドの順序が異なることに気付きました。それは問題ではありませんが、それらをシャッフルしようとしましたか？

クラスがコンパイルされない場合、たとえそれがプロジェクト内であっても、以下を確認してください。

1. クラス名が完全に同じかどうか
2. 名前空間がまったく同じかどうか
3. クラスプロパティがビルドアクションを表示するかどうか=コンパイル

他のすべての答えがあなたを助けない場合、これは最も簡単な解決策でなければなりません

私は答えの中から自分のセットアップの何が問題なのかを探していましたが、すべて試してみました-何も機能しませんでした。その後、Visual Studio 2018がMicrosoftによって開発されたことに気付きました。だから私はほとんどの人がすることをしました、

Visual Studioを再起動し て動作しました

ファイルを含むフォルダーを右クリックして[ プロジェクトから除外 ]を選択し、もう一度右クリックして[ プロジェクトに含める ]を選択することで、この問題を解決しました（最初に[ すべてのファイルを表示]を有効にして、除外されたフォルダーを表示する必要があります）

VS2010で参照が認識されないという同様の問題があり、ここでの回答では修正できませんでした。

私のソリューションの問題は、参照されているプロジェクトが配置されているパスの拡張子に関連していました。私はSVNで作業しているので、いくつかのテストを行うためにリポジトリのブランチを作成し、そのブランチはパス構造の2つのレベルを増やしたため、パスが長すぎてウィンドウで使用できなくなりました。これはエラーをスローしませんでしたが、プロジェクト参照の名前空間を認識しませんでした。プロジェクトの場所を修正してパスを小さくすると、すべてがうまくいきました。

私の場合、参照されたdllは.Net Frameworkの上位バージョンでビルドされました。参照を追加した後、それを使用できました。しかし、ビルドを実行するとすぐに、「参照がありません」というエラーがポップアップします。エラーが発生するDLLを更新しますが、ビルドできません。この投稿でフレームワークのバージョンを確認したので、同じバージョンで参照プロジェクトをビルドすることで解決できました。

おそらく、プロジェクトのタイプテーブルが正しくない状態にあります。参照を削除/追加しようとし、それが機能しない場合は、別のプロジェクトを作成し、コードをインポートして、機能するかどうかを確認します。

私はVS 2005を使用しているときにこれに遭遇しましたが、 MSがその特定の問題を今までに修正していると予想されます。

質問は既に授与されていますが、確認する必要がある追加の詳細がまだ説明されていません。

私もこの動作をしていて、プロジェクトBがプロジェクトAで参照されていましたが、プロジェクトBの名前空間がプロジェクトAで認識されませんでした。少し調べたところ、パスが長すぎることがわかりました。プロジェクト（AとBの両方）のパスを減らすことにより、参照が表示され、利用できるようになりました。

私はこの理論をテストするために、はるかに少ないパスの深さでプロジェクトCを作成しました。プロジェクトAでプロジェクトCを参照しました。参照は正常に機能しました。次に、プロジェクトCをソリューションから削除し、プロジェクトCをプロジェクトBと同じ深いパスに移動し、プロジェクトCをソリューションに追加してコンパイルしました。その後、Cオブジェクトを投影する可視性がなくなりました。

私の場合、クラスライブラリをコピーしていて、プロジェクトプロパティの「アセンブリ名」を変更していないため、一方のDLLが他方を上書きしていた...

これはVisual Studio 2019で私に起こりました。私にとっては、自分のソリューションで別のプロジェクトを参照しようとしていました。他の人を助けるために私が取った手順は次のとおりです：

1. 参照したいプロジェクトが「参照」にリストされていることを確認しました
2. 両方のプロジェクトが正しいバージョンの.NET Frameworkを使用していることを確認した
3. プロジェクトをビルドしました（緑色の「開始」矢印をクリックしました）

手順1と2を実行してもエラーが発生するので混乱しましたが、プロジェクトをビルドすると問題が解決したようです。

コンパイル中には問題ありませんが、実行中にネームスペース/メソッドが見つからないという同様の問題に直面しました。これの理由は、参照しているアセンブリがGACにデプロイされ、それ以降変更されたため、アセンブリを参照したときですVisual Studionでは最新のものを使用していましたが、ランタイム中にGACのバージョンが使用されていました。

私の場合、VS 2015でのみエラーが発生しました。VS2017でプロジェクトを開くと、エラーは発生しませんでした。

クレイジー。知っている。

ここですべてのオプションを試しました。生成されたDLLを再起動、クリーニング、手動でチェックインします（これが実際にごちゃごちゃしているかどうかを理解するには非常に重要です）。

オプションでMSBuildのVerbosityを "Detailed"に設定することで機能しました。

この質問は元のポスターですでに回答されていますが、誰かがMS-Testプロジェクトでこれに遭遇した場合に備えて：

Visual Studio内から、[テスト]メニュー-> [テスト設定]-> [既定のプロセッサアーキテクチャ]をクリックし、アーキテクチャが参照している他のアセンブリのアーキテクチャと一致していることを確認します。他のアセンブリがx64で、テスト設定がx86の場合、元のポスターにあった症状が発生する可能性があります。

私はXamarinプロジェクトに取り組んでいましたが、いつものように、objフォルダーを削除して再構築すると問題が解決し、VSが認識していない名前空間は自分のプロジェクトのコードでしたBTW

私の場合、そのアセンブリの削除/追加はうまくいきました。

私は同様の問題を抱えていて、トラブルシューティングに少し時間がかかったので、それを共有することを考えました：

私の場合解決できなかった名前空間はCompany.Project.Common.Models.EFでした。新しいCompany.Project.BusinessLogic.Common名前空間にファイルを追加しました。

ファイルの大部分は

using Company.Project;

そして、モデルをCommon.Models.EFとして参照します。も持っていたすべてのファイル

using Company.Project.BusinessLogic;

VSが使用する名前空間を決定できなかったため、失敗しました。

解決策は、2番目の名前空間をCompany.Project.BusinessLogic.CommonServicesに変更することです。

Visual Studio 2019を再起動します。