When i build my .NET Core Console Application using .NET Core 3.1 sdk,it generates both .exe as well as .dll as output. When i was using .NET Core 2.1 it was generating only .dll as output. Is there a way to restrict .NET Core 3.1 sdk to generate only .dll as output?
1
You can control this with the UseAppHost MSBuild setting:
The
UseAppHostproperty was introduced in the 2.1.400 version of the .NET Core SDK. It controls whether or not a native executable is created for a deployment. A native executable is required for self-contained deployments.In .NET Core 3.0 and later versions, a framework-dependent executable is created by default. Set the
UseAppHostproperty tofalseto disable generation of the executable.<code><PropertyGroup><UseAppHost>false</UseAppHost></PropertyGroup></code><code><PropertyGroup> <UseAppHost>false</UseAppHost> </PropertyGroup> </code><PropertyGroup> <UseAppHost>false</UseAppHost> </PropertyGroup>
If you want to disable this when building from the command line, instead of setting it within the .csproj, pass the property as an argument. For example:
dotnet build /p:UseAppHost=false
0
In .NET, the difference between a .exe and a .dll is actually very small. .exe tend to be little more then .dll’s with some bootstrap code and a start point (the class whose main method is to be called).
You can use both .NET .exe and .dll as project references. There might be some difference in some fringe details like COM interop, but I do not expect it.
What exactly the compiler will build, depends on it’s inputs. Wich includes the project settings. There is a special type of project for library. And with version changes, the proper reading of projects files could be broken. And of course the option that some code is “seperated out” into a .dll is also there. Most programms nowadays are more .dll’s then executeables. And it can be beneficial to keep .exe small.
3