2009-06-11 16 views
83

可能性の重複:
How do I get the name of the current executable in C#?現在の実行可能ファイル名はどのようにして見つけられますか?

実行可能ファイルが外部ライブラリをロードします。
ライブラリが呼び出し可能な実行可能ファイルを知る方法はありますか?

(私は他の場所でこの答えを見て誓っているだろうが、私はもうそれを見つけるように見えることはできません)

答えて

112
System.Diagnostics.Process.GetCurrentProcess().MainModule.FileName 
+7

これは ".vhost"を追加する傾向があります。ファイル名に、System.Reflection.Assembly.GetEntryAssembly()を使用している場合に存在しない問題。場所(代替回答を参照)。 – Contango

+4

@Contango、VSで "Visual Studio Hosting Process"を使用しているために発生します。 – LuddyPants

+0

VS 2012での単体テストの場合。 ProcessName:vstest.executionengine.x86 ConfigurationFile:C:\ TFS \ Tests \ MyData.Tests.v4.0 \ bin \ Debug \ MyData.Tests.v4.0.dll.config MainModule.FileName:C:\プログラムファイル(X86)\ MICROSOFT VISUAL STUDIO 11.0 \ COMMON7 \ IDE \ COMMONEXTENSIONS \ MICROSOFT \ TESTWINDOW \ vstest.executionengine.x86.exe MainModule.ModuleName:vstest.executionengine.x86.exe フレンドリ:UnitTestAdapter:Running test – Kiquenet

7

私は、これはあなたが望むものであるべきだと思う:

System.Reflection.Assembly.GetEntryAssembly().Location 

このリターンプロセスが起動したときに最初にロードされたアセンブリは、あなたが望むものと思われます。

GetCallingAssemblyは、コールスタックのすぐ上位のメソッドを含むアセンブリを返します(つまり、同じDLL内にある可能性があります)。

+0

アイムGetCallingAssembly()についてわからない - 呼び出すメソッド(呼び出しスタック上にあるもの)を含むアセンブリを返さないということはありませんか?これは、実行可能ファイルではなく、ライブラリと同様です。 –

+0

@マーティン:そうですね。 GetCallingAssemblyはうまくいく場合もありますが、ここでGetEntryAssemblyが必要なようです。 – Noldorin

3

Assembly.GetEntryAssembly()

70

あなたは実行したい場合:あなたのコードが直接呼び出された場合、上記と同じアセンブリすることができた(あなたのライブラリーを消費していますアセンブリをしたい場合は

System.Reflection.Assembly.GetEntryAssembly().Location 

を実行可能ファイル内のクラスから):

System.Reflection.Assembly.GetCallingAssembly().Location 

電子単にファイルはなく、パス、使用:上記の回答に加えて

Path.GetFileName(System.Reflection.Assembly.GetEntryAssembly().Location) 
+6

アンマネージドコードから呼び出された場合、GetEntryAssemblyはnullを返す可能性があります。 –

+0

実行可能ファイルが.NETアプリケーションでない場合、これが動作しないとは思わない。たとえば、管理されたコードを実行するCLRのインスタンスを内部的にスピンアップするアンマネージ実行ファイルであるIISは、ワーカープロセス(w3wp.exe)をスピンアップします。管理されたコードの中からこれを使用すると、私はあなたがw3wp.exeへのパスを取得するとは思わない。 –

40

私はコンソールアプリケーション

static void Main(string[] args) { 
    Console.WriteLine(
    System.Diagnostics.Process.GetCurrentProcess().MainModule.FileName); 
    Console.WriteLine(
    System.Reflection.Assembly.GetEntryAssembly().Location); 
    Console.WriteLine(
    System.Reflection.Assembly.GetExecutingAssembly().Location); 
    Console.WriteLine(
    System.Reflection.Assembly.GetCallingAssembly().Location); 
} 

として、次のTEST.EXEを書いた後、私はプロジェクトをコンパイルし、test2.exeファイルに出力を改名しました。出力線は正確で同じであった。私は、Visual Studioで、それを起動した場合

しかし、結果は次のとおりです。

D:\ test2.vhost.exe

D:\ test2.exe

D:\ test2.exe

C:\ WINDOWS \ Microsoft.NET Frameworkのは、\ \ v2.0.50727の\がmscorlib.dll

ReSharperのプラグインのVisual Studioには、可能なシステムとして

System.Diagnostics.Process.GetCurrentProcess().MainModule 

を強調しました。NullReferenceException。 MainModuleのドキュメントを調べると、このプロパティはNotSupportedException、PlatformNotSupportedException、InvalidOperationExceptionをスローすることができます。

GetEntryAssemblyメソッドも100% "安全"ではありません。 MSDN:マネージアセンブリ は、アンマネージアプリケーションからロードされたとき

GetEntryAssemblyメソッドはnullを返すことができます。たとえば、 管理されていないアプリケーションがC#で と記述されたCOMコンポーネントのインスタンスを作成した場合、C#コンポーネントのGetEntryAssemblyメソッドを呼び出すと、処理のエントリポイントがマネージアセンブリではなく コードであったため、nullが返されます。

私のソリューションでは、Assembly.GetEntryAssembly().Locationが好きです。

仮想化の問題を解決する必要がある場合は、もっと関心が寄せられます。たとえば、私たちはXenocode Postbuildを使って.netコードを1つの実行可能ファイルにリンクするプロジェクトを持っています。この実行可能ファイルの名前を変更する必要があります。上のすべてのメソッドは機能しませんでした。なぜなら、元のアセンブリまたは内部プロセスの情報しか取得できないからです。私が見つけた

唯一の解決策は、このいずれかが含まれていなかった

var location = System.Reflection.Assembly.GetEntryAssembly().Location; 
var directory = System.IO.Path.GetDirectoryName(location); 
var file = System.IO.Path.Combine(directory, 
    System.Diagnostics.Process.GetCurrentProcess().ProcessName + ".exe"); 
+1

GetEntryAssemblyメソッドは、IISの下でデバッグモードでWCFサービスアプリケーションを実行している場合もnullを返します。これは確かに、開発者だけが遭遇するまれな状況です。 – Contango

+0

Addin VS 2008を使用すると、Assembly.GetEntryAssembly()がnullになります。System.Diagnostics.Process.GetCurrentProcess()。MainModuleはdevenv.exeですが、私のDLLではなくAddinです。私はaddinを使用する別のアセンブリからAssembly(Addinのアセンブリ)を取得するのか分からない。 – Kiquenet

+0

1)A.exeがB.dllを使用し、B.dllがC.dllを使用する場合、そのコードがC.dllにある場合はどうなりますか? 2) AppDomainは、EXEアプリケーション、Webアプリケーション、ユニットテストアプリケーション、Addin Visual Studio、および「Silverlight App」(?)です。おそらくすべての場合に興味深い完全な解決策です。 – Kiquenet

2

です:

System.Windows.Forms.Application.ExecutablePath; 

〜ジョー・

+1

Formsの名前空間にはApplicationクラスがありますが、Formsとはまったく関係ありません。 – Nyerguds

+0

LOL - ええ、私はそれを使っていません。それを見つけるために奇妙な点。 – jp2code

+4

実際、Applicationクラスは、すべてのウィンドウ(a.k.a. "フォーム")イベントを処理するメインウィンドウのメッセージループを開始するものであるため、Applicationクラスは排他的にFormsに関連しています。 DoEvents()も含まれています。DoEvents()は、ウィンドウがハンドラ内で保留中のイベントを処理できるようにします。これは、.NETの発明に先立ってWin32 APIをプログラミングした人なら誰でも知っているはずです。 – Triynko

8

Environment.GetCommandLineArgs()[0]

関連する問題