17

Visual Studioを使用してUnix用のアプリケーションを開発しようとして共有するバトルストーリーはありますか?そして、その下で実行されているMonoまたはWine仮想プラットフォームで.NETを使用することについて話しているのではありません。

当社には約20人の開発者がおり、全員がWindows XP / Vistaを実行しており、主にLinuxとSolaris向けに開発しています。最近まで、私たちはすべてメインのLinuxサーバーにログインし、古き良き方法でコードを変更/構築しました:Emacs、Vi、dtpad-選択してください。それから誰かが「ねえ、私たちは暗黒時代に住んでいるので、IDEを使うべきだ」と言いました。

そこで、いくつか試してみて、パフォーマンスのニーズを満たすのはVisual Studioだけであると判断しました(はい、IDE Xは非常に優れたIDEであると確信していますが、VSを選択しました)。

問題は、ファイルをVSでローカルに使用できるだけでなく、ビルドサーバーでも使用できるように環境をどのように設定するかです。Visual Studioプラグインを作成することにしました。[保存]をクリックするたびにファイルがローカルにビルドサーバーに書き込まれ、サーバー側でファイルが変更されたときに押すことができる少し太い[同期]ボタンがあります(ソース管理サーバーから最新のファイルに更新します)。

プラグインは、Visual Studioの外部ビルドシステム機能も使用します。この機能は、最終的にビルドサーバーにSSHで接続し、ローカルの「make」ユーティリティ(Boost Build v2)を呼び出します。依存関係のチェックは優れていますが結果として起動が非常に遅くなります。開始するのに60秒)。結果はVisualStudioにパイプで戻されるため、開発者はエラーをクリックして適切なコード行に移動できます(実際にはかなり滑らかです)。ビルドサーバーはGCCを使用し、すべてのSolarisビルドをクロスコンパイルします。

しかし、これをすべて行った後でも、VisualStudioでコードを書き始めるたびにため息をつくしかありません。ファイルをクリックして入力を開始すると、VSが追いつきます。

ツールを停止して待つことよりも厄介なことはありますか?メリットは欲求不満の価値がありますか?

考え、物語、助け?

4

13 に答える 13

7

私に追いつくためにVS一気飲み。
うーん...マシンにはより多くのメモリとうなり声が必要です。私のパフォーマンスの問題は一度もありませんでした。

私はあなたが提案していることを正確に実行してきた約 10 年の経験があります。そのほとんどは金融業界で、銀行、証券取引所、証券会社のニッチ市場の顧客向けにリアルタイム システムを開発しています。

先に進む前に、これはすべて VS6 + CVS、そして最近では SVN で行われたことを告白する必要があります。

ソースコードのバージョン管理

開発者は、自分の作業を保存し、論理的なマイルストーンで作業のパッケージをチェックできるように、個別の sourcesafe リポジトリを持っています。彼らが統合テストを行いたいと感じたら、それを SVN にチェックインするスクリプトを実行します。

SVN にチェックインすると、関連するメイクファイルを自動的に生成してターゲット マシン上でコンパイルし、継続的インテグレーションを行うプロセスが開始されます。

SVN から VS が管理するフォルダーに新しいものを同期するスクリプトの別のセットがあります。VS は新しいファイルを自動的に取得できないため、少しギャップがあります。通常は手動で処理します。これは、プロジェクトの最初の数日間だけ定期的に発生します。

これは、コードを維持する方法の概要です。私は言わざるを得ませんが、私はおそらくいくつかの詳細を見逃しています (興味がある場合はお知らせください)。

コーディング

コーディングの面では、プリプロセッサ (#define など) と makefile のフラグに大きく依存して、コンパイル プロセスを形成しています。クロスプラットフォームの移植性のために、GCC を使用します。何度か、HP-UX やその他のコンパイラで aCC の使用を余儀なくされましたが、大きな不満はありませんでした。プラットフォーム全体のスレッド ヒープ スペースに注意する必要があったことだけが、常に苦痛でした。コンパイラはそれを惜しみません。

なんで?

よくある質問は、「なぜ、このような複雑な開発方法を採用する必要があるのか​​」ということです。通常、私たちの答えは、「コア ダンプを調べたり、gdb を使用したりしてマルチスレッド アプリケーションをデバッグすることがどれほど常軌を逸しているのか、何か手がかりはありますか?」という別の質問です。基本的に、あいまいなバグをデバッグしているときに、コードの各行をトレース/ステップスルーできるという事実は、努力する価値があります!

さらに!... VS のインテリセンス機能により、クラスに属するメソッド/属性を簡単に見つけることができます。また、VS2008 にはリファクタリング機能があると聞きました。私は、両方の機能を備えた Java on Eclipse に焦点を移しました。ビジネス ロジックのコーディングに集中する方が生産性が高くなります

また!... Windows と Linux の両方で動作する製品ができあがる!

幸運を!

于 2008-10-17T06:49:44.970 に答える
3

あなたの痛みが分かります。「クロスプラットフォーム」のアプリケーションがあります。クライアントがWindowsおよびLinuxで実行できる必要がある典型的なクライアント/サーバーアプリケーション。私たちのクライアントベースは主にWindowsを使用しているため、VS2008を使用して作業します(デバッガーを使用すると作業がはるかに簡単になります)。ただし、Linuxビルドを実行する必要があります。

これに関する主な問題は、gccでビルドされるとは知らなかったコードをチェックインしていたことでした。これにより、セットアップしたCIのものが破損する可能性が高くなります。そこで、開発者のすべてのマシンにMingGWをインストールしました。これにより、作業コピーがリポジトリにコミットする前にgccでビルドされることをテストできます。

于 2008-08-19T03:58:22.873 に答える
2

MacとPC向けに開発しています。私たちは、ほとんどがVSだけでなく、xcodeも含め、好みのideでローカルに作業します。ビルドサーバーに対して変更が十分に安定していると感じたら、チェックインします。2つのビルドサーバー(MacとPC)は、ソース管理チェックインを探し、それぞれがビルドを実行します。ビルドエラーはチームにメールで返送されます。

ビルドサーバー上でライブファイルを編集することは、私には不安定に聞こえます。別の開発者がビルドしない編集を行っているときにビルドをリクエストするとどうなりますか?

于 2008-10-17T07:57:46.050 に答える
2

これがあなたの質問に実際に答えているわけではないことはわかっていますが、リモート X セッションのセットアップを検討し、KDevelopのようなものを実行することをお勧めします。これは、ちなみに、非常に優れた IDE であり、さらにはEclipseです。主流であり、より広い開発者ベースを持っています。おそらく、 Xmingのようなものを Windows マシンの X サーバーとして使用できます。

于 2008-11-10T19:51:38.773 に答える
1

うわー、それはVisualStudioの本当に奇妙な使用法のように聞こえます。私はvimで離れてとても幸せです。ただし、VisualStudioで気に入っているのはデバッガーです。使っていないようですね。

質問を開いたとき、Visual Studioでのポータブルアプリケーションの開発と、それらのSolarisへの移行について言及しているに違いないと思いました。私はこれを行い、それで楽しい経験をしました。

于 2008-08-19T03:24:23.677 に答える
1

ネットワーク共有。

もちろん、ネットワーク上でキラーラグが発生しますが、少なくともファイルのコピーは1つだけです。

私が両方のプラットフォームで開発していたときに私がしたことを聞きたくありません。ただし、次のことを行います。1日に数回ドラッグアンドドロップコピーします。ローカルでビルドして実行し、Unixで定期的にチェックして、gccが満足していることと、そのプラットフォームでも単体テストが満足していることを確認します。そこには実際には急速なターンアラウンドサイクルではありません。

于 2008-08-19T04:20:08.370 に答える
1

@monjardin

私たちがそれを使用する主な理由は、Visual Assist X (by Whole Tomato) を通じて提供されるリファクタリング/検索ツールのためです。他にも Intelli-sense のような便利な機能がいくつかあります。また、環境を完成させるために、他のツールである AccuRev、Bugzilla、および Totalview との統合も調査しています。

@ルー

複数のコンパイラを使用するのは面倒に思えます。すべてのプラットフォームで gcc を使用するという贅沢があります。

@ジョシュ

うわぁ!これは、エラーを導入するための優れた方法のように思えます。:-)

于 2008-08-19T14:10:22.513 に答える
1

私のプログラミング経験のほとんどは Windows であり、私はビジュアル スタジオの大ファンです (特に、たまたま C# コーディングを行っている場合は Resharper を使用します)。最近、私は C++ で Linux 用のアプリケーションを書いています。すべての IDE (Netbeans、KDevelop、Eclipse CDT など) を試した後、Netbeans が最も安っぽくないことがわかりました。私にとって絶対的な最小要件は、コードをシングルステップ実行できることと、理想的にはいくつかのリファクタリング機能も備えたインテリセンスを持っていることです。今日の Linux IDE が 10 年以上前の Visual Studio 6 の状態にさえ近づいていないことは、私にとって驚くべきことです。現在の最大の問題点は、Netbeans のインテリセンスの実装がいかに遅く、不十分であるかということです。8 GB の RAM を搭載した高速なマシンでデータを取り込むには 2 ~ 3 秒かかります。Eclipse CDT のインテリセンスは、さらに遅延が大きくなりました。申し訳ありません、

だから今、私の唯一のビルドターゲットはLinuxですが、WindowsからVSを使用することを検討しています...

Chris さん、すべての主要なソース管理システム (svn、tfs、sourcesafe など) と統合されている無料の自動化ビルド サーバー 'CruiseControl' を調べてみてください。その全体的な目的は、ソース管理システムでのチェックインに対応することです。一般に、誰かがコードをチェックインするたびにビルドが開始され、(理想的には) 単体テストが実行されるように構成します。一部の言語では、コード分析を行ったり、単体テスト コード カバレッジを測定したりする優れたプラグインがいくつかあります。ビルドの成功/失敗に関する通知がチームに送り返されます。これを C++ 用にセットアップする方法を説明した投稿があります: link (thoughtworks.org)

Linux のみの単純な構成 (Netbeans + SVN、ビルド自動化なし) から、Linux でのビルドに加えて単体テストを実行するビルド自動化バックエンドを備えた Windows VS 2008 の使用への変換を始めたところです。すべての構成を完了するのに時間がかかることに身震いしますが、早ければ早いほどよいと思います。

私の理想的な最終状態では、VS プロジェクトから Netbeans プロジェクト ファイルを自動生成できるため、Linux で何かをデバッグする必要がある場合は、その IDE から実行できます。VS プロジェクト ファイルは XML ベースなので、それほど難しくありません。

誰かがこれについての指針を持っていれば、本当に感謝しています。

ありがとう、

クリストフ

于 2009-04-01T18:03:34.503 に答える
1

cygwinで gcc を使用して、Visual Studio で Playstation2 コードを開発した経験があります。gcc と glibc を備えた cygwin を使用している場合、ターゲット環境とほぼ同じになるはずです。Solaris と Linux の間で移植可能でなければならないという事実は、cygwin が問題なく動作することを示唆しています。

于 2008-11-10T20:02:04.103 に答える
1

開発者をプライベート ブランチで作業させることもできます (DVCS を使用している場合は簡単です)。次に、コードをチェックインする場合は、[windows|unix] のプライベート ブランチにチェックインし、[unix|windows] でサンドボックスを更新し、メイン ブランチにコミットする前にビルド/テストします。

于 2009-08-31T21:44:39.423 に答える
0

私たちはあなたが説明したものと同様のソリューションを使用しています。

コードは世界のWindows側に保存されており、UNIX(正確にはQNX 4.25)はNFSマウントを介してアクセスできます(Windows用のUNIXサービスのおかげです)。makeを実行するためのUNIXへのsshと、VSに出力するためのパイプがあります。コードへのアクセスは高速で、ビルドは以前より少し遅くなりますが、現在、最長のコンパイルは2分未満であり、大したことではありません。

VS for UNIX開発を使用することは、IntelliSenseを使用できるようになったため、セットアップする価値があります。タイピングが少ない=開発者は幸せです。

于 2008-08-19T04:08:02.667 に答える
0

仕事で全く同じことをしています。私が使用するセットアップは、Windows 開発用の VS であり、Linux VM はローカル ビルド/実行検証用に VirtualBox で実行されます。VirtualBoxには、ホストOS(私の場合はWindows 7)上のフォルダーをゲスト(私の場合はUbuntu LTS 12.04)でマウント可能なファイルシステムとして利用できるようにする機能があります。そうすれば、VS ビルドを開始してファイルを保存した後、すぐに Linux で make を開始して、ビルドが正常に実行されることを確認できます。

ソース管理には SVN を使用します。最終的なターゲットは Linux マシン (ゲーム サーバー) であるため、ローカルの Linux ビルドと同じ makefile を使用します。そうすれば、プロジェクトにファイルを追加する/コンパイラ オプションを変更する、通常は -D を追加/変更する場合、最初に VS で変更を行い、すぐに Linus メイクファイルを変更して同じ変更を反映させます。次に、コミットすると、ビルド システム (Bamboo) が変更を取得し、独自の検証ビルドを行います。

苦労して得た経験によると、初日からこのように構築すれば、これは桁違いに簡単です。

私が最初に取り組んだプロジェクトは Windows のみで始まりました。私はそれを Linux に移植するために雇われました。彼らは同種のサーバー環境に切り替えたいと考えており、それ以外はすべて Linux でした。Windows プロジェクトをこの種のセットアップに改造することは、かなりの労力を費やしました。

プロジェクト番号 2 は、初日から「2 つのシステム ビルド」が行われました。VS は非常に洗練された IDE であるため、開発 / デバッグに VS を使用する機能を維持したかったのですが、Linux サーバーへの最終的なデプロイも必要でした。上でほのめかしたように、プロジェクトが最初からこれを念頭に置いて構築されたとき、それは非常に簡単でした. 最悪の部分は単一のファイルでした: OS 固有のルーチンを含む system_os.cpp、「Linux エポック開始からの現在の時刻をミリ秒単位で取得する」など。

少し話が逸れますが、これに対する単体テストも作成しました。OS 固有の部分の単体テストを行うことで、両方のプラットフォームで同じように機能するという大きな確信が得られました。

于 2014-09-14T04:29:36.033 に答える
0

"Final Builder" ( http://www.finalbuilder.com/ ) をチェックしてください。バージョン管理システム (cvs や svn など。正直なところ、この特定のユース ケースには cvs の方が適しています) を選択し、FinalBuilder でビルド トリガーを設定して、チェックインによってコンパイルが行われ、結果が返されるようにします。 .

FinalBuilder でルールセットを設定して、壊れたコードをベースラインまたは特定のブランチ フォルダーにチェックイン/マージすることを防止できますが、他のフォルダーには許可します (/baseline または /branches/* への壊れたコミットは許可されませんが、/壊れている可能性のあるコードを共有する必要がある開発者や、一日の終わりにコミットできるようにしたい開発者向けの wip/ branching フォルダー)。

1 つのボックスで 20 人がビルドしようとしたり、1 つのボックスがすべての小さなコミットを処理するのを待ったりしないように、FB を複数の「ビルド サーバー」に分散させることができます。

私たちのプロジェクトには、Mac クライアントと Windows クライアントを備えた Linux ベースのサーバーがあり、すべて共通のコードベースを共有しています。このセットアップは、私たちにとって途方もなくうまく機能します。

于 2010-01-24T01:43:45.750 に答える