[Installer] Source and patch ownership conflict for API csproj

[LunarDiver]

Install method

bootstrap.sh / build from source

Platform

Linux

Updating from version

0.3.14

Installing or updating to version

0.3.15

Steps taken

1. Downloaded v0.3.15 source release
2. Ran install-linux.sh
3. Selected default options for everything
4. Error

Where it stopped

Baseline snapshot saved to .baseline/.

Full error output or log

==> Building Optimum...
bash scripts/bootstrap.sh --refresh --version 1.22.7
Using cached /home/luna/Downloads/Optimum-0.3.15/.vanilla/archives/vs_client_linux-x64_1.22.7.tar.gz
Extracting /home/luna/Downloads/Optimum-0.3.15/.vanilla/archives/vs_client_linux-x64_1.22.7.tar.gz
Decompiling VintagestoryLib.dll with ilspycmd: 10.1.1.8388
Decompiling Vintagestory.dll with ilspycmd: 10.1.1.8388
Cloning VintagestoryApi at 63d33f70018c606fb0f70ead900fe90625fbd7b2
Cloning Cairo at b5a93a4b3f68217f3185f8abaf131115773ea9e7
Cloning VSEssentials at 06673b67318e002332b6aa8b3d0308f11d2aba99
Cloning VSSurvivalMod at 849fa8cad9e392368566efc7474e73db6404a145
Cloning VSCreativeMod at 1c649719734ac5c049ce947a945847b2a07e9f59
Applying post-decompile fixups...
Post-decompile fixups done.
Rewrote base/this constructor calls in 1 file(s).
Restoring serialization metadata...
Serialization metadata restored.
Rewrote 0 event read(s) across 0 file(s).
Rewrote 0 value-type constructor call(s).
Ambiguity and decompiler-artifact fixups applied.
Saving post-fixup baseline snapshot...
Baseline snapshot saved to .baseline/.
ERROR: source and patch ownership conflict:
  VintagestoryApi/VintagestoryAPI.csproj
make: *** [Makefile:76: refresh] Error 1

Checks

• I read the Building from Source wiki page for my platform.

[LunarDiver]

I have also tried running the prebuilt installer for linux but it fails with the same error.

[JimmyMac3]

I also had this same problem on the Win x64 Setup.exe v0.3.15 (not upgrading)

I actually ran into several problems installing Optimum v0.3.15 on Windows. I was eventually able to complete the installation, so I wanted to document the failures and the workarounds that got it working.

Environment

• Windows x64
• Optimum v0.3.15
• .NET SDK 10.0.100
• SDK installed under %USERPROFILE%\.dotnet
• Git installed and available
• Vintage Story client was successfully downloaded/extracted by the installer

There were also two initial machine-specific prerequisite issues:

1. Git was not installed/on PATH.
2. PowerShell initially blocked bootstrap.ps1 because script execution was disabled.

Those were easy to resolve and are probably separate from the actual Optimum problems below.

1. Bootstrap fails with source/patch ownership conflict

The first Optimum-specific failure was:

Source and patch ownership conflict:
VintagestoryApi/VintagestoryAPI.csproj

The v0.3.15 tree appears to contain both:

sources/VintagestoryApi/VintagestoryAPI.csproj

and:

patches/VintagestoryApi/VintagestoryAPI.csproj.patch

The patch adds these two exclusions:

The bootstrap ownership check therefore aborts because the same target is owned by both sources and patches.

Workaround

I manually added those two <Compile Remove> entries to:

sources/VintagestoryApi/VintagestoryAPI.csproj

and renamed:

patches/VintagestoryApi/VintagestoryAPI.csproj.patch

so it was no longer processed.

After that, bootstrap completed successfully.

2. Build then fails on OptimumApiBridge.IsChiselTracked

The installer got much farther but dotnet build then failed with:

OptimumFrustumCullSimd.cs(312,33):
error CS0117: 'OptimumApiBridge' does not contain a definition for 'IsChiselTracked'

OptimumFrustumCullSimd.cs calls:

OptimumApiBridge.IsChiselTracked(location)

while IsChiselTracked is declared internal in optimum-api-bridge.cs.

I also noticed that optimum-api-contracts.csproj explicitly compiles several Optimum source files, including:

OptimumFrustumCullSimd.cs
OptimumKometGuard.cs
OptimumCompatibilityGuard.cs

but those files were not excluded from VintagestoryAPI.csproj.

Workaround

I added these exclusions to sources/VintagestoryApi/VintagestoryAPI.csproj:

along with the two exclusions from the previous workaround.

After doing that, the entire solution built successfully with:

101 Warning(s)
0 Error(s)

3. Packaging fails because runtime-donor build cannot find .NET SDK

After the main build succeeded, the installer reached packaging and failed while preparing the runtime donors.

The log showed:

Building exact runtime donors...
Building VSEssentials...

A compatible .NET SDK was not found.

Requested SDK version: 10.0.100

Installed SDKs:
No .NET SDKs were found.

and then the same failure occurred for VSSurvivalMod.

This was confusing because the installer had just successfully built the entire Optimum solution using .NET SDK 10.0.100.

The SDK on this PC is located at:

%USERPROFILE%.dotnet

The packaging script prepare-runtime-donors.ps1 appears to invoke:

dotnet build ...

directly, rather than reusing the explicit dotnet.exe path that the main installer/prerequisite detection had already found.

Workaround

Before launching Setup, I opened PowerShell and ran:

$env:DOTNET_ROOT="$env:USERPROFILE.dotnet"
$env:PATH="$env:DOTNET_ROOT;$env:PATH"

I verified:

dotnet --list-sdks

showed SDK 10.0.100.

Then I launched Optimum.Installer.exe from that same PowerShell session so the installer and its child PowerShell scripts inherited that PATH.

With that change, the runtime-donor packaging step succeeded and the installer completed successfully.

Possible fixes

From what I observed, v0.3.15 may need three changes:

1. Resolve the VintagestoryAPI.csproj source/patch ownership conflict, either by incorporating those two exclusions directly into the source .csproj or by letting the patch own the file, but not both.

2. Exclude the Optimum contract-owned source files from the VintagestoryAPI project consistently. In particular:

OptimumFrustumCullSimd.cs
OptimumKometGuard.cs
OptimumCompatibilityGuard.cs

3. Have prepare-runtime-donors.ps1 use the same resolved .NET executable/path that the main installer uses, rather than relying on a plain dotnet PATH lookup.

The initial Git and PowerShell execution-policy failures may just be prerequisite/documentation issues, but the three problems above were reproducible during the v0.3.15 installation and the workarounds above resulted in a successful install.

Happy to provide the complete installer logs if useful.

[dxcvvxd]

#97
hopefully will get pushed

[Zaldaryon]

Closed by #100. For the record, this report covered three separate failures and all three are now fixed on main:

1. Source/patch ownership conflict on VintagestoryAPI.csproj: fixed in Bump ilspycmd to 11.0.0.9375, migrate installer to FluentAvalonia, fix bootstrap SIGPIPE #99. The stale patches/VintagestoryApi/VintagestoryAPI.csproj.patch is deleted and its excludes live in the sources overlay, so one file has one owner.
2. Duplicated Optimum types (CS0433) and IsChiselTracked (CS0117): fixed in Bump ilspycmd to 11.0.0.9375, migrate installer to FluentAvalonia, fix bootstrap SIGPIPE #99. The overlay VintagestoryAPI.csproj now removes OptimumFrustumCullSimd, OptimumKometGuard, OptimumCompatibilityGuard, OptimumMeshPartPool, and OptimumChunkVisibilityBfs, so those compile only into Optimum.Api.Contracts.dll. A full dotnet build VintageStory.slnx -c Release completes with 0 errors.
3. Runtime-donor packaging could not find the SDK when it lives under %USERPROFILE%\.dotnet and is off PATH: fixed in Resolve dotnet for runtime-donor build when the SDK is under the user profile (fixes #90) #100. prepare-runtime-donors now resolves dotnet with a PATH-then-profile fallback and sets DOTNET_ROOT when the SDK is in the profile install, so the workaround of exporting DOTNET_ROOT by hand is no longer needed.

Thanks to LunarDiver for the report and to JimmyMac3 for the detailed breakdown of all three, which made the third one straightforward to pin down.