Visual Studioプロジェクトをネットワークドライブに保持する
すべてのファイルをローカルに保存することから、ネットワークドライブに移動しました。問題は、私のVSプロジェクトが現在保存されている場所です。 （バージョン管理システムはまだありません。これに取り組んでいます。）過去にこれを行う際の問題を聞いたことがありますが、回避策を聞いたことはありません。回避策はありますか？
したがって、私のVSはローカルにインストールされます。ファイルはネットワークドライブ上にあります。これを機能させるにはどうすればよいですか？
編集：私は何をすべきか知っていますが、これを修正してネットワークドライブを維持するために今すぐ着ることができるバンドエイドはありますか？
編集2：私は何かを理解していないと確信していますが、 ボブキング は正しい考えを持っています。リードWeb開発者がオフィスに戻ってきたら、何らかのバージョン管理の設定ができるまで一時的な解決策を見つけます。アイデアをありがとう。
ソース管理を使用している間、ネットワークドライブ（共有ディレクトリ、ネットワークドライブ上のプライベートディレクトリではない）からすべてのプロジェクトを実行します。ネットワークドライブは毎晩バックアップされ、ボリュームシャドウコピーも使用するため、何かbeforeに戻す必要がある場合は、SCに進みます。あなたはできる。
適切な権限でプロジェクトを正しく実行するには、 これらの手順 に従ってください。
基本的に、共有ディレクトリをドライブにマップし、そのURLに基づいてすべてのコードにアクセス許可を付与する必要があります。 「N：\」にマッピングした後、「N：\ *」をURLパターンとして使用するとします。ワイルドカードを使用する必要があるかどうかは明らかではありませんが、必要です。
質問はかなり一般的なので、私が直面していた1つの問題に対する答えを示します。
Mac上でParallels仮想マシンを使用してVisual Studio 2010を実行し、ネットワーク共有を介してすべてのプロジェクトをMac側に保持します。ただし、Visual Studioはそこからプロジェクトのアセンブリファイルを読み込みません。 「caspol」だけを使用して権利を設定しようとしても、私の場合は役に立ちませんでした。
Visual Studioがネットワーク共有からアセンブリをロードできるようにするために最終的に働いたのは、ファイル「C：\ Program Files（x86）\ Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe.config」を編集することでした（デフォルトを想定しています）インストール）。
xmlの「<runtime>」セクションに追加する必要があります
<loadFromRemoteSources enabled="true"/>
書き込みアクセスを許可するには、そのファイルのアクセス許可を変更する必要がある場合があります。ファイルを保存します。 Visual Studioを再起動します。
実際に質問に答えるために、jcarle.comからこのコメントをコピーしました。
Visual Studio 2010/.NET Framework v4.0によるネットワーク共有の信頼
2011年1月20日、午後4時10分あなたが私のようであり、すべてのコードをサーバーに保存している場合、おそらくCasPol.exeを使用してネットワーク共有を信頼することを知っているでしょう。ただし、Visual Studio 2008（.NET Framework 2.0/3.0/3.5）からVisual Studio 2010（.NET Framework 4.0）に移行すると、頭を悩ませることがあります。
Visual Studioコマンドプロンプトを使用してCasPolにすばやくアクセスすることに慣れている場合は、一部のプロジェクトが新しいFullTrust設定を尊重していないように見える場合があります。理由は、注意を払っていない限り、Visual Studioコマンドプロンプトはデフォルトで.NET Framework 4.0フォルダーをそのパスに追加するためです。プロジェクトがまだ.NET Framework 2.0/3.0/3.5で実行されている場合、それらのバージョンにもCasPolを設定する必要があります。ほんの一言ですが、個人的には1.2の代わりに1をコードグループとして使用することで成功しました。
.NET Frameworkのすべてのバージョンのネットワーク共有を信頼するには、以下のようにフルパスを使用して各バージョンのCasPolを呼び出すだけです。
C：\ Windows\Microsoft.NET\Framework\v2.0.50727\CasPol -m -ag 1 -url file：// YourSharePath * FullTrust
C：\ Windows\Microsoft.NET\Framework\v4.0.30319\CasPol -m -ag 1 -url file：// YourSharePath * FullTrust
プロジェクトに取り組んでいる複数の人がいる場合（または持っていない場合でも）、これを行うことはお勧めしません。あなたはただトラブルを求めているだけです。
一方、あなたがそれに取り組んでいるのがあなただけなら、多くのトラブルを避けることができます。ただし、パフォーマンスは窓の外に出ます。動作させる方法に関しては、VSからソリューションファイルを開くだけです。セキュリティ上の問題が発生する可能性がありますが、CASPOLを使用して修正できます。しかし、私が言ったように、パフォーマンスはひどいものになるでしょう。繰り返しますが、まったくお勧めできません。
あなた自身とあなたのチームに感謝し、SVNまたは他の形式のソース管理をインストールして、できるだけ早くそこにコードを入れてください。
編集：コメントを部分的に撤回します。ボブキングは、ネットワークドライブからVSプロジェクトを実行する理由を以下に説明します。ボブのような特定の理由でそれをしているのでなければ、近づかないでください。そうでなければ、そのような開発環境をセットアップする前に、アヒルを一列に並べてください。
私はこれが古いスレッドであることを理解していますが、これは（Win 8.1を使用して）仮想ボックスでVisual Studio 2013を使用し、ホストマシン（Win 7）でコードを作成した同様の問題を解決するときに見つけた最高のスレッドでした。ソリューションを開くことはできましたが、コンパイルできませんでした。これに関する他のすべての回答は古いソフトウェアに関連しているため、この回答を追加して、このよくある質問を自分に合ったソリューションで更新します。
これが私がしたことです。現在のディレクトリとしてUNCパスを使用できるようにレジストリエントリを作成しました。
警告：レジストリエディタを誤って使用すると、システム全体に重大な問題が発生する可能性があり、Windows NTを再インストールして修正する必要があります。マイクロソフトは、レジストリエディターの使用に起因する問題の解決を保証できません。このツールは自己責任で使用してください。
レジストリパスの下：HKEY_CURRENT_USER\Software\Microsoft\Command Processor
値DisableUNCCheck REG_DWORDを追加し、値を0 x 1（16進数）に設定します。
警告：この機能を有効にして、UNC名の現在のディレクトリを持つコンソールを起動し、そのコンソールからアプリケーションを起動してからコンソールを閉じると、そのコンソールから起動したアプリケーションで問題が発生する可能性があります。
リンクでこの情報を見つけました： http://support.Microsoft.com/kb/156276
これを、誰もが答えられる質問に言い換えてみませんか？最初のポスターとまったく同じ問題があります。
VB 2008（VB6から最近アップグレードされた）のコピーがあります。バックアップされたネットワークドライブにソリューションを保存する場合、単一のことは実行されません。アセンブリで「allowpartiallytrustedcallers」が設定されている場合でも、モジュールにアクセスするための「信頼できる呼び出し元」エラー。誰もが使用し、私は私の同じ問題に戻っています。
これは大きなリクエストではありません。共有ドライブにソリューションと実行可能ファイルを配置して、セキュリティに関するばかげた無意味なことなく実行できるようにしたいだけです。すべての作業をフォームファイルに詰め込む必要はありません。
-編集：AllowPartialllyTrustedCallersコマンドを無視していた問題を見つけました。 ADODBを参照しようとしていますが、これは部分的に信頼されていません。だから、ネットワーク実行可能ファイルはデータベースにアクセスできませんか？とにかく、マイクロソフトはイントラネットに対して何を持っていますか？
だから私は同様の問題を抱えていました。 Visual Studioは、何かのドライブ文字にマップしたネットワークの場所を認識しません。おかしいのは、1日間働いたということです。私は自分のプロジェクトをセットアップし、作業を開始しましたが、問題はありませんでした。その後、私はシャットダウンし、翌日は何も動作しません。コード内のファイルの読み取り/書き込み、実行可能ファイルなどの出力はできませんでした。私のプロジェクトはローカルですが、私の出力はネットワーク上で放り投げられるように意図されていました。
とにかく、問題はおそらく管理者のコンテキストにありますが、オンラインで掘り下げながら見つけた問題を修正する1つの方法は、Visual Studioに問題のドライブを何らかの方法で参照させることです。これを行う方法はたくさんありますが、VSはマップされたドライブ文字を魔法のように認識できます。私の解決策は、プロジェクトプロパティの[デバッグ出力の場所]に移動し、[参照]をクリックして、ネットワークドライブとVoilaで以前に作成した出力の場所に移動することです!!!
私はこれを理解しようとして半日を費やし、それが誰かの時間を節約するかもしれないと思ったので、これを置きたかった。どうもありがとう！
エリック
私は最近同じ問題に直面していたので、この答えは自分の知識を追跡するためのものです。とにかく、それが役に立つと思うはずです、以下は問題と解決策です。
問題：NET 4.0プロジェクト、SVNリポジトリ、チェックアウトフォルダーはローカルドライブにあり、参照アセンブリはビルドサーバーによってビルドされ、ネットワークドライブで利用可能です。 W7のVisual Studioは参照を追加できますが、プロジェクトをビルドできません。
解決策：NET 4.0はネットワークアセンブリ用のサンドボックスを自動的に提供しないため、machine.config更新を介して完全に信頼する必要があります。 http://msdn.Microsoft.com/en-us/library/dd409252.aspx
しないでください。ソース管理（バージョン管理）がある場合、ファイルをネットワークドライブに配置する必要はありません。ファイルがネットワークドライブに保存されると、現在プロジェクトをビルドしている間でも誰でもファイルを変更できるため、ソース管理を使用して達成したいすべてを完全にバイパスします。カブーム！
PS：これは、私にとって過剰なエンジニアリングの典型的なケースのように聞こえます。
特定の問題がありますか？
複数の人がソリューションを開くことを許可する場合、最初の問題は、.NCBファイル（Intellisense）が排他的にロックされ、1人のユーザーのみがクラスツリーを参照できることです。そしてもちろん、あるユーザーの変更が他のユーザーの変更を上書きする可能性があります。
macで実行するパラレルでvc11を使用しようとしたときに、これが役立つことがわかりました： http://social.msdn.Microsoft.com/Forums/en-US/toolsforwinapps/thread/2ffdcb01-c511-4961-834b-afd5f2fbb8e1 、具体的には：
1）ローカルデバッグからリモートデバッグに切り替えて、マシン名を「localhost」に設定できます。これにより、ローカルマシンでリモート展開が行われます（したがって、プロジェクトのディレクトリは使用されません）。リモートデバッガーツールをインストールしたり、msvsmonを起動してlocalhostで動作させる必要はありません。
Visual Studioの一部の機能がネットワークドライブでの動作を拒否することに注意してください。
たとえば、SQL Expressユーザーインスタンスのmdfファイルはローカルドライブに配置する必要があります。
別の例として、UNCパスを使用する場合、それらが十分に短いことを確認する必要があります。
私が正しく理解していれば、Visual Studioプロジェクトファイルはネットワークドライブに保存されており、そこから実行しています。これは私がやっていることであり、問題はありません。セキュリティポリシーを設定したことを確認する必要があります。 Caspol を使用してこれを行うか、コントロールパネルの管理ツールメニューを使用できます。
ネットワークドライブでVisual Studioプロジェクトを開くときに同様の問題が発生し、ローカルC：\ドライブにUNCディレクトリを指すシンボリックリンクを作成して修正しました
例えば.
mklink /D "C:\Users\Self\Documents" "\\domain.net\users\self\My Documents"
次に、UNCパスの代わりにC：\ Users\Self\Documents \パスを使用してプロジェクトを開くことができます
（プロジェクトを参照しているときにシンボリックリンクをダブルクリックすると、Visual Studioによって '\\ domain.net ..'パスに自動的にリダイレクトされるため、注意が必要です。'C：を貼り付けてコピーする必要がありました。ドライブ文字パスで開くための\ Users\'パス）
これが他の人に役立つ場合、 here の手順を実行して、ネットワーク共有の場所をWindowsイントラネットゾーンに追加する必要がありました。特に、ネットワーク共有でソリューションを開くとき（つまり、VMware Fusionを使用して、Macのハードドライブからソリューションを開くとき）、Visual Studioがロードでハングする問題がありました。このシナリオで実行されているPostSharpにも問題がありました。