[ayuthmang]

Summary

Adds a CI pipeline that builds MemoryX.sln on Windows, and fixes the two things that stopped a clean-checkout build from succeeding.

Both matrix legs are green on 763e1cb.

Changes

.github/workflows/build.yml (new)

Builds the solution on windows-latest in a Debug / Release matrix and uploads the compiled output as artifacts. Triggers on pushes to master, pull requests into master, and manual dispatch.

It uses MSBuild rather than dotnet build because both projects use the legacy non-SDK .csproj format, which the dotnet CLI does not support. (The existing CircleCI config runs dotnet build, which is why it cannot work — see Follow-up below.)

Reference assemblies. The hosted image now ships Visual Studio 18, which no longer includes the .NET Framework 4.5.2 targeting pack, so MSBuild fails with MSB3644. The pipeline therefore downloads Microsoft.NETFramework.ReferenceAssemblies.net452 (pinned to 1.0.3) and points MSBuild at it via TargetFrameworkRootPath — the property that GetReferenceAssemblyPaths, the task raising MSB3644, actually consumes.

This was chosen over the alternatives deliberately:

Option	Assessment
Retarget to v4.8	Raises the minimum framework for library consumers — a maintainer's decision, not something a CI change should do silently
Pin windows-2022	Temporary; that image is being retired and VS 18 will become universal
Reference assemblies package	Keeps the v4.5.2 target exactly as-is, works on any runner regardless of installed targeting packs, and does not affect Visual Studio builds

The step locates the .NETFramework\v4.5.2 folder inside the downloaded package rather than hard-coding its internal layout, and fails with an explicit message if it is absent.

MemoryXTest/MemoryXTest.csproj

The test project referenced the library through a hard-coded path to build output:

<Reference Include="MemoryX">
  <HintPath>..\MemoryX\bin\Debug\MemoryX.dll</HintPath>
</Reference>

That file does not exist on a fresh checkout, and in a Release build the library outputs to bin\Release\ instead, so reference resolution fails (MSB3245) and every MemoryX.Memory usage in Program.cs fails to compile (CS0246).

Replaced with a proper <ProjectReference>, which resolves per configuration and lets MSBuild handle build ordering. The now-redundant ProjectDependencies section in MemoryX.sln was left untouched, as it is harmless.

README.md

Adds a build status badge.

Testing

The workflow could not be run locally — this project needs Windows MSBuild for .NET Framework 4.5.2 — so CI on this PR is the verification.

The first run failed both legs with MSB3644, which is what surfaced the missing targeting pack; 763e1cb fixes it. The current run confirms the reference assemblies resolve and both projects compile in both configurations:

TARGET_FRAMEWORK_ROOT_PATH: ...\packages\Microsoft.NETFramework.ReferenceAssemblies.net452\build
  MemoryX     -> ...\MemoryX\bin\Release\MemoryX.dll
  MemoryXTest -> ...\MemoryXTest\bin\Release\MemoryXTest.exe

The MemoryXTest line is the direct confirmation of the ProjectReference fix, since Release is the configuration that would previously have failed.

One pre-existing warning is reported and left alone, as it is unrelated to this change:

MemoryX\Memory.cs(228,30): warning CS0168: The variable 'ex' is declared but never used

Follow-up (not in this PR)

.circleci/config.yml runs dotnet build, which cannot build these legacy projects — that pipeline is broken and is now redundant. Removing .circleci/ in a separate change would be my suggestion, but it is left alone here to keep this PR focused.

🤖 Generated with Claude Code

https://claude.ai/code/session_01SKZ2gugmpaYSHPS7LR5Xjg

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.