Okay, first post here, and I’ve been thrown in some reasonably deep water at work to try get our TeamCity/Perforce CICD workflow working with UNC-based network paths, instead of the regular C:\ (or D:, or whatever) path. Historically, all our builds have gone to local drive, work fine, no issues (the location for which is determined upon batch startup of the editor in ProjectPath, e.g.
C:/Unity/Unity2021.3.20f1/Editor/Unity.exe -projectPath C:/work/someDir/myGame -quit -batchmode -tonnesofotherparams
Upon changing ProjectPath to be a UNC-based path, which both Perforce and TeamCity are able to write to no problems, it seems Unity doesn’t like it, or I’m missing something somewhere and for the life of me (Googling my little heart out) I can’t crack it. For example:
C:/Unity/Unity2021.3.20f1/Editor/Unity.exe -projectPath \\mypath\goes\here\uncBased -quit -batchmode -tonnesofotherparams
Unity seems to want to take the path, and then for some reason I can’t fathom, ‘local storage’ it - in the above example, it wants to start doing stuff in
C:/mypath/goes/here/uncBased
A very dirty log sample would be:
A re-import of the project may be required to fix the issue or a manual modification of /mypath/goes/here/uncBased/Packages/manifest.json file.```
I thought it could be manifest related, but then it seems deeper rooted - also tried all manner of 'slash espcaping' and working around the path. Anyone ever come across this? From reading the forums it seems not, I just can't get a definitive take on UNC paths. Any pointers very much appreciated!
Not sure but what happens if you make a c:\foo directory and then put a symlink in c:\foo over to the project directory in the UNC path??
I have NO idea where those translations would take place either… I’m just making a wild guess at a possible solution that might move the needle.
Hi Kurt, thanks for the response - tried symlinks a few times before (and mapped drives, which deffo don’t work with TeamCity) - with mixed results - but tried linking again tonight, the jobs failed the first time, but then I removed the manifest.json entirely, re-ran (which creates the new manifest.json), and it seems to have got a whole lot further than before, so I’m deffo down the right rabbithole I reckon! More ferreting required but progress! Cheers!
Okay, tl;dr solution in case anyone stumbles upon a similar situation for this TeamCity-Perforce-Unity triangle, with network-based builds (in our case, to a deduping hardware array presented as UNC)…
In TeamCity, for the Unity build a PowerShell runner and not SimpleRunner is required (with some foregrounding of the Unity.exe process required so it doesn’t spin up multiple Unity sessions, PS backgrounds by default), because CMD doesn’t support UNC. In addition, the critical piece of “-projectPath” parameter having an equals and not a space after it.
Upshot: The Unity documentation is wrong. And subsequently our runner has ALWAYS been setup wrong. ‘Unity.exe -projectPath thePathHere’ has always been used, BUT because it’s wrong, it’s always silently error-ed on that and used its fallback of the DEFAULT ProjectPath - which up until now wasn’t a problem because we were passing that value anyway. Unity was thinking when we were passing the default ProjectPath ‘oh, I don’t know what this extra parameter is, I’ll use the default ProjectPath’ 
- so it’s never ever been an issue, more through luck than anything.