[dotnet] Blog post about strong naming

[nvborisenko]

To be loud for 1% of users.

Description

This pull request adds a new blog post announcing that, starting with Selenium 4.44, the main .NET NuGet packages (Selenium.WebDriver and Selenium.Support) are now strongly signed. The separate StrongNamed packages are discontinued, simplifying package usage for teams requiring strong naming.

Key updates:

.NET Strong Name Signing Announcement:

• Added a new blog post, dotnet-strong-name-signing.md, detailing that Selenium.WebDriver and Selenium.Support NuGet packages are now strongly signed with the project's key, and the separate StrongNamed packages are retired.
• The post explains migration steps for users of the old StrongNamed packages and provides context on why this change matters for enterprise and strongly signed projects.
• Related issues and implementation pull request are referenced for further information.

Types of changes

• Change to the site (I have double-checked the Netlify deployment, and my changes look good)
• Code example added (and I also added the example to all translated languages)
• Improved translation
• Added new translation (and I also added a notice to each document missing translation)

Checklist

• I have read the contributing document.
• I have used hugo to render the site/docs locally and I am sure it works.

[netlify]

👷 Deploy request for selenium-dev pending review.

Visit the deploys page to approve it

Name	Link
🔨 Latest commit	d9b266e

[qodo-code-review]

Review Summary by Qodo

Add blog post announcing .NET strong name signing

📝 Documentation

Walkthroughs

Description

• Announces strong name signing for .NET NuGet packages
• Starting with Selenium 4.44, main packages now strongly signed
• Separate StrongNamed packages discontinued, simplifying usage
• Provides migration guide for existing StrongNamed package users

Diagram

flowchart LR
  A["Selenium 4.44"] -->|"Strong Name Signing"| B["Selenium.WebDriver"]
  A -->|"Strong Name Signing"| C["Selenium.Support"]
  D["StrongNamed Packages"] -->|"Deprecated"| E["Migration Guide"]
  B --> F["Enterprise Projects"]
  C --> F

Loading

File Changes

1. website_and_docs/content/blog/2026/dotnet-strong-name-signing.md 📝 Documentation +46/-0

Blog post on .NET strong name signing announcement

• New blog post announcing strong name signing for .NET NuGet packages
• Explains rationale for strong naming in enterprise environments
• Documents assembly name and version compatibility details
• Provides step-by-step migration guide from StrongNamed packages
• References related GitHub issues and implementation PR

website_and_docs/content/blog/2026/dotnet-strong-name-signing.md

---

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0)

1. Future post not built 🐞 Bug ☼ Reliability

Description

The new blog post sets date: 2026-04-27, but the site build runs hugo --minify without enabling
future content, so the post will be omitted from generated output until that date. This makes the
post invisible in Netlify previews/production builds prior to 2026-04-27.

Code

website_and_docs/content/blog/2026/dotnet-strong-name-signing.md[4]

+date: 2026-04-27

Evidence

The post is explicitly future-dated, and the repo’s build script invokes Hugo without any
option/config shown to include future-dated content; therefore this content won’t render in the
built site until its publish date under Hugo’s default behavior.

website_and_docs/content/blog/2026/dotnet-strong-name-signing.md[1-5]
build-site.sh[42-44]
Best Practice: Hugo documentation (future-dated content behavior)

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`website_and_docs/content/blog/2026/dotnet-strong-name-signing.md` is dated in the future (`2026-04-27`). The repo build runs `hugo --minify` without `--buildFuture`, so Hugo will omit the post from the generated site until that date.

### Issue Context
If the intent is for the post to be visible immediately (including in Netlify deploy previews), the build must include future content or the post date must not be in the future.

### Fix Focus Areas
- website_and_docs/content/blog/2026/dotnet-strong-name-signing.md[1-5]
- build-site.sh[42-44]

### Suggested fix options
- **Option A (publish now):** Change the post frontmatter `date` to today or earlier.
- **Option B (keep scheduled date but preview/build it):** Add Hugo `--buildFuture` (or equivalent config) in the relevant build contexts (e.g., deploy previews), while keeping production behavior as desired.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

[rpallavisharma]

this looks fine to me. very informative and well written blog article.