2

実行可能ファイルと同じディレクトリにあるファイルを確認する必要があります。

現在、私はこのコードを使用しています -

if (!File.Exists(versionFile))
{
     File.Create(versionFile).Close();        
}

そして、ある場所で私はこれを使用しています：

string file =     
   Path.GetDirectoryName(System.Reflection.Assembly.GetEntryAssembly().Location) 
        + "\\" + args.Executable;
    if (File.Exists(file)) {
        Process.Start(file);
        Application.Exit();
    }

どちらも同じ仕事をしていますが、どちらがより堅牢かはわかりません。どちらかが失敗するシナリオは考えられませんが、同時に、これらのアプローチの両方について怪しい感じがします。

どちらがより堅牢ですか、またはこの単純な問題に対する他のより良い代替手段はありますか?

4

3 に答える 3

3

最初の方法は現在のディレクトリ (Directory.SetCurrentDirectory(dir) で設定可能) を使用するため、2 番目の方法は最初の方法よりも堅牢です。

于 2013-10-11T10:15:58.707 に答える
3

それらはまったく同じ仕事をしているわけではありません.1つ目は現在の作業ディレクトリに関連するファイルを探しますが、2つ目とは異なる場合があります.

GetEntryAssemblyマネージ アセンブリがアンマネージ アプリケーションから読み込まれた場合は null を返すAssembly.Location可能性があり、アセンブリ ダウンロード キャッシュである可能性があるため、どちらも完全に堅牢というわけではありません。

最善の解決策は、 を使用することAppDomain.CurrentDomain.BaseDirectoryです。

于 2013-10-11T10:27:50.340 に答える
1

私が使う：

string startupPath = null;

using (var process = Process.GetCurrentProcess())
{
    startupPath = Path.GetDirectoryName(process.MainModule.FileName);
}

その理由は、これまで信頼できる唯一のものだったからです。補足として、これをApplication.StartupPath行います：

public static string StartupPath
{
    get
    {
        if (Application.startupPath == null)
        {
            StringBuilder buffer =
                new StringBuilder(260);
            UnsafeNativeMethods.GetModuleFileName(
                NativeMethods.NullHandleRef, buffer, buffer.Capacity);
            Application.startupPath =
                Path.GetDirectoryName(((object)buffer).ToString());
        }
        new FileIOPermission(
            FileIOPermissionAccess.PathDiscovery,
            Application.startupPath).Demand();
        return Application.startupPath;
    }
}
于 2013-10-11T10:37:17.063 に答える