With push deployment, all folders and files needed to run a game are located in a single package physically located on the hard drive of the dev kit.
With the minimal-fetch comparison type of push deployment, the only files that are compared are those that are located on both the dev kit and the dev PC. Any files that are on the dev kit but not on the dev PC are ignored in calculating the delta between the two drives. Default Visual Studio settings and xbapp.exe deploy use this type of push deployment.
In contrast, the full-fetch comparison type of push deployment compares all files on both drives to determine the delta between the two. The Remove Existing Files setting in Visual Studio and the xbapp.exe deploy /s switch enable this type of comparison.
The use of /s is expensive , but it is also extremely thorough. Essentially, it compares everything on the dev PC to everything on the dev kit and makes sure that all files match. This method is very costly in terms of deployment time, and in many cases it can be faster to use xbapp.exe uninstall and start clean with xbapp.exe deploy.
A point of clarification: Ensuring that there are no stale files (incremental deployment) is very different than ensuring that there are no orphaned files on the console (what /s is needed for). If incremental deployment is all that is needed, then don’t use the /s switch; simply using xbapp.exe deploy will more efficiently determine which files are out of date.
This push-deployment approach guarantees that the layout on the dev kit is an exact match to the layout on the dev PC, but it incurs the cost of a full deployment. It will often be less costly than a full fetch comparison.
| Pros | Cons | Best for |
|---|---|---|
| Absolutely guarantees that the layout on the dev kit is what was intended, that is, that it matches the layout on the dev PC exactly. | Incurs the cost of a full deployment every time it is implemented. | Cleaning up and getting a known good push deployment as a base from which you can use other approaches. |
With this push-deployment approach, the game-development studio is fully in charge of maintaining the synchronization between the dev PC and the dev kit.
| Pros | Cons | Best For |
|---|---|---|
| Not “fire and forget”: It may become tedious to maintain the files to be updated, or difficult to troubleshoot when things get out of sync. | Situations in which a single individual is making targeted changes to a largely static (unchanging) enlistment where the file changes external to the individual are minimal. |
With the iterative deployment approach, the push-deployment system ignores orphan files in keeping the files in sync.
| Pros | Cons | Best for |
|---|---|---|
| Fire and forget: Synchronizes all files. | All or nothing: It prevents you from targeting specific files while leaving others alone. | Daily or weekly builds for play test scenarios in which there is not likely to be iterative development. |
The advantage of this deployment strategy is that after it has been set up once, very little additional scripting is required for subsequent updates.
Rather than copying the large amount of content into the solution folder structure, you will copy the relatively small number of loose files in the solution folder [solution][project]\XboxOne\ Layout\Image\Loose\ to where the content currently resides. Then you’ll run xbapp.exe deploy from that folder to copy the content over. You will only have to do this once; subsequent iterations are deployed from the solution folder by using Visual Studio F5.
REM Build the project in Visual Studio before running this script.
set iterativefolder="D:\Direct3DGame1\Direct3DGame1\XboxOne\Layout\Image\Loose"
set deployfolder="D:\deploy"
robocopy.exe %iterativefolder% %deployfolder%
xbapp.exe deploy %deployfolder% /v
del %deployfolder%\*.* /q
const float clearColor[] = { 0.39f, 0.58f, 0.93f, 1.000f }; to const float clearColor[] = { 0.93f, 0.39f, 0.58f, 1.000f };it’s up to you to decide how to update the content in the package on the console. One way would be to write a small app that uses a FileWatcher on the \deploy\content\ folder and generates a batch file to copy to the console package only the content files that have changed. The batch file could accomplish this by using the xbcp {PFN}:\ approach, or by silently copying the files over in real time.
Visual Studio uses push deployment by default for all Xbox One projects. The following sample output is representative of the data seen in the Output pane during push deployment when F5 is used to save, build, and launch the project.
Example of initial deployment output (push)
Push deploying 'C:\Users\charlieo\Documents\Visual Studio\Projects\Direct3DGame1\XboxOne\Layout\Image\Loose' to '10.124.132.249'.
Calculating payload.
Transfer starting for 7 files (757690 bytes).
Transferring 1/7: C:\Users\charlieo\Documents\Visual Studio\Projects\Direct3DGame1\XboxOne\Layout\Image\Loose\appdata.bin (262144 bytes)
Transferring 2/7: C:\Users\charlieo\Documents\Visual Studio\Projects\Direct3DGame1\XboxOne\Layout\Image\Loose\AppxManifest.xml (1240 bytes)
Transferring 3/7: C:\Users\charlieo\Documents\Visual Studio\Projects\Direct3DGame1\XboxOne\Layout\Image\Loose\Direct3DGame1.exe (478720 bytes)
Transferring 4/7: C:\Users\charlieo\Documents\Visual Studio\Projects\Direct3DGame1\XboxOne\Layout\Image\Loose\Logo.png (5789 bytes)
Transferring 5/7: C:\Users\charlieo\Documents\Visual Studio\Projects\Direct3DGame1\XboxOne\Layout\Image\Loose\SmallLogo.png (745 bytes)
Transferring 6/7: C:\Users\charlieo\Documents\Visual Studio\Projects\Direct3DGame1\XboxOne\Layout\Image\Loose\SplashScreen.png (7126 bytes)
Transferring 7/7: C:\Users\charlieo\Documents\Visual Studio\Projects\Direct3DGame1\XboxOne\Layout\Image\Loose\StoreLogo.png (1926 bytes)
Package Full Name: '1777df60-649d-42fd-ba63-e0aaf5ccd379_1.0.0.0_x64__zjr0dfhgjwvde'
757690 bytes in 7 files over 4.635 seconds.
Approximate transfer speed: 0.155898488198026 MB/s.
Aumids returned for this package:
1777df60-649d-42fd-ba63-e0aaf5ccd379_zjr0dfhgjwvde!App
Project associated with aumid '1777df60-649d-42fd-ba63-e0aaf5ccd379_zjr0dfhgjwvde!App'
Selected debugger address '10.124.133.56'.
Launch request successful.
Example of iterative deployment output (push)
Push deploying 'C:\Users\charlieo\Documents\Visual Studio\Projects\Direct3DGame1\XboxOne\Layout\Image\Loose' to '10.124.132.249'.
Calculating payload.
Transfer starting for 2 files (740864 bytes).
Transferring 1/2: C:\Users\charlieo\Documents\Visual Studio\Projects\Direct3DGame1\XboxOne\Layout\Image\Loose\appdata.bin (262144 bytes)
Transferring 2/2: C:\Users\charlieo\Documents\Visual Studio\Projects\Direct3DGame1\XboxOne\Layout\Image\Loose\Direct3DGame1.exe (478720 bytes)
Package Full Name: '1777df60-649d-42fd-ba63-e0aaf5ccd379_1.0.0.0_x64__zjr0dfhgjwvde'
740864 bytes in 2 files over 3.039 seconds.
Approximate transfer speed: 0.232491927854557 MB/s.
Aumids returned for this package:
1777df60-649d-42fd-ba63-e0aaf5ccd379_zjr0dfhgjwvde!App
Project associated with aumid '1777df60-649d-42fd-ba63-e0aaf5ccd379_zjr0dfhgjwvde!App'
Selected debugger address '10.124.133.56'.
Launch request successful.
Starting in the June 2015 XDK, when deploying an application, if the tools determine that the console does not have enough free disk space, they will display the following error message:
The package could not be installed because there is not enough storage on the console.
In some cases, this error can be reported when the console actually does have enough free space to deploy the application. The error can be bypassed by setting the environment variable XTF_WARN_DISK_FULL=1.
When this environment variable is set, this error will be treated as a warning like it was in the May 2015 and earlier XDK and deployment will be allowed to proceed.
After setting this environment variable, you must restart the following processes:
In both push and pull deployment, the era.xvd file is required to be at the root of the package.