We Keep Coding

C# .NET 6.0 - exe only?

Hey I switched from NET Framework 4.8 to .NET 6.0
When I build my file it outputs the build.exe (130kb) and an build.dll (2.3mb).
So it looks like the exe is using the dll to run as the dll has the source code inside and the .exe doesn't.
Is it possible to build an .exe only without the dll?
I tried to use a Costura Fody an resource embedder but that didn't work.
Edit:
I was able to use the "publish" feature to create a self contained exe but the file size increased from 3mb to an 180mb exe... Is there any other method?

You probably want a single file framework dependent deployment and not "self contained". This way you would not have to include all the framework file in your deployment package, instead the computer would have to have the framework already installed. To do this, change deployment mode in the deployment settings from self contained to framework dependent. See Single file deployment
You might also check out "trimming" to remove unneeded dependencies, since this should significantly reduce the size of a self contained application.

Your observation is right.
The .exe file of a .NET core app is only a stub loader. The actual code is in the .dll file. For the application project, you now have both an application.dll and an application.exe.
Unless you use any of the options you mentioned (deploy as single file), I don't think there's a way around this.

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

.NET Core and .NET Standard projects don't do an incremental build

I'm using .NET standard libraries inside my desktop solution so I can share those libraries between my desktop and web solution. However, I'm seeing incremental build problems now. Has anyone else experienced this or managed to fix it?
I can see that the .NET standard libraries have some incremental build features in that if I build them on the command line using "dotnet build" it takes, for example, 1 second and then if I make a code change in that library and run again it takes 2 seconds. This goes back to 1 second if I run for a third time.
However, in pure .NET framework applications like a console app or wpf app, traditionally if you make no code change then inside visual studio it doesn't even attempt to build the project. It simply says "1 up-to-date". I'm seeing the .NET standard libraries always re-copied to the output directory and they also cause my entire WPF project to rebuild every time. After a while this starts to get annoying if every code change takes 5 seconds to build!

I have at least a partial answer for you. The issue of the binaries copying out every time is explained by Microsoft as essentially there is no support, update to a later target framework version.
At this point we don't do any smart trimming of the compat shims that come with the tooling so it ends up copying them all. If you (or your dependencies) don't rely on them it is safe to delete/not-deploy them but doing it blindly may break some of your dependencies.
And this is supposed to be fixed in 4.7.1
It's worth mentioning that with .NET Framework 4.7.1 and up you'll not have to deploy any extra files for .NET Standard. Today, that's already the case if you target Xamarin or .NET Core.
As for why it always copies, instead of doing so selectively as it should, I am unsure. I have scoured build logs and I believe that the files have not been properly added to the output list of a build target but it is difficult to diagnose. Visual Studio also has smart ways to entirely avoid invoking MSBuild, so logic in the MSBuild script to skip a target doesn't even have to run. Visual Studio is mostly a black box, but I suspect this logic is broken too, based on the behavior both you and I have observed.
This is a frustrating issue because there are still good reasons to target old versions of .NET Framework, for example if a library is distributed to a customer who may build against it using Visual Studio 2013, and cannot be expected to update.

Sharing a DLL between projects

Microsoft says it's platform neutral these days, so I'm trying to build on Mac and Linux only with VS Code and deploy to Azure. Why? It's mainly to prove that I can.
Our project has several parts which include a couple of different websites, a Web API, er API and a few other bits. On my Mac I've built a .Net Core Class Library with a load of objects in. Command line, dotnet build, DLL out, no problem.
I want to put that DLL on the Linux machine where the MVC website is being built - the objects forming the models part of that site hopefully. I cannot figure out how to get the website project to reference my DLL and use the objects.
I had assumed I copy it to the other machine, place it in the bin folder of the site being developed and reference it in the Dependencies section of the site's project.json. Nope. I saw a few articles that said .Net Core only works with NuGet and it had to be a package. Is that really true?
I've found and read (if not entirely understood) everything you could imagine on sharing between .net core and .net framework. This is a core-only project so not applicable. Frankly I'm lost, and something called .Net Standard has just rolled into my field of vision.

So instead of copying the DLL, use dotnet pack to build a nuget package on your Mac, and copy that to your Linux machine instead. Put it in a directory that you configure as a local nuget repository (no server or anything required) and you're away.
I agree it's not as straightforward as a reference to a DLL, but it's not too bad. Note that you'll need to version the package appropriately, so that the tool system can detect when it's changed.

How to use wixlibs as file references with support for different platforms?

I just am trying to replicate my distributed C# project structure to WIX setup projects. Now there is the following problem:
LIB: a C# library solution that builds AnyCPU .NET dlls from several C# projects
APP: the dlls from LIB are referenced (as file references) by this main application solution. Additionally there are platform dependent libs included in this application solution, therefore it is important to being able to create setups for the two specific target platforms x86 and x64.
Now I started to create a wixsetup project within the APP solution (which works fine). Then I proceeded with creating a wixlib within the LIB solution that references the LIB .NET dlls into the wixlib.
Now the problem:
The wixlib references the AnyCPU .NET dlls within a DirectoryRef which seems to be platform specificly tagged when creating the wixlib. Therefore I have to go back to the LIB solution, build the project with one platform target, copy the built files (via SVN externals mechanisms) to the APP solution, build this project with the exact same target platform as the wixlib was created with and repeat this procedure for creating the other platform.
It may seem that this is kind of complicated, but doable. Due to the fact that I omitted several other library solutions for which the same problem applies and the fact that all those libraries are used in multiple application solutions and - finally - everything has to run on our build server automatically as well, it is clear that this will not work.
I know of the following solution, though:
Double the .NET dll references within wixlib to assign them to different DirectoryRef INSTALLDIR and INSTALLDIR32 e. g. and to implement those different directory references in the wixsetup.
But this would complicate things as well and is not my preferred solution therefore - if there is an alternative.
If there is no smart alternative, just tell me and I will do things as described in the last paragraph.