Single-file applications get empty application names and collapsed folders (Assembly.Location is empty)

[karlspace]

Problem

In a single-file application (PublishSingleFile=true), Assembly.Location is an empty string (IL3000). BAUERGROUP.Shared.Core derives application names and folders from it in several places. In a single-file build they all come out empty or collapse into their parent folder.

Observed on 2026-09-15 with bgIndustrialAutomation Client (Shared.Core 3.0.8), published the way its release workflow does it (-r win-x64 --self-contained true -p:PublishSingleFile=true) and then started:

What	Expected	Actual
Log file	C:\ProgramData\<App>\Logging\<App>.log	C:\ProgramData\Logging\.log
ApplicationFolders.ExecutionAutomaticApplicationDataFolder	C:\ProgramData\<App>	C:\ProgramData (the application's settings file lands directly in C:\ProgramData)
BGLoggerConfiguration.ApplicationName	<App>	empty (start banner prints --- ---)
NLog logger name (BGLogger)	<App>	empty
Sentry ApplicationName tag / Logger context property	<App>	empty, so Sentry.NLog drops both

The same build run from dotnet run (not single-file) behaves correctly, so this only shows up on installed stations. Two different single-file applications on one machine also share the same log file and data folder.

Affected code (main, 02325dd)

• Application/ApplicationFolders.cs:29 ApplicationBinary, :40 ApplicationFileNameWithoutExtension (and everything built on it: ExecutionApplicationDataFolder, ExecutionCommonApplicationDataFolder, ExecutionAutomaticApplicationDataFolder), :84 ApplicationExecuting
• Application/ApplicationConfigurationStoreBinary.cs:98
• Logging/BGLogger.cs:41 (logger name)
• Logging/BGLoggerConfiguration.cs:28 (ApplicationName, which feeds the log file name, the archive name and the Sentry tag)
• ErrorTracking/BGErrorTracking.cs:100 (default release name), ErrorTracking/BGErrorTrackingConfiguration.cs:18 (ApplicationName)

Suggested fix

• For names use assembly.GetName().Name, which works in single-file builds.
• For directories use AppContext.BaseDirectory, and for the executable path Environment.ProcessPath.
• Enable <EnableSingleFileAnalyzer>true</EnableSingleFileAnalyzer> in the library, so IL3000 flags any new Assembly.Location use at build time.
• Add a test that runs the name and folder resolution with an empty Location, or a smoke test against a single-file publish.

Impact on applications

Stations that are already installed keep their settings in C:\ProgramData\<App>.Configuration.json and their log in C:\ProgramData\Logging\.log. Once this is fixed, the folders move to the intended location. The release notes should say so, since applications may need to migrate or look in the old location once.

[karlspace]

Thanks for the observation table from a real single-file publish. Seeing C:\ProgramData\Logging\.log made the scope obvious right away.

Fixed in 155e7c7, following the suggested approach:

Aspect	Behavior
Names (ApplicationFileNameWithoutExtension, BGLogger logger name, BGLoggerConfiguration.ApplicationName, BGErrorTracking release and ApplicationName, binary store file name)	Assembly.GetName().Name, which works in single-file builds
ApplicationBinary, ApplicationExecuting	AppContext.BaseDirectory (trailing separator trimmed to keep the previous format)
Build-time guard	EnableSingleFileAnalyzer on for all non-netstandard targets, IL3000 promoted to an error, so a new Assembly.Location use fails the build
Tests	ApplicationFoldersTests pin names and folders

Verified with a real single-file publish (-r win-x64 -p:PublishSingleFile=true), where Assembly.Location is empty:

ApplicationFileNameWithoutExt  : 'SingleFileProbe'
ExecutionAutomaticAppDataFolder: 'C:\ProgramData\SingleFileProbe'
BGLoggerConfiguration.AppName  : 'SingleFileProbe'
Logger name                    : 'SingleFileProbe'
Rendered log file              : 'C:\ProgramData\SingleFileProbe\Logging\SingleFileProbe.log'
ErrorTracking AppName          : 'SingleFileProbe'

One trade-off: ApplicationExecuting used to be the folder of BAUERGROUP.Shared.Core.dll and is now the application base directory. These are the same in every normal NuGet deployment; only a host that loads Shared.Core from a separate plugin folder would see a difference.

As noted in the issue, stations installed from a single-file build keep their old files in C:\ProgramData\<App>.Configuration.json and C:\ProgramData\Logging\.log. The application now uses C:\ProgramData\<App>\, so a one-time migration or a release-note hint is needed on the application side.

[github-actions]

🎉 This issue has been resolved in version 3.1.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀