問題タブ [projects-and-solutions]

ソリューションを論理レイヤーに分割する場合、フォルダーごとにグループ化するだけでなく、別のプロジェクトを使用するのが最適なのはいつですか?

前回プロジェクトを開いたときに以前に開いていたすべてのファイルを開かずに、Visual Studio 2008 でプロジェクトを開くことはできますか? 私は作業中に多くのファイルを開いたままにしておく習慣があるため、次にプロジェクトを開くと、(非常にゆっくりと) 開く必要のない一連のファイルがエディターに読み込まれます。設定を検索しましたが、この動作を止めるものは見つかりませんでした。

Visual Studio 2008 で作成されたソリューションを Visual Studio 2005 で開くことができず、回避策 1 を試しましたが、回避策 2 を試していません。

しかし、そのリンクは少し古く、必死になってここで尋ねていたので、利用可能なコンバーターはありますか?

私はまだ VS2008 を持っていないので、vs2008 で行われたオープンソース ソリューションを開きたいと思っていました。

いじくり回すか、vs2008 が出荷されるまで待つ必要があると思います。

私は頻繁に Visual Studio の複数のインスタンスを操作し、多くの場合、同じソリューションの異なるブランチで作業しています。

Visual C++ 6.0 では、現在のソース ファイルのフル パスがタイトル バーに表示されていましたが、Visual Studio 2005 では表示されません。これにより、現在見ているソリューションのブランチを特定するのが少し厄介になります (私が知っている最も簡単な方法は、タブにカーソルを合わせて、ソース ファイルのパスをツールヒントとして表示することです)。

ソリューションまたはファイルのフル パスをタイトル バー、または少なくとも常に表示される場所に取得する方法はありますか?

ソース ファイルを共有する複数のプロジェクトを持つ Visual Studio ソリューションを何度も見てきました。これらの共通のソース ファイルは通常、共通のディレクトリにあり、ソリューション エクスプローラーでは、左下にリンクの矢印が付いたアイコンが表示されます。

ただし、そのプロジェクトのメイン ディレクトリの外部にあるプロジェクトにソース ファイルを追加しようとすると、そのソース ファイルがディレクトリに自動的にコピーされるため、共有コピーがなくなります。

プロジェクト ファイルをテキスト エディターで手動で開き、パスを "../../../Common/Source.cs" のように変更することで、これを回避できることがわかりましたが、これはハックのようなものです。したい。

IDE内からこれを実行できるようにするために変更できる設定または何かがありますか?

この質問に答えた後、MSVS のソリューションとプロジェクトを操作するためのヒントとコツを集めておくとよいと思いました。

ここに私のリストがあります：

• ファイルシステムのガベージを減らすために、新しいプロジェクトを自動的に保存しないようにする方法。

  [ツール] -> [オプション] -> [プロジェクトとソリューション] -> [作成時に新しいプロジェクトを保存] のチェックを外します

• プロジェクトのディレクトリにコピーせずに、共通ファイルを複数のプロジェクトに追加する方法。

  プロジェクトを右クリックし、[追加] -> [既存のアイテム] -> [リンクとして追加] を選択します ([追加] ボタンの小さな矢印を押します)。

• プロジェクトをビルドプロセスに含めずにソリューションに追加する方法

  ソリューションを右クリックし、Add->New solution folderを選択します。
  作成したフォルダを右クリックし、[追加] -> [既存のプロジェクトを追加] を選択します

• Visual Studio からプロジェクト ファイルを編集するには?

  プロジェクトを右クリックしてUnload Projectを選択し、アンロードされたプロジェクトを右クリックしてEditを選択します。または、 Power Commandsをインストールして、[プロジェクト ファイルの編集]を選択します。

• プロジェクト ツリーでファイルをグループ化する方法 (WinForms コントロールの自動生成ファイルなど)

  プロジェクト ファイルを編集用に開きます。

他に追加することはありますか？

何年にもわたって、完全なプロジェクト ビルドを実行するために一連の NAnt スクリプトを作成および調整してきました。メイン スクリプトは、単一のアプリケーション エンドポイント (たとえば、Web アプリケーション プロジェクト) を取り、ソース管理から完全なビルドを行います。スクリプトは、ビルド出力場所、ソース管理アドレスなどに関する必要な情報で事前構成されています。主なポイントは、スクリプトにほとんど情報を供給せず、特定のプロジェクトをゼロから構築できることです。これは、私の質問の「任意」の部分を満たしています。

過去に、いくつかのソフトウェア製品 (主に Web アプリケーション) を作成する会社で働いていました。この環境は、製品ごとにインテグレーターが存在する典型的な継続的インテグレーションのセットアップに非常に適しています。CI ビルドの両方として機能するインテグレーターと、完全なリリース候補ビルドと QA 展開を処理するインテグレーターをセットアップしました。これらのインテグレーターはマスター ビルド スクリプトを使用するため、インテグレーター自体は、ソース管理の監視とマスター NAnt スクリプトの呼び出しにすぎません。

私は現在、多くのアプリケーションを作成する開発グループで働いています。多くの場合、開発者は、最初に他の人が作成したアプリケーションをサポートするよう求められます。私が始めたとき、ビルド管理はありませんでした。私は、1 つのビジネス ユニットの製品スイート (約半ダースの完全なシステム) の 4 人のチームの主任開発者として、グループ内で特にユニークな立場にあります。CI ビルドと RC ビルドの両方を実行するためのマスター ビルド スクリプトを使用して、CruiseControl.Net を実装しました。これは、ビジネスの製品スイート内の固定されたプロジェクトのセットに対して機能します。

私は何年もの間 CCNet を使用してきたので、CCNet で何ができるかを十分に認識しています。製品スイートのすべてのプロジェクトで使用しているため、継続的インテグレーションの分野への貢献に大きな敬意を払っています。私は自分のチームに、開発以外の場所に向けられたもののマスター ビルダーとして、公式の RC ビルド インテグレーターを使用することを強調しました。これにより、CCNet の管理下にあるプロジェクトの固定セットを大幅に管理できます。

ただし、他のアプリケーションを構築している他の開発者もいます。これらのいくつかは、プロジェクトのライフ サイクル (私が変更しようとしている他の何か) に入るまでソース管理さえされないことが多い 1 つの開発者プロジェクトです。これらのプロジェクトの多くは 1 回限りのものであり、デプロイされた後はあまり開発されません。それにもかかわらず、彼らはまだサポートする必要があります。それらをサポートする上で不可欠なのは、これらのプロジェクトの集中ビルド管理がなければ、QA に送られ、最終的には本番用のリリース候補ビルドが個々の開発者マシンで行われることになります。もちろん、これは、開発者のマシン ビルドの他の要因の中で、すべてがソース管理下にあるという保証をまったく提供しません。

私が解決しようとしている問題は、この種の任意のビルドを集中管理するためにどのようなシステムを使用できるかということです。これは間違いなく固有の問題ではありません。ただし、集中型ビルド、ビルドの自動化、および継続的インテグレーションについて私が行った多くの読書では、固定されたプロジェクト/製品と、それらの継続的な開発をサポートするタスクに焦点が当てられています。常に新しいプロジェクトの開発を行っているビジネスでは、どのようなプロセスが使用されていますか? これらのタイプのプロセスを使用していませんか?

マスター ビルド スクリプトはビルド サーバー上に存在しますが、使いにくいです。また、ビルド サーバーへのコンソール アクセスを制限したいと思います。そのため、中央システムで任意のビルドを起動するためのより簡単なアクセスを提供するために、何らかの管理システムが必要です。

私が探しているものは、MS Team Build のカバーの下にある可能性があることに気付きました。残念なことに、MS について読み始めると、MS のマーケティング資料を読み始めると流砂のような気分になり、すぐに道に迷い、自分がやりたいことがそれでできるかどうかを実際に知ることができなくなります。さらに、ライセンス コストは、Team Foundation Server と Team System のトピックに関する過去の一般的な議論で、目立たないものとして取り上げられてきました。

この問題を解決した人からの提案をお待ちしています。私は、マスターの "build-any-project" ビルド スクリプトに基づいた集中型ビルド システムでいくつかの作業を行いました。ただし、私が持っているものはまだ初期段階にあり、主に私が取り組んでいるプロジェクトの種類だけをサポートするように構築されています。現時点では、多くの種類のアプリケーションや、Visual Studio で可能な大量のプロジェクト/ソリューション構成を処理するために必要なサポートが不足しています。

ソリューションユーザーオプションファイル（ソリューションファイルに付随する.suoファイル）の内容を表示するために利用できる無料のツールはありますか？

基本的にファイル内のファイルシステムとしてフォーマットされていることは知っていますが、ソリューションとカスタマイズのどの側面が時間の経過とともに非常に大きくなるのかを把握できるように、内容を表示できるようにしたいと思います。

多数の電子メール (プレーン テキスト) を解析する必要があるシナリオがあります。各電子メールの「種類」は、さまざまなプラットフォームに対して実行されるスクリプトの結果です。タブで区切られているものもあれば、スペースで区切られているものもあれば、まだわからないものもあります。

今後もさらに多くの「フォーマット」をサポートする必要があります。

以下を使用して解決策を探しますか。

• 正規表現
• 単純な文字列検索 (string.IndexOf などを使用)
• レックス/ヤック
• 他の

全体的なソリューションは C# 2.0 (できれば 3.5) で開発されます。

仲間の類人猿とスイレンとパドルホイール！

VS 2008 を使用して、C#/.NET/WPF で Windows デスクトップ アプリを開発しています。このアプリは、Vista および XP マシンにインストールして実行する必要があります。アプリをインストールするセットアップ/Windows インストーラー プロジェクトに取り組んでいます。

私のアプリでは、SQLCE データベース ファイル (.sdf) と、使用しているサードパーティ コントロールに関連するその他のデータベース タイプのファイルへの読み取り/変更/書き込みアクセスが必要です。これらのファイルは、PC 上のすべてのユーザー/ログイン間で共有する必要があり、いずれも管理者である必要はありません。もちろん、これは、ファイルをプログラム自体のインストール ディレクトリに入れることができないことを意味します (Vista が登場する前はよくあることでした)。

解決策は簡単だと思っていました。Vista と XP の両方に、この目的のための共有アプリケーション データ フォルダがあります。(Vista では「\ProgramData」、XP では「\Documents and Settings\All Users\Application Data」。) .NET Environment.GetFolderPath(SpecialFolder.CommonApplicationData) 呼び出しは、特定の PC 上のこれらのフォルダーへのパスを見つけるために存在します。 、 はい！

しかし、Shared-application-data フォルダーを Setup プロジェクトのターゲットとして指定する方法がわかりません。

セットアップ プロジェクトは "Common Files" フォルダーを提供しますが、これは共有プログラム コンポーネント (データ ファイルではない) を対象としており、通常は "\Program Files" の下にあり、"\Program files" の他のフォルダーと同じセキュリティ制限があります。はいはい！

Setup プロジェクトは "User's Application Data" フォルダーを提供しますが、それはユーザーごとのフォルダーであり、まさに私が避けようとしているものです。

VS 2008 セットアップ プロジェクトから、堅牢なクロス Windows バージョンの方法で shared-app-data フォルダーにファイルを追加することは可能ですか? 誰でも方法を教えてもらえますか?