問題タブ [visual-studio-shell]

WPF アプリケーションの UI スキャフォールディングとして Visual Studio 分離シェルを使用する可能性を探っています。アプリケーションには、カスタムの「ドキュメント」ウィンドウと、追加情報を表示するために使用される多くのサイド ツール ウィンドウが含まれます。ツール ウィンドウとドキュメント ウィンドウをメイン コントローラーで制御するか、相互に簡単に通信できるようにする必要があります。

VS 分離シェルに関するドキュメントは非常に少なく、例もさらに少ないです。したがって、VS 分離シェルを使用してカスタム アプリまたは IDE を開発した経験のある人が、これを手伝ってくれることを願っています。

VS 分離シェルを UI スキャフォールディングの目的だけに使用することは可能ですか? もしそうなら、Visual Studio から継承されたすべての機能を本質的に消去し、メニュー バーからドキュメント ページまですべてをカスタマイズするにはどうすればよいでしょうか? それとも、AvalonDocks などの他の UI スキャフォールディング ライブラリを使用する方がよいでしょうか? VS シェルを使用する利点は、はるかに安定しており、必要に応じてカスタム ツール ウィンドウとして Visual Studio に簡単に移植できることです。

とても有難い！

バッチスクリプトから、Visual Studio Shellがインストールされているかどうか、およびどのバージョンがインストールされているかを確認するにはどうすればよいですか？

ファイル/フォルダの存在を確認できることを理解しています。

しかし、私はよりエレガントで一般的な解決策を探しています。

何か助けはありますか？

受け入れられた回答への更新：

あなたの答えはエレガントで、仕事をします。私は特定のバージョンを具体的にチェックしていたので、（あなたが提供したリンクをチェックした後）使用しています：

Shell は Express、Professional などと同じように Visual Studio のエディションですか?

マシンに VS2010 Shell をインストールしましたが、多くのプロジェクトを開くことができませんでした。誰でも助けてください。このエディションについて頭を下げたことはありません。

私たちはまだ C++ 開発に VS2005 を使用しています (アップグレードが計画されています!) 問題は、TFS で動作するように VS2010 シェルもインストールされていることです。.SLN ファイルをダブルクリックすると VS2005 は正しく起動しますが、.vcproj ファイルをダブルクリックすると VS2010 が起動しますが、これはシェルのみであるため、プロジェクトを開く方法がありません!

ここには特別なランチャー バージョンのツールが含まれていることは理解しています。

Visual Studio 2010 を開こうとすると、Windows Server 2008 R2 Enterprise SP1 を実行している VPS でタイトルにエラー メッセージが表示されます。SQL Server 2012 と VS 2013 をインストールした後でも、最初は問題なく動作していました。

これを解決しようとして、SysWOW64 フォルダー内の msvcp100、msvcp100d、msvcr100、msvcr100d、および msvcr100_clr0400 DLL の 32 ビット バージョンが何らかの形で 64 ビット バージョンで上書きされたと述べている、この問題を抱えている他の人を見つけました。そのため、32ビット版をダウンロードして、うまく置き換えられませんでした。また、system32 フォルダー内のバージョンも削除しました。これもうまくいかなかったので、元に戻しました。

また、Visual Studio 2010 の完全なクリーン アンインストールを実行してから、VS 2010 Shell Integrated を再インストールしました。Visual Studio はまだ起動せず、同じエラーが発生します。

誰でもこの問題を解決するのを手伝ってもらえますか? DLL に問題がある場合、問題の原因となっている DLL を正確に絞り込むのに役立つツールを知っている人はいますか?

どんな助けでも大歓迎です。ありがとう！！！

最近、コード ウィンドウに透かしを指定できる Visual Studio の拡張機能を発見しました。この拡張機能は、こちらの github にあります。

https://github.com/nategreenwood/VSEditorBackgroundChangerExtension

小さなプロジェクトの一環として、SQL Server Management Studio で動作するようにしようとしています。Microsoft は SSMS の拡張を公式にはサポートしていませんが、推奨していません。それは彼らの言葉であり、私のものではありません。

SQL Server 2014 の SSMS の下にある extension\application サブフォルダーを見ると、Microsoft が VSPackage を使用して、SSMS が構築されている Visual Studio の分離シェル バージョンに独自の拡張機能を組み込んでいることは明らかです。ただし、マニフェストはバージョン 1 マニフェストのようです。

これらは、私のボックスの次の場所に表示されます: C:\Program Files (x86)\Microsoft SQL Server\120\Tools\Binn\ManagementStudio\Extensions\Application

この拡張機能を SSMS で動作するように変更できるかどうかを確認するための支援を探しています。バージョン 1 スタイルのパッケージおよびマニフェストとしてパッケージを書き直すなど、さまざまな方法でパッケージ マニフェストを変更しました。VSIX が生成する pkgdef GUID の下にパッケージが登録されていることがわかります。設置されているとのことです。エラー メッセージはスローされませんが、画像も表示されません。

分離シェル、具体的には SSMS が TSQL を開発および実行するために使用するコード ウィンドウは、このパッケージで使用されているような装飾をサポートしていますか? SSMS はバージョン 2 のマニフェストと VSPackage をサポートしていますか?

このパッケージを動作させるための変更方法に関するアドバイスをいただければ幸いです。

私自身の試みは、ここにさらに文書化されています： http://sqljudo.wordpress.com/31-days-of-ssms/ssms-day-30-vspackage-and-ssms/

どういうわけか、プロジェクトでソース管理バインディングが混同され、ローカル ファイルをサーバー上の正しい場所にバインドしようとしています。最初にプロジェクトのバインドを解除しようとしていますが、バインドを新たに設定して「ソリューションをソース管理に追加」しようとすると、「ソース管理に追加しようとしているプロジェクト PDAClient.csdproj を追加できません。項目 AppSettings.cs は、選択した場所で既にソース管理下にあるため、 "

AppSettings.csがアルファベット順で最初のファイルであるため、問題のあるファイルとしてAppSettings.csのみを選択したようです。これは、プロジェクトから一時的に削除して再試行したため、同じように次のアルファ オーダーのファイルについて不平を言ったからだと思います。

TFSの裏をかくために、「MSSCCPRJ.SCC」の名前を「MSSCCPRJ.SCCHide」に変更し、「PDAClient.vssscc」の名前を「PDAClient.vsssccHide」に変更しましたが、単に新しい「PDAClient.vssscc」を作成しました

(PDAClient はソリューションとプロジェクトの名前です)

VS 2003 File > Source Control > Change Source Controlから試すと、次のように表示されます。

次に、ソリューションの [バインド] を選択してから、その名を冠したプロジェクトを選択すると、次のように表示されます。

[参照] または [サーバー バインド] 列の省略記号ボタンをクリックすると、「点滅」するだけで、接続を確立するためのダイアログが開きません。

したがって、ソリューションのバインディングは「無効」ですが、プロジェクトのバインディングはおそらく有効です...

次に「OK」を選択すると、次のようになります。

...これは有望に見えますが (「はい! バインディングを修正してください!」)、「修正」ボタンを選択すると、何もせずに [ソース管理の変更] ダイアログに戻るだけです。だから私は最後に、しぶしぶ、「既存のバインディングを続行する」という他のオプションを選択し、次のことを確認します。

わかりました...それを機能させるにはプロジェクトをチェックインする必要があることがわかり、続行しようとしましたが、次のように表示されます。

Handheld/Development/Development/HHS に接続しようとしていることに注意してください。DEV は別のブランチです。これはリリース ブランチです。上記のソリューションのスクリームショットで、Path プロパティ (C:\Project\sscs\Handheld\Release (など) に設定) ではなく ...Development...(など) であることがわかります。 -in ツールを実行すると、サーバー バージョンが Dev ブランチ (目的のリリース ブランチではなく) からのものであり、ローカル バージョンが使用されていることがわかりました。しかし、私は得ました：

その後、プロジェクトのファイルの一部がチェックアウトされていることがわかったので、これでうまくいくのではないかと思いました。メソッド名を変更してテストしたところ、「チェックアウト中にエラーまたはユーザーのキャンセルが発生しました。一部のファイルがチェックアウトされていない可能性があります。(ファイルがチェックアウトされていませんでした。)」と出て、続いて、「影響を受けるファイルの一部を書き込み可能にできなかったため、リファクタリングを実行できませんでした」...そして、私の変更は自動的に取り消されました。

このプロジェクトに変更を加える必要があるため、明らかにこれは機能しません。

[ファイル] > [ソース管理] メニューに残っているものをいじくり回し、 [ソース管理からプロジェクトを追加...] を選択して、何が提供されるかを確認しました。まず、TFS に接続するためのダイアログが表示されます。やった。サーバー上の適切な場所に移動しましたが、これは問題なく、すぐに使用できます。

[OK] を選択すると、「ソリューションを保存するために選択したローカル フォルダーには、ソース管理サーバー フォルダー内のファイルと同じ名前のソリューション ファイルが 1 つ以上含まれています。」というダイアログが表示され、[上書き]、[キャンセル]、および [ヘルプ] ボタンが表示されます。

[上書き] を選択します。次に、ダイアログが表示されます。

PDAClient.sln を選択します (HHS はソリューション/プロジェクトの以前の名前でした)

ただし、その後 [開く] ボタンを選択すると、「フォルダー 'C:\Project\sscs\Handheld\Releases\6-4-0\HHS' は、既に使用されているため、ソリューションまたはプロジェクトには使用できません。別のソリューションまたはプロジェクトの一部を保存します。」

やむを得ず「OK」を選択するしかありません。

Any-Port-in-a-Stormism Syndrome の最終的な首から先の首輪を壊す可能性のある偉業として、[ File] > [Source Control] > [Team Foundation Server MSSCCI Provider]を選択します。これにより、XP モード内の VS 2003 内で Kafka 風の Windows 2010 シェルが呼び出されます。そこに表示される内容によると、セットアップは正しいです。Release プロジェクトのサーバーのコピーは、ローカル ファイルの Release フォルダーにバインドされています。

ただし、\Releases\HHS はグレー表示されており、サーバー フォルダーとローカル フォルダーの間に接続がないことを示しています。そして、Release セットアップ内のファイルのほとんど (すべてではありませんが、ほとんど) は、実際には Development フォルダーにローカルに保存されていることに注意してください。正しくバインドされている主要なファイルがいくつかあります。

すべての (数十の) 目に見えないファイル (最後の 2 つのスクリーンショットでは最初と最後のファイルのみが表示されています) も開発に関連付けられています。

\Releases\HHS の「バインド」タイプのコンテキスト メニュー項目はありませんが、「マップ ローカル」があります。表向きは既に正しくマップされていますが、試してみましたが、「ローカル フォルダーを C:\Project\sscs\Handheld\Releases\6-4-0\HHS に設定できませんでした。これは、既にローカル フォルダーであるためです。別のサーバー フォルダ。」

そこで、「有効な」バインディングを持つ\Development\HHS に移動します。繰り返しますが、間違ったローカル パス (Dev ではなく Releases) にバインドされていることに注意してください。

そのため、まずコンテキスト メニューの [マッピングの削除] を選択します。これにより、「ワークスペース マッピングを編集または削除する」機会が与えられます。ローカル フォルダーを Releases から Dev に変更します。よさそうです。Dev は Dev にバインドされ、バインディングは引き続き有効と見なされます。今回は本当にそうです（とにかく願っています）。

ここでリリースに注意を戻しますが、「マップ ローカル」というコンテキスト アイテムはもうありません...そして、サーバーの場所とローカルの間の正しい接続を示していますが、まだグレー表示されています...???

注: ファイルの「保留中の変更」リストは、強調表示された \Development\HHS と \Releases\HHS の両方と同じです。両方のケースで同じ 3 つのファイルがローカルの Releases フォルダーにあり、その他すべてがローカルの Dev フォルダーにあるように表示されます。フォルダ。

VS 2003 (TFS MSSCCI プロバイダーを実行している VS 2010 シェルの外) に戻り、[ソース管理の変更] に移動すると、ソリューションとプロジェクトの両方のステータスが [有効] になっていることがわかります...「 OK」ですが、多くのファイルが一致しないことがわかり、管理者に連絡するか、すべてを取得することで解決する可能性があります。暫定的に Select All を調べてみましたが、私のプロジェクトは Development にバインドされているとまだ表示されています。あぁぁぁぁぁぁぁぁぁぁぁぁぁぁ！！！

誰もこの狂気から抜け出すことができますか? ブリードオーバーや不一致なしで、Release ローカル フォルダーを指す Release サーバー フォルダーと Dev ローカル フォルダーを指す Dev サーバー フォルダーを取得するにはどうすればよいですか?

アップデート

今朝もソース管理エクスプローラー (TFS MSSCCI) を調べたところ、Dev\HHS が再び間違ったローカル パス (リリース) に設定され、接続されていました (それが、直面している -each- のグリフだと思います)。フォルダの左側にあるその他の垂直矢印が示す)。

Releases\HHS に関しては、接続されていませんでしたが (グリフなし)、右クリックして、セットアップした新しいフォルダーにマップすることができました。

これが私が今見ているものです（DEVのマッピングをローカルのリリースフォルダーからローカルのDEVフォルダーに再度変更した後です！）。

Dev HHS のプロパティ:

リリース HHS のプロパティ:

これがあなたにとって意味があるかどうかはわかりませんが、私には怪しいように見えます。

更新 2

狂気は今日も衰えない。私のソリューションは、2 つの保留中のチェックインがあると主張しています。

「チェックイン」を選択すると、確認ダイアログが表示されます。そこで「チェックイン」ボタンを押します。次に、[チェックイン - ソース ファイル] ダイアログが表示されます。そこでも「チェックイン」ボタンを選択します。しかし、「ファイルがチェックアウトされていません」と表示されます

上記の操作を繰り返すと、最後のメッセージは次のようになります。

???

IMO、最新の変更を保存したいときに、この面倒な獣を使用するのではなく、ファイルを圧縮するだけで多くの時間を節約できたでしょう。私は、より単純なアプローチを使用するよりも、「生産性」ツールをいじることに多くの時間を費やしています。この打ち砕かれた希望と巧妙で巧妙な汚いトリックの大釜に対する zip ファイルと優れた diff ユーティリティをください!

更新 3

プロジェクトを閉じて再度開くと、次のメッセージが 3 回続けて表示されます。

では、青い炎の中で誰がそのようなサーバーを見つけるようにあなたに言いましたか?!?!

それから私は得る：

そして最後にこれをもう一度：

ぐぐぐぐぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁ！！！！！！！！！！！！！！！！！！

更新 4

ソリューションとプロジェクトのパスが正しい (リリース) 場合でも、プロジェクト内のファイルは次のように表示されます。

更新に示すように、[ブランチ] タブには、Dev が Release に進むことが示されています。それが正しいかどうかはわかりませんが、Release は Dev のブランチだったので、

また...？？？

とにかく、ファイル>ソース管理>チームファンデーションのプロパティから上記を参照してください

ただし、[ファイル] > [ソース管理] > [Team Foundation Server MSSCCI プロバイダー] を選択すると、バインドが正しいように見えます。HHS Dev プロジェクトにはローカル フォルダーの場所として Dev があり、HHS Release プロジェクトにはローカルの場所として Release フォルダーがあります。

誰がもっと混乱しているのかわかりません。私、たまたまこれを読んだ人、または TFS/MSSCCI 自体です。この種のことは、皮肉なことに、生産性を著しく低下させます。