fix: resolve symbol-upload outside the package folder

[bobbyg603]

Closes #150

What was broken

UploadSymbols resolved the uploader at Path.GetFullPath("Packages/com.bugsplat.unity/Editor/<exe>"). That path only physically exists for embedded/local installs — registry and git URL installs resolve under Library/PackageCache/com.bugsplat.unity@<hash>/, so the file was never found there.

The uploader binaries are gitignored and never ship in the package, so the download fallback ran on every install, not just the broken ones. For PackageCache installs it tried to write into a directory that does not exist (and that Unity owns and may re-extract at any time). WebClient.DownloadFile threw, the error was logged and swallowed, and Process.Start then threw uncaught with a FileName pointing at a nonexistent binary — leaving a build that reported success with no symbols uploaded.

This affects the majority install path (git URL / OpenUPM), on every platform that goes through UploadSymbols (Windows, macOS, Android).

What changed

All of it in Editor/PostBuild.cs, confined to the uploader path resolution and download:

• New GetSymUploaderPath() resolves the package root via UnityEditor.PackageManager.PackageInfo.FindForAssembly, the same way PostProcessWindows already does, with the old Packages/com.bugsplat.unity path kept only as the fallback when FindForAssembly returns null. An uploader already sitting in the package's Editor/ folder is used in place; otherwise the path resolves to Temp/, which is writable for every install type, is not scanned by the asset importer (no .meta churn), and never mutates the package.
• DownloadSymbolUpload now creates the destination directory and returns whether it succeeded. A failed download or a failed chmod +x short-circuits to onCompleted(-1) instead of falling through to a doomed Process.Start.
• Process.Start is wrapped in a try/catch, so a launch failure is logged and surfaced as a non-zero exit code to the existing callbacks rather than escaping the [PostProcessBuild] callback.

Deliberately not touched, to keep this mergeable alongside #151 and #162: the #elif UNITY_EDITOR_WIN dispatch in OnPostprocessBuild and the Android upload callback.

Verified

• dotnet build of the full Runtime/ + Editor/ source set against Unity 6000.5.6f1's managed assemblies, in three define configurations: UNITY_EDITOR, UNITY_EDITOR;UNITY_EDITOR_WIN (with UnityEditor.WindowsStandalone.Extensions.dll), and UNITY_EDITOR;UNITY_ANDROID (with UnityEditor.Android.Extensions.dll + Unity.Android.Types.dll). 0 errors in all three; the only warnings are pre-existing (_platform unused, two never-assigned fields in BugSplat.cs).
• Confirmed the bug is real in current main rather than drifted audit notes: the hardcoded path was still at PostBuild.cs:545, and .gitignore confirms the uploader binaries are never committed, so the download path is always exercised.

Not verified

• No Unity run of any kind. The compile check above is dotnet build against Unity's DLLs, not a Unity build, so nothing here was exercised at runtime: no actual player build, no real download to Temp/, no real upload to BugSplat, and no confirmation from an actual PackageCache install.
• The #if UNITY_IOS block was not compiled (needs the iOS Xcode extension assemblies). It does not call UploadSymbols and is unchanged by this PR.
• Temp/ is cleared when the editor quits, so the uploader is re-downloaded once per editor session. That is the tradeoff the issue asked for and it is not benchmarked here.
• No tests were added. The issue also asks for editor-mode tests for path resolution; the repo has only a BugSplat.Unity.RuntimeTests assembly, so that needs a new Editor test assembly and is left as follow-up under Audit: 5.0.0 SDK review — correctness, platform coverage, security, DX, packaging (mono-issue) #132 (J3). The optional fail-the-build toggle from the issue is also not implemented — it needs a new serialized field on BugSplatOptions plus editor UI, which would collide with the other in-flight PostBuild.cs PRs.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Resolves symbol uploader path resolution for Unity PackageCache installs by locating the package root via PackageInfo.FindForAssembly, downloading the uploader into a writable Temp/ location when needed, and ensuring failures surface as non-zero exit codes instead of silently proceeding.

Changes:

• Added GetSymUploaderPath() to resolve the uploader path via PackageInfo.FindForAssembly, with a fallback to Packages/com.bugsplat.unity.
• Updated UploadSymbols to short-circuit on download failures and to catch Process.Start exceptions.
• Updated DownloadSymbolUpload to create the destination directory and return success/failure (including chmod success).

Suppressed comments (1)

Editor/PostBuild.cs:681

• Log prefix is inconsistent (PostBuild: vs BugSplat.) within the same symbol-upload path, and the chmod exception path again logs only ex.Message. Use the consistent BugSplat. prefix and log the full exception for actionable diagnostics.

			if (process.ExitCode != 0)
			{
				Debug.LogError($"PostBuild: Failed to make {destinationPath} executable. Error: {error}");
				return false;
			}

			Debug.Log($"PostBuild: Successfully made {destinationPath} executable. Output: {output}");
		}
		catch (Exception ex)
		{
			Debug.LogError($"PostBuild: Error setting executable permission for {destinationPath}. Error: {ex.Message}");
			return false;

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.