Open pikadun opened 4 years ago
What was the commandline you used? For example, if I create a console app, set the Copyright
property and then do something like dotnet publish --self-contained -r win7-x64
, the resulting EXE has the copyright set
I'm having the same problem. No information is being set on the exe when I use dotnet publish
on a linux CI server.
They are set when I do a publish to folder from Visual Studio.
I'm using SDK and runtime version 3.1
Here's what I use:
dotnet publish ./back-src/vmp/vmp.csproj --nologo -p:PublishProfile=FolderProfile -p:VersionPrefix="${version_prefix}" -p:VersionSuffix="${commit_short_hash}-${version_suffix}" -p:PublishDir="${CIRCLE_WORKING_DIRECTORY}/publish-backend"
First I tried without specifying the csproj file in order to build all projects in the solution, but had the same problem.
FolderProfile is set up through VS.
version_prefix, commit_short_hash, version_suffix are also correctly set up, as the artifact is going to be zipped with these values, which works (CIRCLE_WORKING_DIRECTORY is correct as well).
My project file has all these:
<PropertyGroup>
<GenerateAssemblyCompany>false</GenerateAssemblyCompany>
<!-- NOT SET ON CLI PUBLISH -->
<Authors>me</Authors>
<!-- NOT SET ON CLI PUBLISH -->
<AssemblyDescription>Business management and logistics</AssemblyDescription>
<!-- should be overridden but NOT SET ON CLI PUBLISH at all -->
<VersionPrefix>1.3.0</VersionPrefix>
<!-- should be overridden but NOT SET ON CLI PUBLISH at all -->
<VersionSuffix>rc</VersionSuffix>
<!-- NOT SET ON CLI PUBLISH -->
<Copyright>me and a company</Copyright>
<!-- NOT SET ON CLI PUBLISH -->
<Product>xxx - Virtual Marketplace</Product>
<UserSecretsId>REDACTED</UserSecretsId>
</PropertyGroup>
<PropertyGroup>
<LangVersion>latest</LangVersion>
<TargetFramework>netcoreapp3.1</TargetFramework>
<RootNamespace>Vmp</RootNamespace>
<!-- NOT SET ON CLI PUBLISH -->
<NeutralLanguage>en-150</NeutralLanguage>
<!-- NOT SET ON CLI PUBLISH -->
<Company>REDACTED</Company>
<!-- NOT SET ON CLI PUBLISH -->
<Description>blahblah</Description>
<AssemblyName>vmp</AssemblyName>
</PropertyGroup>
My FolderProfile.pubxml:
<?xml version="1.0" encoding="utf-8"?>
<!--
https://go.microsoft.com/fwlink/?LinkID=208121.
-->
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<DeleteExistingFiles>True</DeleteExistingFiles>
<ExcludeApp_Data>False</ExcludeApp_Data>
<LaunchSiteAfterPublish>True</LaunchSiteAfterPublish>
<LastUsedBuildConfiguration>Debug</LastUsedBuildConfiguration>
<LastUsedPlatform>Any CPU</LastUsedPlatform>
<PublishProvider>FileSystem</PublishProvider>
<PublishUrl>D:\publish</PublishUrl>
<WebPublishMethod>FileSystem</WebPublishMethod>
<SiteUrlToLaunchAfterPublish />
<TargetFramework>netcoreapp3.1</TargetFramework>
<RuntimeIdentifier>win-x64</RuntimeIdentifier>
<PublishSingleFile>True</PublishSingleFile>
<ProjectGuid>2601011b-106e-44fa-b768-77874e85f475</ProjectGuid>
<SelfContained>true</SelfContained>
</PropertyGroup>
</Project>
This seems too easy to find to be a bug to me.
Difference between publish command on linux VS Visual Studio: (You can also see, that the archive I downloaded has the correct version.)
Sorry, seems like a duplicate of #4127 / dotnet/runtime#3828 (or at least my part)
This needs more attention.
I'm unable to create a single file executable, because of this bug.
My companies has a policy that every executable needs a ProgramVersion (and FileVersion) along with a digital Signature.
@ckuetbach can you check again with .NET 8 RC1? In August the runtime was updated to enable generating win32 resources from non-Windows hosts in this PR, so I'm hopeful this is resolved.
@baronfel I can confirm, that this issue is gone in .NET 8 RC2, because I just installed that version.
I can also confirm that after updating .NET from version 6 to 8, this issue has been resolved. Now, when I build a .NET application inside a Linux container with the parameters '-os win --self-contained,' it produces the correct metadata information for the exe file.
Same problem occured when building inside a Windows Container on a Windows Machine e.g. mcr.microsoft.com/dotnet/sdk:6.0-windowsservercore-ltsc2022
. Any chance the mentioned fix gets backported?
Same problem occured when building inside a Windows Container on a Windows Machine e.g.
mcr.microsoft.com/dotnet/sdk:6.0-windowsservercore-ltsc2022
. Any chance the mentioned fix gets backported?
Very little chance - this work was done on the runtime and isn't security related so I'll likely not be backported.
I created a console project and edit .csproj like this:
After publishing the project, check the generated
exe
file, the has no details.If I publish it with vs2019, it generate right details.
What should I do this with dotnet cli ??