問題タブ [buildconfiguration]

ビルドする前に、プロジェクトの [プロパティ] タブで x86 (または任意の CPU) を選択します。

これらのプロパティを保存し、[プロパティ] タブを再度開くと、プラットフォームとターゲットとして x64 に戻ります。なぜですか?

デバッグ構成とリリース構成を削除し、「開発」と「テスト」を作成して、ソリューションのビルド構成をカスタマイズしました。ローカルではすべて正常にビルドされますが、TFS で新しい構成の 1 つをビルドすると、次のエラー (および同様のエラー) が発生します。

C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets (177): ファイル "bin\CommonServiceFactory.dll" を "C:\MyApp\Binaries_PublishedWebsites\" にコピーできませんEpsi.Web\bin\CommonServiceFactory.dll". パス 'bin\CommonServiceFactory.dll' の一部が見つかりませんでした。

外部依存関係とプロジェクト依存関係の両方でこのエラーが発生しています。私が読んだ投稿から、私が行ったビルド構成の変更に関連しているようです。「デバッグ」構成を使用するように TFS ビルドを設定すると、警告は表示されますが、正常にビルドされます。

C:\MyApp\Sources\MyApp.sln.metaproj: 指定されたソリューション構成 "Debug|Any CPU" は無効です。構成とプラットフォームのプロパティ (MSBuild.exe Solution.sln /p:Configuration=Debug /p:Platform="Any CPU" など) を使用して有効なソリューション構成を指定するか、これらのプロパティを空白のままにして、既定のソリューション構成を使用してください。

どんな助けでも大歓迎です。

MSBuild コマンド:

MSBuild.exe /nologo /noconsolelogger "C:\Builds\2\MyApp\ci.MyApp.acme.com\Sources\MyApp.sln" /m:1 /fl /flp:"logfile=C:\Builds\2\ MyApp\ci.MyApp.acme.com\Sources\MyApp.log;encoding=Unicode;verbosity=diagnostic" /p:SkipInvalidConfigurations=true /p:OutDir="C:\Builds\2\MyApp\ci.MyApp.acme .com\Binaries\" /p:Configuration="Dev" /p:Platform="Any CPU" /p:VCBuildOverride="C:\Builds\2\MyApp\ci.MyApp.acme.com\Sources\MyApp. sln.Any CPU.Dev.vsprops" /dl:WorkflowCentralLogger,"C:\Program Files\Microsoft Team Foundation Server 2010\Tools\Microsoft.TeamFoundation.Build.Server.Logger.dll";"Verbosity=Diagnostic;BuildUri=vstfs ///Build/Build/2603;InformationNodeId=449514;TargetsNotLogged=GetNativeManifest,GetCopyToOutputDirectoryItems,GetTargetPath;TFSUrl=http://tfsServer01:8080/tfs/Core%20Development;"*WorkflowForwardingLogger,"C:\Program Files\Microsoft Team Foundation Server 2010\Tools\Microsoft.TeamFoundation.Build.Server.Logger.dll";"Verbosity=Diagnostic;

これが私のcsprojファイルからの抜粋です：

私がやりたいのは、リリースとデバッグの両方など、複数のビルド構成を含めることprogram_data.dllです。

次のことをやってみました

しかし、VisualStudioはこれを窒息させます。

これを行う方法はありますか、それとも<ProjectReference>ビルド構成ごとに個別にする必要がありますか？

単体テストを使用して新しいプロジェクトを作成する場合、Xcodeはビルド構成をテストスキームのデバッグに設定します（実行スキームの場合も同じです）。

実行（Command-R）スキームとテスト（Command-U）スキームを区別する必要がありますか？

つまり、Testという新しいビルド構成を作成し、それにプリプロセッサマクロTEST = 1を追加して、代わりにTestスキームのビルド構成として使用する必要がありますか？または、実行とテストの両方をデバッグとして保持する必要がありますか？

私はRuby/Railsのバックグラウンドを持っており、通常、テスト、開発、および実稼働環境があります。デバッグは開発のようなもので、リリースは本番のようなものだと私には思えますが、テストが不足しているため、テストを追加するのが理にかなっていると思います。

コメント？意見？提案？

Test用に何かをコンパイルしたいので、私は特にこれを求めています：

これもデバッグ用にコンパイルしても問題ないと思います。だから、私は本当にすることができました：

しかし、私は実際には今のところテストのためにそれをするつもりです。だから、私はデバッグとテストを区別する必要があると思っているのですが、なぜXcodeがデフォルトでそれを行わないのか疑問に思っていますか？Appleはあなたがそれらを区別すべきではないと思いますか？

私の会社には、継続的インテグレーションプラットフォームとしてすでにTeamFoundationServerがあります。ただし、私がセットアップしようとしているのは、開発者が自分の開発マシンで実行できるビルド構成です。

.NET C＃クラスライブラリプロジェクト（これをライブラリプロジェクトと呼びます）を含むVisualStudioソリューションがあるとします。また、ライブラリプロジェクトのユニットテストクラスを含む別のプロジェクトも含まれています（これをテストプロジェクトと呼びます）。

各プロジェクトおよびソリューションレベルで、通常のデバッグおよびリリースビルド構成があります。これらの構成の両方について、ライブラリプロジェクトのみをビルドするように設定しました（したがって、テストプロジェクトはビルドされません）。

私がやりたいのは、DebugWithTestingとReleaseWithTestingという2つの新しいビルド構成をセットアップすることです。それらはそれぞれデバッグおよびリリースと同じになりますが、次の追加機能が必要です。

1. テストプロジェクトを構築します。
2. テストプロジェクトですべてのテストケースを実行します。
3. ライブラリプロジェクトでコード分析を実行します。
4. テストとコード分析のためのレポートを生成します。
5. レポートを特定の場所に保存します。

項目1の実行は簡単です。しかし、項目2から5の方法がわかりません。誰かが私を正しい方向に向けることができますか？

どんな助けでも大歓迎です。TIA

特定のターゲット (すべて/デバッグ) に基づいて、プロジェクト フォルダーのリリース/デバッグ ディレクトリに実行可能ファイルを生成する Makefile があります。アクティブなビルド構成に応じて適切な出力を生成するように、Eclipse-CDT C/C++ ビルド動作メカニズムをセットアップしました。

たとえば、「リリース」ビルド構成は動作として「all」で「make」を呼び出し、リリース/出力ファイルを作成し、「デバッグ」構成はデバッグ/出力でデバッグバージョンを作成します

ここまでは順調ですが、「実行構成」をセットアップする必要がある場合は、バイナリのパスを入力する必要があります (プロジェクトを検索しても何も表示されません)。変数 ${ConfigName} も展開されないため、次のようなものは使用できません。 ${ConfigName}/output をバイナリとして実行/デバッグします。また、「パスとシンボル」/「出力場所」にリリースとデバッグを追加しようとしましたが、どちらも役に立ちません。

そこに相対/絶対パス (たとえば ./release/output) を入力できます。実行をクリックするとバイナリが実行され、デバッグをクリックするとデバッグされます。ただし、パスに依存しているため、デバッグ用とリリース用の 2 つの起動構成が必要です。

問題は、実行構成とデバッグ構成が基本的に同じであり、gdb をカスタマイズするオプションしかないため、非常に混乱することです。デバッグまたはリリースがアクティブであるかどうかに関係なく、4 つの組み合わせのいずれかを実行/デバッグできます。

実際にビルドされたものを実行/デバッグできる方法はありますか? デバッグビルドがアクティブな場合、デバッグビルドを実行/デバッグできますか? 私は、デバッグ ビルドを実行不可にしたり、リリース ビルドをデバッグ不可にしたりすることを制限しているわけではありません。問題は 2 つの起動構成が原因であり、ビルド構成に依存する 1 つだけにする方法が見つかりません。

VS 2010 と TFS 2010 を使用するソリューション間でプロジェクトを共有する際に、多くの問題が発生しています。

最初の問題は、誰もがマシンを異なる方法でセットアップし、ワークスペースを異なる方法で作成することです。すべてのプロジェクトに 1 つのワークスペースを使用するものもあります。プロジェクトごとに異なるワークスペースを使用するものもあります。2 つの異なるプロジェクトをツリーの異なる部分からソリューションに配置する場合、必ずしも TFS ツリー構造にマップするとは限りません (通常はマップしません)。

したがって、ある人は次のようになります。

別の人が持っているかもしれません

別の人もそうします

問題は、ソリューションが物理的なプロジェクトの場所を保持しており、ユーザーが最新のものを入手するたびに、プロジェクトの場所について争ったり、競合を引き起こしたりすることです。

簡単な解決策は単一の構造を義務付けることですが、ここではうまくいきません。

2番目の問題:

プロジェクトである共有ライブラリがいくつかあり、ツリー全体のさまざまなソリューションに含まれています。これらのプロジェクトの中には、ビルド構成が異なるものがあります。1 つは Dev、Test、Stage、Prod で、もう 1 つは Debug、Release、Prod です。

ビルド構成がプロジェクト ファイルに保存されるため、これにより問題が発生します。プロジェクトが共有プロジェクトを使用しようとしていて、共有プロジェクトにソリューションに一致するビルド構成が含まれていない場合、VS がロックされ、あらゆる種類の奇妙な動作が発生します。

これらの問題に対する解決策はありますか？すべてのユーザーに影響しない場所のローカル オーバーライドを作成する方法はありますか? (ユーザーごとに Web サーバー構成を設定する方法と同様)

これらの問題は、今までに把握されているはずです。

どのシナリオに関するビルド構成でどのコード署名 ID を使用する必要があるかについて、私は決して明確ではありません。誰かが最も簡単な方法でそれを説明できれば幸いです。

これは私が知っていることです：

1. プロビジョニング ポータルで作成し、開発プロファイルと配布プロファイルの両方をアプリに実装します。

2. 次に、さまざまなプロファイルに従って 、プロジェクト >> ビルド設定 >> コード署名を割り当てます。

これが最初の質問です: ReleaseとDistributionの違いは何ですか? どちらを開発者プロファイルに接続し、どちらを配布プロファイルに接続する必要がありますか?

3. さて、私が正しく理解していれば、アプリを実行する前に「スキーム」を設定することになっています:

Code Signing Identityのいずれかを選択してビルド構成を定義する必要がある 5 つの異なる手順があります。

これが大きな問題です...どのシナリオで、どのコードサイニングIDを選択する必要がありますか?

私は常に同じ 2 つのデバイス (iPhone と iPad) でアプリを実行しています。どちらもプロビジョニング ポータルで定義され、プロファイルに設定されます。シミュレーターとデバイスでのテスト、および後でApp Storeにアップロードするためのアプリをビルドするために問題なく実行できることを確認したいだけです。

どんな支援/指示も大歓迎です。

昔々、プロジェクト用に「DEV」構成と「Web.DEV.config」変換ファイルがありました。次に、その特定の構成を削除しました...

…また欲しくなる。問題は、構成を追加してから構成変換をプロジェクトに追加しようとすると、次の Visual Studio の苦情が表示されることです。

プロジェクトの物理ディレクトリを確認しましたが、そのようなファイルはありません。ソリューション全体で「Web.DEV.config」を検索しましたが、結果は 0 です。今日、Visual Studio が私の生産性を殺そうとしているのはなぜでしょうか?

ビルド構成が異なる VS2010 ソリューションがあります。特定のビルド構成に特定の単体テスト プロジェクトを含めて、特定の構成で作業しているときに関連する単体テスト プロジェクトのみを実行できるようにしました。

これはうまく機能します。（最後に）

ただし、このソリューションには負荷テスト プロジェクトとパフォーマンス テスト プロジェクトもあります。これらは両方とも、ビルド構成に関係なく、また、一般的なデバッグ構成以外のすべてからそれらを削除するために全力を尽くしたという事実に関係なく、テスト ビューアーに表示されます。

特定のビルド構成の実行可能なテストリストからこれらの種類のプロジェクトを削除する方法を知っている人はいますか...信じられないかもしれませんが...すべてのテストを実行することを選択するたびに負荷テストを実行したくありません!

ご協力ありがとうございます