What's wrong
The ios subcommands pass --project through as given (KtsuBuild.Tool/Program.cs, handlers around lines 500–740). dotnet runs with workingDirectory = workspace, so the build and publish themselves find the project. KtsuBuild's own file lookups, however, resolve the path against the process CWD:
IosBuildService.VerifyDeviceBundle: Path.GetFullPath(head) (KtsuBuild/Ios/IosBuildService.cs:118)IosService.LocateIpas: Path.GetFullPath(head) (KtsuBuild/Ios/IosService.cs:256)IosService.ArchiveAsync: Path.GetFullPath(options.ProjectPath) (:401)IosService.ResolveInfoPlist: Path.GetFullPath(projectPath) (:462)IosService.ResolveIosFramework: File.Exists(projectPath) (:477)
Failure scenario
On macOS, from outside the workspace: ktsubuild ios build --workspace app --project src/App.iOS/App.iOS.csproj
ios build: dotnet build succeeds, then the bundle check searches <cwd>/src/App.iOS/bin/Release. It logs "Device .app bundle not found" and exits 1.ios package: Info.plist is "not found", so the version is not stamped (only a warning). -f is omitted, and the command throws "iOS archive completed but no .ipa was produced".ios upload: it finds no .ipa and exits 0 having uploaded nothing.
test run already handles this case (TestCommand.cs around line 116). #172 is the same class of bug (--workspace differs from CWD) for the changelog and release notes.
Suggested fix
Normalize once in the ios handlers, the same way test run does: Path.IsPathRooted(p) ? p : Path.Combine(workspace, p). Alternatively, resolve against options.WorkingDirectory inside the services, so every lookup agrees with the directory dotnet ran in.
Acceptance: unit tests run the three services with a relative project path and a WorkingDirectory that differs from the process CWD, using temp directories. They show that the bundle, Info.plist, framework and .ipa lookups all resolve under the workspace.
What's wrong
The
iossubcommands pass--projectthrough as given (KtsuBuild.Tool/Program.cs, handlers around lines 500–740).dotnetruns withworkingDirectory = workspace, so the build and publish themselves find the project. KtsuBuild's own file lookups, however, resolve the path against the process CWD:IosBuildService.VerifyDeviceBundle:Path.GetFullPath(head)(KtsuBuild/Ios/IosBuildService.cs:118)IosService.LocateIpas:Path.GetFullPath(head)(KtsuBuild/Ios/IosService.cs:256)IosService.ArchiveAsync:Path.GetFullPath(options.ProjectPath)(:401)IosService.ResolveInfoPlist:Path.GetFullPath(projectPath)(:462)IosService.ResolveIosFramework:File.Exists(projectPath)(:477)Failure scenario
On macOS, from outside the workspace:
ktsubuild ios build --workspace app --project src/App.iOS/App.iOS.csprojios build:dotnet buildsucceeds, then the bundle check searches<cwd>/src/App.iOS/bin/Release. It logs "Device .app bundle not found" and exits 1.ios package: Info.plist is "not found", so the version is not stamped (only a warning).-fis omitted, and the command throws "iOS archive completed but no .ipa was produced".ios upload: it finds no.ipaand exits 0 having uploaded nothing.test runalready handles this case (TestCommand.csaround line 116). #172 is the same class of bug (--workspacediffers from CWD) for the changelog and release notes.Suggested fix
Normalize once in the
ioshandlers, the same waytest rundoes:Path.IsPathRooted(p) ? p : Path.Combine(workspace, p). Alternatively, resolve againstoptions.WorkingDirectoryinside the services, so every lookup agrees with the directorydotnetran in.Acceptance: unit tests run the three services with a relative project path and a
WorkingDirectorythat differs from the process CWD, using temp directories. They show that the bundle, Info.plist, framework and.ipalookups all resolve under the workspace.