In my attempts to automate building a project for the windows store, I am using a using Unity in batchmode. I have noticed two different behaviors which has me concerned about several things.
I build the project using the same method that I call with -executeMethod in batchmode. I have observed two different behaviours:
When building the project myself (Editor GUI open), no errors come up and the build succeeds.
When building in batchmode (nogui), the following erros get thrown:
After some digging, I’ve found that “AbstractManager” is a class that is provided by the Prime31 plugin. Why would this error get thrown when compiling in batchmode and not when in gui mode?
My other concern is with the options available when building using the pipeline. To set the building target I use “-buildTarget wsaplayer” to set the builder to Windows Store Apps. I was not, however, able to find any resources as to be able to set the building SDK (Universal 10 in my case). Right now, I do not know what sdk is being used in batchmode. I’ve tried using Unity - Scripting API: EditorUserBuildSettings but am getting Unreachable Code warnings. The “Unity C# Projects” is also an option I want set. Is there any way to set these settings to build by project? My Unity version is 5.3.5p8.
As for errors - I have no idea why you’re getting them. If you still get them after configuring these things, could you paste the whole editor log with the errors?
Hey,
Thanks for the resources. These did solve the errors that showed up, but some other strange behavior has occurred. The UWP assemblies are being built to an unwanted location.
For some reason the Unity project, located in the CI runner’s directory, is building the UWP assemblies in my local git workspace.
I have attempted to rename the local workspace ‘D:\git projects{game}2’. This did bypass the errors above, but another arose when Visual Studio’s MSBuild started building:
Looking at the UWP directory, I see that the files are generated in a completely different structure than the errors suggest. See the contents of Assembly-CSharp below.
Is there something I’m missing? I don’t quite understand why Unity would generate a .csproj with a path it didn’t make.
Here you go https://pastebin.com/Egigd9pU
The logs include both Unity and MSBuild logs. The first logs of my original post are at line 2876, the errors at the bottom, and MSBuild starts at 2836. I hope you can find where I go blind.
Whoa, you’re on an ancient version of Unity. And it seems you’re invoking MSBuild from VS2017, which we only started supporting in Unity 5.5. I’m not exactly sure how Unity 5.3 behaves with it, but we can try solving it.
It seems that for some reason it tries to first build game project rather than Assembly-CSharp project (your scripts), even though game project depends on your scripts, and fails because they’re not built yet.
You could try invoking MSBuild twice instead: first, invoke it with an extra parameter “/t:Assembly-CSharp”, and once that’s done, invoke it normally again. That would force Assembly-CSharp to be built first.
Btw, is there any reason you want to use “C# projects” option when using automated builds?
Thanks for the suggestions. I did some more fiddling and I figured out that the assemblies were building in the wrong location because of the “OutputPath” setting with MSBuild. After removing outputpath from the command, it can only build the ARM version of the game correctly. When it continues to build x86 results in
It seems that these weren’t even built, since the contents of UWP do not include the path \bin\x86\ at all.
Why do you assume you cannot submit to the store with prebuilt assemblies? That’s all nuget does: just downloads them and puts them into your output folder. Are you sure you are not messing up the generated projects in the process? Doing this thing with references is definitely not something we tested for…
Anyway, the build log says that Assembly-CSharp.dll isn’t built for x86/Release. Did you try following my suggestion to first call MSBuild to build it in the configuration you want it for?
I had already tried submitting the game with a pre-built assembly of notifications extensions, and certification rejected it on the pretense of it being an unauthorized plugin - security reasons/could be malware. For now it doesn’t seem to negatively affect the output since manual building still works.
Furthermore, I did follow your advice. In fact I called the command with /t: twice: once for ARM and once for x86, and then the full build without /t. Both of the /t: builds finish successfully.
My MSBuild commands look like this:
Do you happen to have exactly what they said? I’m very curious on this as I have never seen that before.
Ah, I think the issue is the fact that Assembly-CSharp does not actually build any bundles. Specifying their platform doesn’t do anything. Instead, you have to specify project platform:
I’ll see if I can request the exact log since I don’t have access to the email inbox associated with the developer account.
Also, using your build commands for Assembly-CSharp I was successfully able to build the packages. Unfortunately not it seemed like the package did not fully build without fault. A TypeLoadException triggered on startup.
From the log I can infer that something in firstpass corrupted, but it’s still too vague for me to know which plugin may have caused this. Any ideas?
