Hi.WpfPlus

Author	SHA1	Message	Date
iambossandClaude Opus 5	60dea348d2	chore(Hi.WpfPlus): bump VersionBuild to 3.1.160 Carried over from a deploy.py run -- incrementPackageID bumps VersionBuild but deploy.py only auto-commits HiAPI-docsite-2025. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-05 20:11:15 +08:00
iambossandClaude Opus 5	85d5515a97	build(Hi.WpfPlus): keep the package line on 3.1 and resume the build counter The 3.2 line is retracted -- the major version stays fixed for commercial positioning, so 3.1 remains the development line. Version stamp only; no code changed on the way out or back. VersionBuild resumes at 158, where it stood before the detour, instead of restarting from the 143 the feed serves. Everything between was built locally and stamped into real assemblies even though deploy.py deliberately withholds the upload until the API has settled commercially, and re-minting a spent number with different code is the one failure that yields two Hi.WpfPlus.dll claiming the same version. Next upload is 3.1.159; the 143 -> 159 gap on the feed is intended. 3.2.1 was packed locally and never uploaded, so nothing outside this machine saw the 3.2 line at all. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-01 14:27:48 +08:00
iambossandClaude Opus 5	c25bd820c3	build(Hi.WpfPlus): start the 3.2 package line and restart VersionBuild The 3.1 line ends at Hi.WpfPlus 3.1.143 -- tag v3.1.143, part of the aligned hinc-suite/3.1.175 set. master now produces 3.2 and VersionBuild restarts at 0, so the first published 3.2 package is 3.2.1: IncrementPackageID.targets bumps before the build, not after it. The 3.1.158 stamp this replaces was a local increment from a deploy run whose upload step is commented out, so it never reached the feed and nothing depends on it. Fixes for customers pinned to 3.1 come off the support/3.1 branch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 18:00:18 +08:00
iambossandClaude Opus 4.8	a5a778fb1c	chore(Hi.WpfPlus): bump VersionBuild Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-13 12:36:47 +08:00
iamboss	f9a85f0e33	tune.	2026-07-07 18:52:21 +08:00
iamboss	2097cc6bb3	deploy fixed MRR drift and webservice CylindroidHolder buckle branch update issue.	2026-05-28 20:20:39 +08:00
iamboss	277c87ad3d	deploy fixed MRR drift and webservice CylindroidHolder buckle branch update issue.	2026-05-28 19:34:22 +08:00
iambossandClaude Opus 4.7	c1b86be4aa	fix(Hi.WpfPlus): drop stale using Google.Protobuf.WellKnownTypes WpfDispUtil.cs carried a stale `using Google.Protobuf.WellKnownTypes;` with zero matching symbol usage in the file body — it resolved only because HiGeom used to re-export Google.Protobuf transitively via its now-removed Grpc.Tools / Google.Protobuf PackageRefs. CS0246 on 'Google' once that transitive bring-in went away. VersionBuild bump 140→141 rides along for the NuGet republish. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-28 18:57:12 +08:00

2 changed files with 1 additions and 2 deletions

									
										Disp/WpfDispUtil.cs
									
		-1
	
												View File
												
				@@ -1,4 +1,3 @@

				using Google.Protobuf.WellKnownTypes;

				using Hi.Disp;

				using Hi.Geom;

				using Hi.Licenses;

									
										Hi.WpfPlus.csproj
									
		+1
		-1
	
												View File
												
				@@ -12,7 +12,7 @@

							HiAPI wpf canvas.

						</Description>

				    <Configurations>Debug;Release</Configurations>

				    <VersionBuild>140</VersionBuild>

				    <VersionBuild>160</VersionBuild>

				    <VersionPrefix>3.1.$(VersionBuild)</VersionPrefix>

				    <PackageId>Hi.WpfPlus</PackageId>

				    <PackageTags>HiAPI</PackageTags>

Compare commits