You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
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 Investigate removing FAKE from the build #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.
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.
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.
Motivation
paket.dependenciesstill 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.fsPaket.Coreand used byNupkgWriter,TemplateFileandPublicAPIforisMatch/searchbehavior.Microsoft.Extensions.FileSystemGlobbingpackage is a candidate, but compatibility withnet461and FAKE's exact glob semantics must be verified.github fsprojects/FSharp.TypeProviders.SDK:dc5ac01... src/AssemblyReader.fsPaket.Core. It supplies assembly references, custom-attribute decoding and SHA1 helpers used by install, package metadata, dependency cache and platform matching code.System.Reflection.Metadata/PEReaderor another maintained API, and replace the hashing helpers withSystem.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.fsnet461andnet9; otherwise migrate assertions to NUnit or keep a minimal repository-owned compatibility module while thenet461test 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-formattingnuget FSharp.Formatting prerelease(currently locked to3.0.0-beta09)docs/tools/generate.fsxloads the package's oldFSharp.Formatting.fsxand Razor/metadata APIs.Release automation
github fsharp/FAKE modules/Octokit/Octokit.fsxbuild.fsxfor theReleaseGitHubtarget and brings in Octokit 0.29.ghrelease workflow, or a maintained Octokit package if release logic remains in .NET code. This should align with Investigate removing FAKE from the build #4348 rather than preserving interactive username/password handling.Framework reference assemblies
nuget 0x53A.ReferenceAssemblies.Paket 0.2.0Directory.Build.propspointsTargetFrameworkRootPathat this package for cross-platform .NET Framework builds.Microsoft.NETFramework.ReferenceAssemblies.net461package already declared/referenced by the repository, remove the global customTargetFrameworkRootPath, and verifynet461restore/build/test on Windows and Linux/Mono.Windows executable icon
github enricosada/add_icon_to_exe:e11eda... rh/ResourceHacker.exepaket.icoto the mergednet461executable; it worked around Coreclr compiler does not embed native resources, E.g icons for vs dotnet/fsharp#1172.paket.exeretains 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
0x53A.ReferenceAssemblies.Paketand validate cleannet461builds on Linux and Windows.net461test coverage.AssemblyReader.fsincrementally, starting with SHA1 helpers and then metadata reading.Acceptance criteria
paket.dependenciesorpaket.lock.net461and modern .NET build/test coverage.paket.exestill has the expected icon without an opaque downloaded executable.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