We Keep Coding

Is there a way to restrict .NET Core projects to generate only .dll as output files when using .NET Core 3.1 sdk

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?

You can control this with the UseAppHost MSBuild setting:
The UseAppHost property 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 UseAppHost property to false to disable generation of the executable.
<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

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.

How create a .net standard and .net framework self-contained build?

My goal is to create a build output that acts as portable version of my application, containing the non-framework dependencies (nuget + projects) directly as dlls.
This demonstrates the solution and the four projects contained:
You can see the libraries are .net standard 2.0 while a console app (to run / debug some code) is using .net framework 4.7.2 (because we have some .net framework apps in use around here). The arrows in the image show the references that have been set.
Parts of the the libraries (not console app) might be imported into MS sql server in the future; these imports usually pick up all dependencies from the same folder if available (which is the reason for a self-contained output).
Problem A: Running the code on linux/mono
Using jetbrains rider to open the solution, build + restore packages will work without problems.
Running the console app will work to some extend (e.g. loading data from SQL) until it fails when calling some code that makes use of BouncyCastle (dll not found exception).
Looking at the build output shows three .dll files of my lib-projects along with the .exe file of the console-app plus all the .pdb files AND additionally the System.Data.SqlClient.dll.
Seems that might be the reason my sql code worked.
Problem B: Running the code on win10, .net framework / core installed
Using VS / rider made no difference here, opened the solution, restored packages + build without problems. Running the console-app fails earlier than before: this time it was unable to find the Syste.Data.SqlClient.dll.
Checking the build folder shows my three lib-dlls and the .exe including the .pdb files, nothing else.
To my understanding, the files have to be either in GAC or inside the same folder for them to be found. It seems when a .net standard library dependency includes nuget-packages, something is having troubling either loading them into GAC or at least copying them to the build directory (which is outdated I guess).
So even if my approach (having a portable-ish / self-contained version of my app) might be uncommon or even stupid, I would have thought that just running this code on the dev-machine should work fine.
Problem C: Including dependencies in the build output
According to information I found here, the <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies> property can be used to have dependencies being copied to the build directory.
And while this seems to copy too many files (tried excluding some according to docs) it does indeed copy the .dll files for a complete package when building the ExchangeIntegration project (.net standard 2.0).
Looking into accomplishing the same for .net framework .csproj projects yielded mixed results. I was playing around with the copy-local setting and stumbled across similar problems when creating nuget packages and using .targets files but had no success.
About the specific libraries used
I'm more interested in learning the right concept to handle this, it's not really about whether or not it makes sense to import Newtonsoft.Json into MS sql server.
I feel I'm fundamentally missing something; maybe the output type library is not correct for my goal or maybe I'm mixing problematic .net versions, although I did a quick check and it seems ok.
How can I get a .net framework (console-app) build that contains all non-framework dependencies (e.g. nuget) AND an separate .net standard (library) build, that also contains all non-framework dependencies?
EDIT: Adding all nuget packages to the top tier project (console-app in my example) seems to work around the problem, code executes without problems. I'm still waiting for a proper solution.
EDIT2: Added mono/msbuild version used under arch: 16.4

Is there a way to make a console application run using only a single file in .NET Core?

In .NET framework, you can make a single .EXE file that will run from the command line without having any extra config files (and if using ILMerge, you can put all .DLL references into the 1 .EXE assembly).
I am taking a stab at using .NET Core to accomplish the same thing, but so far without success. Even the simplest Hello World application with no dependencies requires there to be a file named <MyApp>.runtimeconfig.json in order to run using dotnet.exe.
dotnet F:\temp\MyApp.dll
The contents of the <MyApp>.runtimeconfig.json are as follows:
{
"runtimeOptions": {
"framework": {
"name": "Microsoft.NETCore.App",
"version": "1.1.1"
}
}
}
Without this config file in the same folder as the .DLL, I get the following error:
A fatal error was encountered. The library 'hostpolicy.dll' required to
execute the application was not found in 'F:\temp'.
My question is: Is there some way to change the application so it doesn't require this config file to be present, so that the defaults of this information are compiled within the .DLL but can be overridden by adding the config file?
NOTE: I also want to ensure it "just works" regardless of the platform it is installed on it provided the platform has the right version of .NET Core.
Background
I am trying to get a smooth user experience for running some utilities that are useful sometimes, but are rarely ever needed. Since it doesn't appear to be possible to use the same .DLL that is referenced from a client application as a console application, the next best thing would be to have a single file that could be downloaded and run without any dependencies.
For example, in Java you can simply download a .jar file on any supported platform and run:
java <package>.jar <namespace>.SomeClass [args]
and it will "just work" without any extra files. How can I get a similar user experience using .NET Core?
In a nutshell, I want to try to avoid the extra step of "unzip to a directory first"...

Update 2018: .NET Core 3.0 aims to enable a new scenario: packing the .NET Core runtime and all application dependencies into a single executable.
At the moment, there are no fail-safe methods to create a single executable file. Since there are a lot of type-forwarding dll files involved, even ILMerge and similar tools might not produce correct results (though this might improve, the problem is that those scenarios haven't undergone extensive testing, esp. in production applications)
There are currently two ways to deploy a .NET Core application:
As a "portable application" / "framework-dependent application", requiring a dotnet executable and installed framework on the target machine. Here, the XYZ.runtimeconfig.json is used to determine the framework version to use and also specifies runtime parameters. This deployment model allows running the same code on various platforms (windows, linux, mac)
As a "self-contained application": Here the entire runtime is included in the published output and an executable is generated (e.g. yourapp.exe). This output is specific to a platform (set via a runtime identifier) and can only be run on the targeted operating system. However, the produced executable is only a small shim that boots the runtime and loads the app's main dll file. This also allows an XYZ.runtimeconfig.json to set additional runtime properties like garbage collection settings.(think of it as a "new" app.config file)
In the future, the CoreRT runtime – which is still under development at the time of writing – aims to allow creating a single pre-compiled native executable that is specific to a runtime and does not require any other files.

Tested with .NET Core 2.2 on a console app:
Reference Microsoft.DotNet.ILCompiler package in your output project. You'll need to add MyGet package repository in Visual Studio settings. *
Publish the project via command line,
dotnet publish C:\src\App\App.csproj -c release -r win-x64 -o output-win-x64. If there's no "Desktop Development for C++" component installed, do it in Visual Studio Installer, or the command will fail.
Go to the output folder (e.g. "C:\src\App\output-win-x64") and grab the native image (.exe file).
On Windows it produced a fully functional 5Mb .exe file (compared to original self-contained publish with folder size at ~60Mb). On macOS the ILComplier though produced output without any error, the app crashed with unhandled expection (on the line with LINQ expression).
*Go to "Tools -> Options -> Package Manager -> Package Sources" and add new source at https://dotnet.myget.org/F/dotnet-core/api/v3/index.json

It is possible in .NET Core 3.0+
The feature is enabled by the usage of the following property in your project file (.csproj):
<PropertyGroup>
<PublishSingleFile>true</PublishSingleFile>
</PropertyGroup>
There are other options as well, such as packaging the pdb into the bundle, or leaving certain files out.
Documentation can be found here: https://learn.microsoft.com/en-us/dotnet/core/deploying/#publish-self-contained
True it just works:
Combine this technique with the Self Contained Deployment workflow, you can get a true "it just works" experience for your user, they don't even have to install the .NET Core runtime for your app to run.
I am currently deploying applications to my clients as single .exe files.
Read more about that here: https://learn.microsoft.com/en-us/dotnet/core/deploying/#self-contained-deployments-scd

Publish ONE executable file

Is there a possibility to publish .NET Core Console Application as single file (no matter if it's EXE or DLL)?
I am using .NET Core 1.1 but I am elastic to port my project to another version.

At the moment, this is not possible because:
portable applications still need at least a runtimeconfig.json to tell the host (dotnet / dotnet.exe) which shared runtime to use. Even if you IL-Merge all your managed code into a single dll, this file is still required. The host also expects a deps.json expressing the dependencies of the application.
self-contained applications rely on building a .dll + .deps.json and copying over content from runtime-specific NuGet packages. This also includes native libraries that are searched for by file name.
The CoreRT project aims to compile a .NET Core application to a single native binary using ahead-of-time compilation but is still in development.

Filehelpers Publish Release file without need for DLL

this might be a bit of a noob question..
I've coded a simple file conversion app in C Sharp (.net 4, VS2010) that uses the Filehelpers library. I've got a reference to the library in my project references. When I publish the project in Release mode, it outputs the Filehelpers.dll file with the executable together, and the executable won't work unless it's in the same folder as the DLL.
I tried setting Copy Local to False, but it still doesn't work. Is there any way to package the library as part of the exe file?? This is a very simple app which is meant to be distributed easily and having this required Dll floating around is a huge downside.
thanks
T
Got it working after some fiddling with ILmerge not running on .net v4. Here is my command for future thread visitors:
ILMerge /targetplatform:v4,C:\windows\microsoft.net\framework\v4.0.30319 /out:merged.exe /log Original.exe FileHelepers.dll

You may want to look in to your project property settings where you can custom copy files where ever you want post build if you are looking to move files around after the build. If you are looking to include a .dll in your .exe look here