Update/remove the .NET 4 note saying "<generatePublisherEvidence>" has no effect on assembly load times.

[DougSchmidt-AI]

In the Remarks section of the generatePublisherEvidence element page. there is a big blue warning note saying "In the .NET Framework 4 and later, this element has no effect on assembly load times."

That statement is not true (or at least, is not always true).

In our .NET 4.7 desktop app, we have needed to add <generatePublisherEvidence enabled="false"/> to the *.exe.config files for all of our signed executables, in order to prevent 30-40 launch delays when a system is behind an HTTP proxy and the servers hosting certificate revocation lists are not reachable.

Without the magic XML in the App.config file, the assembly is delayed for 40-seconds while the OS tries to reach out to OCSP and CRL endpoints to figure out if the app's certificate has been invalidated.

Some of our executables are Windows Services, so causing these startup delays is definitely something to avoid. In fact there is already a note saying "We recommend you disable this feature for Windows services", which seems to go directly against the "This setting doesn't apply to .NET 4 or greate" note.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 4a579a8e-74fd-a86e-8e80-78719c9b1b4e
• Version Independent ID: 56f18e1d-69fe-4423-23ad-29d7d5bce914
• Content: <generatePublisherEvidence> Element
• Content Source: docs/framework/configure-apps/file-schema/runtime/generatepublisherevidence-element.md
• Product: dotnet-framework
• GitHub Login: @rpetrusha
• Microsoft Alias: ronpet

[BillWagner]

Thank you for pointing this out @DougSchmidt-AI

We've added it to our backlog.

[kapsiR]

It would be great, if there would be any clarification how this actually works.
What's the behavior if referenced assemblies does have a different .NET version?

Remarks of Publisher Class:

By default, code access security (CAS) does not check for Publisher evidence. Unless your computer has a custom code group based on the PublisherMembershipCondition class, you can improve performance by bypassing Authenticode signature verification.

The legacy security policy and the Code Access Security Policy Tool (Caspol.ex):

Specifies whether the runtime uses legacy code access security (CAS) policy.

Starting with the .NET Framework 4, Caspol.exe does not affect CAS policy unless the element is set to true. Any settings shown or modified by CasPol.exe will only affect applications that opt into using CAS policy.

Security Changes in the .NET Framework 4, especially Evidence Collections in this article:

Before the .NET Framework 4, the CLR generated the full set of evidence objects that applied to an assembly when the assembly was loaded. These objects were stored in a list, which consumers would then iterate over looking for a specific object. Therefore, all evidence was made available, whether or not it was used. For most evidence objects, this behavior was not an issue; however, for evidence objects such as System.Security.Policy.Publisher (which requires Authenticode verification), this behavior was inefficient.

To improve this behavior, the interaction with the evidence collection has been redesigned in .NET Framework 4. An evidence collection now behaves like a dictionary instead of a list. Instead of iterating over the evidence collection to see if a required evidence object exists, consumers can now request a specific type of evidence, and the collection returns the evidence if it is found. For example, the call StrongName name = evidence.GetHostEvidence(); returns a StrongName object if one exists; otherwise, it returns null.

This dictionary model delays the generation of evidence objects until they are requested. In the Publisher evidence example, the performance overhead of verifying the Authenticode signature of an assembly is delayed until that information is needed. In the most common case of full-trust applications where Publisher evidence is not needed, the verification process is avoided altogether.

[dotnet-bot]

This issue has been closed as part of the issue backlog grooming process outlined in #22351.

That automated process may have closed some issues that should be addressed. If you think this is one of them, reopen it with a comment explaining why. Tag the @dotnet/docs team for visibility.

[kapsiR]

Please reopen this to update the documentation accordingly

/cc @BillWagner

[BillWagner]

reopening per comment.