2

C: ドライブの Visual Studio 2008 で開発した subsonic を使用するプロジェクトがあります。問題ありません。Visual Studio 2010 にアップグレードしたばかりです (私のコンピューターが偶然に停止したため、現在、VirtualBox で仮想化された Windows XP を実行しています)。

プロジェクトは C: ドライブでは問題なく実行されますが、G: (ベース PC のパーティションを指すマップされたドライブ) から実行すると、subsonic が使用するカスタム ツールを実行できません (以下にリストされているエラー)、またはWeb アプリケーションを実行します (「デバッグなしで開始」: 「G:\GPNNT\GpnntApp\GpnntApp」への変更の監視を開始できませんでした)。

これは .net 3.5 ソリューションです。

ここに画像の説明を入力

これは、十分に文書化された簡単な問題のようです。私は次の行動をとった：

(1) バッチファイル

c:
cd "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727"
caspol -all -reset
caspol -q -machine -addgroup 1 -url file:////g:\* FullTrust -name "G Drive"
caspol -q -machine -addgroup 1 -url g:\* FullTrust -name "G Drive 1"


c:
cd "C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319"
caspol -all -reset
caspol -q -machine -addgroup 1 -url file:////g:\* FullTrust -name "G Drive"
caspol -q -machine -addgroup 1 -url g:\* FullTrust -name "G Drive"

pause

（私は無数の異なるURLフォーマットを試しましたが、すべて役に立ちませんでした）

(2) .Net 2.0 構成ユーティリティ ([コントロール パネル] > [管理ツール])

分析ツールを使用すると、上記のバッチ ファイルで行われた両方の設定がドライブ上のファイルに適用されるように見えます。
また、イントラネット グループを FullTrust に設定してみました (これはやりたくないことです!)。変わりはない。

(3) loadFromRemoteSources

プロジェクト自体は .NET 2 しか使用していませんが、VS2010 自体は内部で .NET 4 を使用している可能性があると考えるのが妥当です。さらにグーグルで調べた後（例：ここ）、追加しました

<runtime>
  <loadFromRemoteSources enabled="true"/>
</runtime>

両方の .net バージョンの machine.config ファイルに。

(4) VS2010 SP1 へのアップグレード

これらのどれも違いを生んでいません。私の血圧が危険なほど高いレベルに達する前に、誰かがこれに光を当てることができますか? すべてを C: で実行することに戻れると思いますが、この仮想化の時代では少しばかげているように思えます。VM とは別の場所にあるデータが本当に必要です。

このSO 投稿にも同じ問題があり、テスト プロジェクトを非難していることに注意してください。また、テスト プロジェクトもありませんが、SubSonic dll のどこかにテスト参照が埋め込まれている可能性があります。

直前の追加: また、SQL Server 2005/8 が G: と通信しないことにも気付きました (たとえば、そこからバックアップを復元する)。どのソリューションでもこれが発生する可能性があると思います。それはもう一つの素晴らしいことです。

4

2 に答える 2

3

後世のために、ここに私の調査結果をいくつか示します。

VS 2010 でマップされたドライブ:

  • 安全でない場所からのプロジェクトの読み込みに関する最初のメッセージがあります。これは、前述のように CASPOL を使用して修正されます。CASPOL はその URL に対して非常に柔軟で、表示されている両方の形式を受け入れます。CASPOL は .NET 4 ではデ​​フォルトで無効になっているため、設定によって違いは生じません (理由はこちらを参照してください)。
  • その後、さらにいくつかの問題があり、それらを文書化していませんでしたが、それぞれを修正した後、別の問題が発生しました。loadFromRemoteSources は 1 つのメッセージを修正しましたが、「変更の監視を開始できませんでした ...」に触れることはできませんでした。これの一環として、Christoph の答えはおそらく正しい (少なくとも .NET 2 の場合) で、おそらくドライブ上に各アセンブリをセットアップする必要があり、これは VS プロジェクト ドライブではまったく実用的ではありません。

したがって、当然のことながら、マップされたドライブに VS プロジェクトを保存するのは面倒だと思います。ソース管理とローカル プロジェクトが最適です。率直に言って、ネットワーク化されたドライブで元に戻す機能がないことは、IMO だけでなく開発作業にとっても苦痛です。

しかし

元の問題は、VM の C: にプロジェクトを保存したくないほどネットワーク ドライブが必要だったということではありませんでした (つまり、VM ベースのドライブ イメージとは別にデータをバックアップできるようにしたかったのです)。 ）。

ずっと私を見つめていた答えは、2 番目の仮想ディスクを作成し、それを VM に G: として接続することでした。これはローカル ドライブであるため、すべての信頼の問題が発生するわけではありませんが、データは完全に分離されます。そのドライブのすべてのデータを Dropbox フォルダに保管しているので、完全なリアルタイムのオフサイト バックアップも得られます。満足しています。

于 2011-09-16T12:29:56.440 に答える
0

たぶん私は間違っています（私はこれを調べませんでした）が、マップされたドライブで作業するときは強い名前で作業する必要があると思います。好き

caspol -m -q -ag My_Machine_Zone -url g:\* Nothing -n "GDrive"

caspol -m -q -ag "GDrive" -strong -file "<pathToFile>" "<assemblyStrongName>" "<assemblyVersion>" FullTrust -n "GDriveFileX" -d "Code Group for fileX"

後でポリシーを簡単に変更または削除できるように、常にトップレベルのグループを作成します。これは苦痛ですが、URIに基づいてマップされたドライブに完全な信頼を与えないことは理にかなっていると思います。

可能であれば、より現代的なものを使用してください。

于 2011-09-14T08:32:28.510 に答える