Add AngouriMath.Terminal to NuGet publishing workflow and use ProjectReference for internal dependencies

[Copilot]

The NuGet workflow publishes AngouriMath, AngouriMath.FSharp, and AngouriMath.Interactive but not AngouriMath.Terminal, which uses a separate TerminalNightly workflow for binary releases only.

Changes

• .github/workflows/Nuget.yml: Added publishing step for AngouriMath.Terminal following the pattern of other packages. Publishes to MyGet on master pushes and NuGet.org on releases.

• Sources/Terminal/AngouriMath.Terminal/AngouriMath.Terminal.fsproj: Removed hardcoded <Version>1.4.0-preview.3-2</Version> to align with other packages. Now inherits version from Package.Build.props or workflow override via -p:PackageVersion.

• Sources/Wrappers/AngouriMath.FSharp/AngouriMath.FSharp.fsproj: Replaced PackageReference with ProjectReference to AngouriMath. Changed from <PackageReference Include="AngouriMath" Version="1.4.0-preview.3" /> to <ProjectReference Include="..\..\AngouriMath\AngouriMath.csproj" />.

• Sources/Wrappers/AngouriMath.Interactive/AngouriMath.Interactive.fsproj: Replaced PackageReference with ProjectReference to AngouriMath.FSharp. Changed from <PackageReference Include="AngouriMath.FSharp" Version="1.4.0-preview.3" /> to <ProjectReference Include="..\AngouriMath.FSharp\AngouriMath.FSharp.fsproj" />.

Notes

The TerminalNightly workflow continues to produce standalone binaries for the AngouriMathLab repository independently.

All internal dependencies now consistently use ProjectReference, which simplifies dependency management and ensures that local changes are always used during builds. This follows the same pattern already used by AngouriMath.Terminal.

Original prompt

It seems that the NuGet workflow didn't publish AngouriMath.Terminal. It seems to use a different workflow - TerminalNightly. It should be incorporated somehow.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[Happypig375]

@copilot Are there other hardcoded versions that should be removed?

[Copilot]

@copilot Are there other hardcoded versions that should be removed?

Yes, there are hardcoded dependency versions in PackageReference tags that are outdated:

1. AngouriMath.FSharp.fsproj (line 35): AngouriMath Version="1.4.0-preview.3" - should be 1.4.0-preview.4
2. AngouriMath.Interactive.fsproj (line 42): AngouriMath.FSharp Version="1.4.0-preview.3" - should be 1.4.0-preview.4
3. AngouriMath.CPP.Exporting.csproj: AngouriMath Version="1.4.0-preview.2" - very outdated, but this package isn't published via the NuGet workflow

These are different from the <Version> tag I removed (which defines the package's own version). These PackageReference versions define which version of dependencies to use when building as standalone NuGet packages.

However, since the NuGet workflow builds packages in dependency order and uses ProjectReference during the build, these hardcoded versions don't affect the workflow. They would only matter if someone tried to build the packages independently from NuGet.

Should I update these PackageReference versions to match Package.Build.props (1.4.0-preview.4)?

[Happypig375]

@copilot Update them to directly use the version in Package.Build.props and add a comment there that it won't affect CI builds.

[Copilot]

@copilot Update them to directly use the version in Package.Build.props and add a comment there that it won't affect CI builds.

Updated in commit 0de4b60. Changed:

• AngouriMath.FSharp.fsproj: AngouriMath Version="1.4.0-preview.3" → Version="$(Version)"
• AngouriMath.Interactive.fsproj: AngouriMath.FSharp Version="1.4.0-preview.3" → Version="$(Version)"

Added comment: "Using $(Version) from Package.Build.props. This won't affect CI builds as they use ProjectReference."

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• 0t3vsblobprodcus362.vsblob.vsassets.io
  • Triggering command: /usr/bin/dotnet dotnet msbuild Sources/Wrappers/AngouriMath.FSharp/AngouriMath.FSharp.fsproj /t:Restore /p:Configuration=Release -nologo (dns block)
• www.myget.org
  • Triggering command: /usr/bin/dotnet dotnet msbuild Sources/Wrappers/AngouriMath.FSharp/AngouriMath.FSharp.fsproj /t:Restore /p:Configuration=Release -nologo (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

[Happypig375]

@copilot Actually, just replace it with a project reference - it seems easier to manage anyway.

[Copilot]

@copilot Actually, just replace it with a project reference - it seems easier to manage anyway.

Done in commit c2489cc. Replaced PackageReference with ProjectReference:

• AngouriMath.FSharp.fsproj: Now uses <ProjectReference Include="..\..\AngouriMath\AngouriMath.csproj" />
• AngouriMath.Interactive.fsproj: Now uses <ProjectReference Include="..\AngouriMath.FSharp\AngouriMath.FSharp.fsproj" />

All internal dependencies now consistently use ProjectReference, which is simpler to manage.