Replace vendored source files and legacy build dependencies

Motivation

paket.dependencies still contains several unusual dependencies: individual source files and a binary downloaded from GitHub, a private/legacy package feed, a 2017 prerelease documentation package, and a pre-SDK reference-assembly package.

These entries were reasonable compatibility measures when introduced, and some deliberately dogfood Paket's GitHub-file support, but they now make restore depend on old repositories/feeds and make ownership, updates, licensing and security review harder. We should migrate them to maintained packages, standard SDK tooling, or small repository-owned implementations where necessary.

This is an umbrella issue. The entries have different risk levels and should normally be changed in separate PRs.

Inventory and proposed path

Production source dependencies

• github fsharp/FAKE:0341a2e... src/app/FakeLib/Globbing/Globbing.fs

  • Compiled directly into Paket.Core and used by NupkgWriter, TemplateFile and PublicAPI for isMatch/search behavior.
  • Added in 2015 for wildcard support in #690.
  • Replace with a maintained globbing package compatible with all Paket targets, or a small repository-owned implementation of the required semantics. Preserve existing wildcard behavior with focused tests before removing the remote source file. The current Microsoft.Extensions.FileSystemGlobbing package is a candidate, but compatibility with net461 and FAKE's exact glob semantics must be verified.

• github fsprojects/FSharp.TypeProviders.SDK:dc5ac01... src/AssemblyReader.fs

  • Compiled directly into Paket.Core. It supplies assembly references, custom-attribute decoding and SHA1 helpers used by install, package metadata, dependency cache and platform matching code.
  • Replace the metadata-reading portions with System.Reflection.Metadata/PEReader or another maintained API, and replace the hashing helpers with System.Security.Cryptography. This is the highest-risk item and needs regression coverage for binding redirects, assembly metadata and package metadata.

Test source dependency

• github forki/FsUnit FsUnit.fs
  • Compiled directly into both test projects and used throughout the unit and integration suites.
  • It was introduced in 2014 to dogfood Paket's GitHub-file feature, not because a source-file dependency is intrinsically required.
  • Prefer a normal test package if one supports both net461 and net9; otherwise migrate assertions to NUnit or keep a minimal repository-owned compatibility module while the net461 test target remains. The current FsUnit release targets .NET 6+, so this cannot be a blind package upgrade.

Documentation dependencies

• source https://ci.appveyor.com/nuget/fsharp-formatting
• nuget FSharp.Formatting prerelease (currently locked to 3.0.0-beta09)
  • These are active: docs/tools/generate.fsx loads the package's old FSharp.Formatting.fsx and Razor/metadata APIs.
  • Migrate documentation generation to the current stable FSharp.Formatting/fsdocs tooling from NuGet.org, then remove the AppVeyor feed, prerelease package and old Razor-specific build dependencies that become unused.
  • Compare generated command help, prose docs and API reference output before switching.

Release automation

• github fsharp/FAKE modules/Octokit/Octokit.fsx
  • Loaded by build.fsx for the ReleaseGitHub target and brings in Octokit 0.29.
  • Replace with a token-based GitHub Actions/gh release workflow, or a maintained Octokit package if release logic remains in .NET code. This should align with #4348 rather than preserving interactive username/password handling.

Framework reference assemblies

• nuget 0x53A.ReferenceAssemblies.Paket 0.2.0
  • Not dead: root Directory.Build.props points TargetFrameworkRootPath at this package for cross-platform .NET Framework builds.
  • It was added in 2017 to make clean builds work before official reference-assembly packages were available.
  • Replace it with the official Microsoft.NETFramework.ReferenceAssemblies.net461 package already declared/referenced by the repository, remove the global custom TargetFrameworkRootPath, and verify net461 restore/build/test on Windows and Linux/Mono.

Windows executable icon

• github enricosada/add_icon_to_exe:e11eda... rh/ResourceHacker.exe
  • Used after ILRepack to add paket.ico to the merged net461 executable; it worked around dotnet/fsharp#1172.
  • The upstream compiler issue was closed as fixed in 2020. Test SDK/F# compiler icon/resource support on the final merged executable (ILRepack may affect resources), then remove the downloaded executable if the resulting paket.exe retains the expected icon. If post-link injection is still required, use a maintained, reproducibly acquired tool rather than a pinned binary source file.

Suggested order

• Add characterization tests for glob matching/search and assembly metadata behavior.
• Replace 0x53A.ReferenceAssemblies.Paket and validate clean net461 builds on Linux and Windows.
• Migrate documentation to current fsdocs/FSharp.Formatting and remove the AppVeyor feed.
• Replace the FsUnit source file without losing net461 test coverage.
• Replace/integrate the globbing implementation.
• Replace AssemblyReader.fs incrementally, starting with SHA1 helpers and then metadata reading.
• Replace Octokit release automation as part of #4348.
• Verify native icon support after ILRepack and remove ResourceHacker if possible.

Acceptance criteria

• None of the eight entries listed above remain in paket.dependencies or paket.lock.
• Paket.Core no longer compiles source downloaded from unrelated GitHub repositories.
• Test projects no longer compile a floating GitHub source file.
• Restore uses only documented, maintained package sources; the AppVeyor feed is gone.
• Linux and Windows CI retain the complete net461 and modern .NET build/test coverage.
• Globbing, assembly inspection, binding redirect and package metadata behavior have regression coverage.
• Generated docs and release artifacts retain required content and layout.
• The merged Windows paket.exe still has the expected icon without an opaque downloaded executable.
• Each replacement has its license and update mechanism represented normally in the repository dependency model.

Notes

Test fixtures and documentation examples that mention FAKE, FsUnit or FSharp.Formatting should remain where they exercise Paket behavior; this issue concerns the repository's own build, product and test dependencies, not example package names.

Related: #4348, #4002, #690

Start by selecting one inventory item in paket.dependencies and reading its referenced entry point, such as docs/tools/generate.fsx, build.fsx, Directory.Build.props, or the affected test projects. Run the relevant build, documentation, or test command before changing anything, then verify that the selected dependency is removed without losing its documented behavior or target coverage.