When you publish an Asp.net core application it produces a web.config with the following configuration
<aspNetCore processPath=".\MyApplication.exe" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="inprocess" />
You can use processPath=".\MyApplication.exe" or processPath=".\MyApplication.dll"
Does anyone knows the pros & cons of each on and when should we use which?
Thank you in advanced!
Usually, I don’t think you have much of a choice there. There are two options as far as I am aware:
.exe.dotnet executable and passing the path to the application DLL.That’s also what the documentation suggests and what happens automatically when you publish your ASP.NET Core application from Visual Studio or through the dotnet CLI. So the transformed web.config should have either of the following configurations:
<!-- self-contained application -->
<aspNetCore processPath=".\MyApp.exe" … />
<!-- framework-dependent application -->
<aspNetCore processPath="dotnet" arguments=".\MyApp.dll" … />
The framework-dependent application configuration here assumes that the dotnet executable is in the PATH environment variable. Otherwise, you can also specify an absolute path to it.
I personally have never seen <aspNetCore processPath=".\MyApp.dll" … /> and would be surprised if that worked because the ASP.NET Core hosting module for IIS does not actually come with any knowledge how to launch .NET Core applications (at least as far as I know). That’s why you usually have to specify the path to an exectuable (either the application’s .exe itself, or the runtime executable).
As for which of these options to use, it really depends on how you want to run your application. If you publish your application as self-contained, then the runtime is already included and you do that in order to be independent of the global runtime that may be installed on the machine. If you publish your application as framework-dependent, you rely on a framework being available on the machine (which can also be updated centrally etc.).