問題タブ [project-reference]

他の70のプロジェクトを含むソリューションがあります。私の質問は: プロジェクトがどこで使用されているかを知るにはどうすればよいですか? 参照を 1 つずつ検証するために、これら 70 のプロジェクトすべてを開きたくありません。特定のプロジェクトを使用しているプロジェクトを確認するにはどうすればよいですか?

編集 XMLまたはVSのリファレンスで1つずつ検索したくありません。手っ取り早い方法でお願いしたいです。

WinForms プロジェクトでは、Excel シートからデータをインポートする機能を提供する必要があります。

プロジェクト参照で MS Office ファイル (ここでは Office 2003) を参照する方法があります。

ビルド環境にわずかな違いがあるたびに、プロジェクトの参照が壊れ、Excel が見つからないというエラーが表示されます。

私の質問は、Office 2003 ファイルを WinForm アプリケーションに正しく参照する方法は?

私には2つのプロジェクトがあります：A/B。プロジェクトAは、B（ロジックアイテム）のオブジェクトにバインドされているすべてのWinFormを含むプロジェクトです。

AにはタイプA.Formのオブジェクトがあります

BにはタイプB.SerializerB.Logicのオブジェクトがあります

ここで、AにはBへの参照があり（ただし、BにはAへの参照はありません）、A.FormにはタイプB.Logicのメンバー変数が含まれています。ある時点で、すべてのデータがB.Logicに格納されたら、B.Serializer（B.Logic）を呼び出して、このオブジェクトをディスクに保存しようとします。

この時点で、A.Fromがシリアル化可能としてマークされていないというエラーがシリアル化時に発生します。

しかし、プロジェクトBにはAへの参照がまったくなく、A.Formを参照するメンバーがSOMEHOWにあったとしても、コンパイルすらすべきではありません。

複数のサブプロジェクト (約 20) で構成される .NET プロジェクトがあります。いくつかのソリューションがあり、それぞれが特定のソリューションに関連するサブプロジェクトのみを含んでいます。

任意の解決策を可能にするために、サブプロジェクトはプロジェクト参照によって相互に参照することはなく、直接の dll 参照によって参照されます。HintPath に $(Configuration) を含めるために csproj ファイルを微調整する必要があるため、デバッグ ビルドはデバッグ dll を参照し、リリース ビルドはリリース dll を参照します。

すべてうまく機能しますが、大きな問題が 2 つあります。

1. VS は、依存関係の計算のために dll 参照を認識しません。新しいプロジェクトまたは参照が追加されるたびに、[プロジェクトの依存関係] ダイアログを使用して依存関係を手動で指定する必要があります。これは面倒です。
2. Resharper も Visual Assist も使用していません (優れたツールですが、使用していません。当然のことです)。私たちは、標準の "Browse to Definition" コマンド (たとえば、ソース コードのコンテキスト メニューから利用できます) を使用したいと考えています。重大な問題は、あるプロジェクトがプロジェクト参照を使用して他のプロジェクトを参照している場合にのみクロスプロジェクトで機能し、参照先のプロジェクトがソリューションに含まれていても、参照が直接 dll 参照である場合は機能しないことです! ソースに移動する代わりに、メタデータに移動するため、これは本当に残念です。

私たちのように dll 参照を使用し、これら 2 つの問題を何とか克服した人々のアドバイスを求めています。ありがとう。

編集：

「定義の参照」の問題に加えて、プロジェクト参照の代わりに Dll 参照を使用すると、プロジェクト マネージャーに 1 回だけコストがかかることに注意してください。これは、新しいプロジェクトまたは新しい依存関係が追加されたときに、影響を受ける各ソリューションのプロジェクト依存関係を更新することです。導入する必要があります。これらのプロジェクトの依存関係は .sln ファイルに保持され、新しいプロジェクトが到着するか、新しい依存関係が作成されるまで、メンテナンスは必要ありません。これはそれほど頻繁には発生しません。

VS と同じ .sln ファイルを使用する CI サーバーでプロジェクトをビルドするために msbuild を使用しています。すべてのサブプロジェクトを含むメインの .sln ファイルが 1 つあります。

参照が dll 参照であるため、両方のプロジェクトが同じソリューションにあるにもかかわらず、別のプロジェクトの定義を参照できないという、より深刻な問題を強調したいと思います。これは面倒で迷惑です.VSが機能を有効にするためにプロジェクト参照を主張する理由はありません. Resharper や Visual Assist などの他のツールには、この制限はありません。悲しいかな、私たちはこれらのツールを持っておらず、観察可能な将来に持っている可能性は低い.

VS2008 で実行またはデバッグを使用して単体テストを実行すると、VS はテスト プロジェクトのすべての依存関係、つまり単体テストでテストしているプロジェクトを再構築することを要求するのはなぜですか?

変更されていない場合もあります。単体テストの一部を修正しただけです。または、アセンブリの 1 つを変更したのに、すべてのアセンブリを再構築することを主張しているのかもしれません。

単体テスト プロジェクトには、他のプロジェクトへの通常のプロジェクト参照があります。

これにより、可能な限り効果的に TDD を実行する能力が低下しているため、ご提案はありがたく受け取りました。

ありがとう！

[参照]タブを使用してDLLを選択することにより、VisualStudioでCOMdllを参照しようとしています。DLLがunicorn32を使用してシステムに登録されている場合は参照できますが、登録されていない場合は、dllファイル「'file.DLL'への参照を追加できませんでした。」を選択するとエラーが発生します。ファイルにアクセスでき、有効なアセンブリまたはCOMコンポーネントであること。」
DLLを登録しないでおくと、他の開発マシンや開発環境で必要な構成が少なくなります。
質問するのは多すぎますか？
ありがとう！

VisualStudio2008でアプリケーションを作成しています。プロジェクトの出力に含めたいヘルプファイルがあります。ヘルプファイルの最新バージョンを、VisualStudioプロジェクトディレクトリではないフォルダーに残しておく必要があります。たとえば、C：/Helpfilesです。

このファイルをVisualStudioプロジェクトに含めて、プロジェクトをビルドするときに、プロジェクト出力でファイルの最新バージョン（C：/ helpfilesにある）を取得できるようにします。「既存のものを追加」してヘルプファイルを選択すると、ビルドするたびにC：/ helpfilesから最新バージョンが取得されますか？

多くのプロジェクトを含むソリューションの一部として、(<ProjectReference>ソリューション内の他の 3 つのプロジェクトと他のいくつかのプロジェクトを介して) 参照するプロジェクトがあります。でAfterBuild、3 つの特定の依存プロジェクトの出力を別の場所にコピーする必要があります。

さまざまなSOの回答などを介して、それを達成するために私が落ち着いた方法は次のとおりです。

しかし、これで問題が発生しました。<MSBuildステップのタスクは、最終的IncrementalCleanに のいくつかの出力を削除しますProjectC。これを VS2008 で実行すると、build.forceファイルが ProjectC のobj/Debugフォルダーに置かれ、プロジェクトがこのターゲットを含む場合にソリューション全体でビルドを実行すると、ProjectC が再構築されますが、AfterBuildこのプロジェクトをビルドから除外すると、[正しく] は、ProjectC の再構築をトリガーしません (そして、ProjectCのすべての依存関係の再構築は重要です)。これは、この場合、TeamBuild またはその他のコマンドライン MSBuild 呼び出しのコンテキストでは発生しない VS 固有の策略である可能性があります (ただし、最も一般的な使用法は VS 経由であるため、いずれかの方法でこれを解決する必要があります)。

依存プロジェクト (および一般的なソリューションの残りの部分) はすべて VS と対話的に作成されているため、ProjectRefences には相対パスなどが含まれています。これが問題を引き起こす可能性があるという言及を見てきましたが、理由の完全な説明はありません。 、またはいつ修正されるか、またはそれを回避する方法。言い換えれば、ProjectReference.csproj を手動で編集してパスを絶対パスに変換するなどにはあまり興味がありません。

私がばかげたことをしていて、誰かがすぐにそれが何であるかを指摘する可能性は十分にありますが (それは素晴らしいことです)、/v:diag出力などを熟読するのに多くの時間を費やしたことを確認してください (ただし、から再現を構築しようとしたことはありません)ゼロから - これは比較的複雑な全体的なビルドのコンテキストにあります)

次のように TFS Build によってビルドされたプロジェクト参照を使用する大規模な VS ソリューションがあります。

ソリューションが大きすぎるため、日常的に使用するいくつかの小さなソリューションがあります。

問題は、SubSolution に取り組んでいる開発者が、プロジェクト参照が見つからないためにビルドされていないことに気づき、ファイル参照を使用するようにプロジェクトを変更することです。

これにより、これらのファイル参照がまだビルドされていないため (プロジェクトが同じソリューション内にある場合でも)、これらのファイル参照を見つけることができない TFS ビルドが中断されます。この 2 種類の参照の間の綱引きを回避する方法はありますか。ソリューションを分割する正しい方法は何ですか?

VS2010、Silverlight 4、.NET 4には、WCFサービスとSilverlightアプリがあり、Silverlightは、サービス参照の追加ではなく、コントラクトを共有することでクラスにアクセスしています。当然、これは、Silverlightクラスライブラリに契約があり、サービスにそのライブラリへのプロジェクト参照があることを意味します。

不思議なことに、これにより、参照に/！\アイコンが表示され、警告が表示されます。

プロジェクト'SilverlightClassLibrary1'は参照できません。参照されているプロジェクトは、別のフレームワークファミリ（Silverlight）を対象としています

ただし、参照は正常に機能し（Silverlightアプリのインターフェイスを使用できます）、正常にビルドされます。

これはバグですか？警告は嘘をついていて、プロジェクト参照の代わりにアセンブリ参照を追加すると消えてしまうので、私の推測はイエスです。バグを報告しましたが、ここにも詳細があります。