Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue with 'AfterTargets="Publish"' and PublishAot #109414

Closed
SCLDGit opened this issue Oct 31, 2024 · 3 comments
Closed

Issue with 'AfterTargets="Publish"' and PublishAot #109414

SCLDGit opened this issue Oct 31, 2024 · 3 comments

Comments

@SCLDGit
Copy link

SCLDGit commented Oct 31, 2024

Description

We have a build target similar to the following in our project file:

<Target Name="SignPublishExe" AfterTargets="Publish" Condition="'$(Configuration)'=='Signed Release'">
    <Exec Command="&quot;C:\Path\To\signtool.exe&quot; sign /tr http://timestamp.digicert.com /td sha256 /fd sha256 /f &quot;C:\Path\To\Certificate.cer&quot; /csp &quot;eToken Base Cryptographic Provider&quot; /kc &quot;[{{$(signing_key_pass)}}]=$(signing_key_id)&quot; &quot;\\?\$(PublishDir)$(TargetName).exe&quot;" />
  </Target>

It is intended to sign our published exe automatically after build. It works properly for all of our projects, except for our most recent addition, which uses PublishAot. The console output shows that the signing was successful, but upon inspection, the file in the actual publish location is not signed.

It appears that, at some point after the AfterTargets="Publish" step has completed in the build process, the file written to the location specified with the --output is overwritten by the executable that is created in the bin/x64/native directory. If we hardcode a build target to sign that file before the publish step, the executable in the --output location at the end of the process is signed.

Is there a separate build target for properly targeting this file? If not, how might we replace \\?\$(PublishDir)$(TargetName).exe in order to properly create a new build target for the executable in the native directory without having to hardcode the path in our .csproj files?

Reproduction Steps

1.) Create a project that makes use of PublishAot.
2.) Add the specified build target to the .csproj file.
3.) Run dotnet publish --output "Some/Path".

Expected behavior

Final output exe should be signed

Actual behavior

After the successful signing step, the executable is replaced with an unsigned copy of the executable from the native bin directory

Regression?

No response

Known Workarounds

Hardcode the path to the native executable and add an additional signing AfterTargets="Build" target that signs that exe prior to the AfterTargets="Publish" target.

Configuration

.NET 8
Windows 10 and 11
x64

Other information

No response

@dotnet-issue-labeler dotnet-issue-labeler bot added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Oct 31, 2024
@dotnet-policy-service dotnet-policy-service bot added the untriaged New issue has not been triaged by the area owner label Oct 31, 2024
@SCLDGit
Copy link
Author

SCLDGit commented Oct 31, 2024

Duplicate of dotnet/sdk#39549, which has a solution.

@jkotas jkotas removed the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Oct 31, 2024
Copy link
Contributor

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

@MichalStrehovsky
Copy link
Member

We don't have any documented way to do this. What you got will probably work for .NET8/9.

We have open issues (known bugs) on how AOT compilation hooks up into publish infrastructures and we're going to standardize it with how PublishSingleFile and PublishTrimmed works (#108909). Closing as a duplicate of that.

@MichalStrehovsky MichalStrehovsky closed this as not planned Won't fix, can't repro, duplicate, stale Nov 2, 2024
@dotnet-policy-service dotnet-policy-service bot removed the untriaged New issue has not been triaged by the area owner label Nov 2, 2024
@github-actions github-actions bot locked and limited conversation to collaborators Dec 2, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
Archived in project
Development

No branches or pull requests

3 participants