How can I embed a valid publisher name in executables for .NET and .NET Core apps using Visual Studio 2022?

Below is some background and guidance that might put you on the right track.

---

What’s Happening

When Windows Defender (or another security product) shows a publisher name of “Unknown” on your application, it isn’t reading a Visual Studio–specific project property. In both .NET Framework and .NET Core apps, the publisher information that Windows displays comes from the digital signature embedded in the executable. In your case, the “Publisher Name” you see in the project properties for a .NET Framework ClickOnce project is used only for deployment purposes (for example, when installing an application via ClickOnce) and does not automatically become the embedded trusted publisher in the executable’s manifest.

---

Overcoming the Restriction

1. Organizational Policy vs. Technical Issue:
   The restriction you’ve described is an enforced infosec policy that blocks unsigned or unknown-signed executables. In similar cases, teams have worked with their security groups to obtain an approved code-signing certificate. Once you sign the executable with this certificate (which includes a publisher name like “Microsoft” or “OrgName”), the signature shows as trusted and the file is allowed to run.

2. How to Sign Your Executable:
   Instead of relying on the project property “Publisher Name” (which only affects ClickOnce publishing), the solution is to digitally sign your executable using a valid Authenticode certificate. Once signed, Windows will read the publisher information from the certificate and show that name (e.g., “OrgName”) in Defender alerts and other security prompts.

---

Signing in .NET Framework and .NET Core

.NET Framework

For a .NET Framework project, you may already see the option for signing in the project properties. However, note that:

• The “Signing” tab’s options (and the ClickOnce “Publisher Name”) do not affect the Authenticode signature.
• To get the proper publisher display on the final EXE, you need to sign the executable with a certificate—this can be done as part of your build process.
• Many teams use Visual Studio’s post-build events or integrate signtool into their build pipeline. For example, a post-build step might look like:

BATCHCopied
signtool sign /f "path\to\your-cert.pfx" /p YourPfxPassword /tr http://timestamp.url /td sha256 /fd sha256 "$(TargetPath)"

This command takes the built executable (from the debug folder, for example) and signs it. The certificate itself holds the publisher’s name that Windows Defender will read.

.NET Core

For .NET Core projects, the process is similar but with one difference: the project properties in Visual Studio don’t expose a “Publisher Name” or signing option that affects the final executable’s digital signature. To get your executable signed:

• Create an application manifest (if needed) and include it in the project. This is done by placing an “app.manifest” file in your project and referencing it from your project file (using the <ApplicationManifest> MSBuild property).

• Digitally sign the executable post-build.
  Just like with .NET Framework, use a post-build event or integrate a signing step into your CI/CD pipeline with signtool. For example, you can add the following to your project file:

XMLCopied
<Target Name="SignAssembly" AfterTargets="Build" Condition="'$(Configuration)' == 'Debug'">
  <Exec Command="signtool sign /f &quot;path\to\your-cert.pfx&quot; /p YourPfxPassword /tr http://timestamp.url /td sha256 /fd sha256 &quot;$(TargetPath)&quot;" />
</Target>

This instructs MSBuild to sign the generated executable after building.

---

Summary of Recommendations

• Talk with Security/Windows Team:
  Verify that the only acceptable approach is to have the publisher show as “Microsoft” or an approved organization. Ask whether a code-signing certificate is available for your developers or if you need to go through a particular process.

• Apply Authenticode Signing:
  Once you have an approved certificate (whether it’s “Microsoft” or “OrgName”), update your build process (for both .NET Framework and .NET Core projects) to perform digital signing of the output executable using signtool.

• Embed the Manifest (if needed):
  If your organizational guidelines require certain manifest properties to be set, include an application manifest file in your project and ensure it’s embedded into the executable.

By following these steps, your executables will have the trusted publisher information embedded, which should satisfy the infosec guidelines and allow you to debug within Visual Studio.

---

This approach is commonly used when organizational policies demand that executables are properly signed with an approved certificate. It addresses both the .NET Framework and .NET Core scenarios.