Add missing project build settings

[flawedworld]

… by default in project file

[ElPumpo]

Hi. I've tried this. Wont the built file be > 200 MB?

[flawedworld]

@ElPumpo No, this will not occur, as <SelfContained>false</SelfContained> has been set. Because this option is set, the .NET Desktop runtime is not bundled with the exe, and produces a file ~12MB in size.

[ElPumpo]

I do not quite understand what this changes?

[flawedworld]

It merely just sets this configuration in the project file so you can just do dotnet publish -c Release to produce a usable exe. Just for convenience.

[TomKranenburg]

Actually @ElPumpo I did this for my pull request. It's a good idea. These are the options I used to compile. Just make sure you select "Deployment mode: Framework dependant" or indeed it does end up being several hundred MiB.

[ElPumpo]

@flawedworld why did you change build from 86 to 64 bit?

[ElPumpo]

Oh I see now my private build settings are not shared..

[flawedworld]

@flawedworld why did you change build from 86 to 64 bit?

I don't think it makes sense to target win-x86, given that Nvidia has killed 32 bit driver updates.

In general, it is not good practice to produce 32 bit binaries and expect 64 bit users to use them.

[ElPumpo]

But .NET 7 still supports 32 bit correct? Since TNUC supports many older GPUs thanks to the nvidia-data repo it's best not to kill support just yet?

I understand you wouldn't run this on discontinued drivers but you could always run TNUC once on systems with old drivers to find out if there's a newer.. Does it make any sense to you?

I also changed your PR title it's misleading. TNUC is already released as a single file it's nothing new. It's just that as I just discovered it was a file in gitignore and not general setting.

[flawedworld]

@ElPumpo Yes, win-x86 is still supported in .NET 7. I personally don't think that the use-case of older devices is too important, the drivers will contain several unpatched security issues, and nobody should really be using them. Though with that said, if it is considered to be something in-scope, then "technically" there should be a separate 32 bit exe used for such cases.

[ElPumpo]

So you can change in the changelog to what I titled the PR. Add author like the previous PR aswell

Are these two lines really needed?

    <DebugType>embedded</DebugType>
    <IncludeNativeLibrariesForSelfExtract>true</IncludeNativeLibrariesForSelfExtract>

I don't have them in my build file, do I really need them? My FolderProfile.pubxml looks like this:

<?xml version="1.0" encoding="utf-8"?>
<!--
https://go.microsoft.com/fwlink/?LinkID=208121.
-->
<Project>
  <PropertyGroup>
    <Configuration>Release</Configuration>
    <Platform>Any CPU</Platform>
    <PublishDir>bin\Publish\</PublishDir>
    <PublishProtocol>FileSystem</PublishProtocol>
    <_TargetId>Folder</_TargetId>
    <TargetFramework>net7.0-windows</TargetFramework>
    <RuntimeIdentifier>win-x86</RuntimeIdentifier>
    <SelfContained>false</SelfContained>
    <PublishSingleFile>true</PublishSingleFile>
    <PublishReadyToRun>false</PublishReadyToRun>
  </PropertyGroup>
</Project>

[flawedworld]

<DebugType>embedded</DebugType> is bundling the data from the .pdb that would be generated normally, into the exe, might be helpful to debug issues.

<IncludeNativeLibrariesForSelfExtract>true</IncludeNativeLibrariesForSelfExtract> means the exe will be built with native DLLs bundled inside of it. If you set it to false you will see it does not produce a single exe.

[ElPumpo]

IncludeNativeLibrariesForSelfExtract

Only managed DLLs are bundled with the app into a single executable. When the app starts, the managed DLLs are extracted and loaded in memory, avoiding the extraction to a folder. With this approach, the managed binaries are embedded in the single file bundle, but the native binaries of the core runtime itself are separate files.

To embed those files for extraction and get one output file, set the property IncludeNativeLibrariesForSelfExtract to true.

Specifying IncludeAllContentForSelfExtract extracts all files, including the managed assemblies, before running the executable. This may be helpful for rare application compatibility problems.

Fine pdb is good for crashes yes, does it take more space? Still don't understand this other option I still don't use it for my builds. Why do you need it?

[flawedworld]

Embedding debug information into the exe will take slightly more space, but barely anything. 12817959 bytes vs 12805671 bytes.

Without <IncludeNativeLibrariesForSelfExtract>true</IncludeNativeLibrariesForSelfExtract> it does not produce a single exe.

[ElPumpo]

Thanks for your contribuations improving the project!