This question was created in reference to: [Modifying Crypto settings on a packaged [Content removed]
I currently have a custom tool that’s been successfully managing enabling/disabling encryption/signing of a packaged game. This is a high level overview of my current build pipeline: Package game -> custom tool to disable encryption/signing -> upload game to target 1 -> custom tool to enable encryption/signing -> upload game to target 2. This produced 2 versions of the build: 1 with encryption/signing enabled and one without.
Each time the custom tool ran, it would do 2 things:
Update the DefaultCrypto.ini and trigger a re-build of the binary via `BuildCookRun -config=Test -project=./<project>/<project>.uproject -target=<project> -targetplatform=Win64 -unattended -utf8output -build -skipcook -skipstage`. This would generate a new .exe that I could include in the packaged game with the correct encryption/signing keys registered via the UE_REGISTER_ENCRYPTION_KEY and UE_REGISTER_ENCRYPTION_KEY macros registered in TargetRules.cs.
Recreate the .pak files with the encryption/signing set depending on if we are enabling or disabling crypto settings
This was working great until a recent engine upgrade from 5.6 -> 5.7. Now the re-build step concludes with no build actions and target being marked as up to date. So from what I’ve gathered: a change in the DefaultCrypto.ini on its own no longer recreates the .exe with the crypto keys registered via the macros.
I’ve tried the following:
Pass `-clean` to the build command to force a clean build and re-compile the project but adds a good chunk of time for each run of our custom tool.
Always leave the DefaultCrypto.ini and build with -skipencryption but on the packaged game with encryption disabled, the start up fails with : `Failed to open descriptor file ../../../<project>/<project>.uproject`
A quick test with loading a module with `“LoadingPhase”: “EarliestPossible”` but that seemed to fail with: `Failed to find requested encryption key 00000000000000000000000000000000` whenever trying to enable encryption/signing.
I’ve narrowed my best options between the 2:
Continue to depend on a re-build of the binary but figure out how to force a minimal rebuild of just the pieces that register the crypto keys
I’m wondering if it’s possible to: 1)“dirty” a file that would force the re-compile of the necessary components or 2) delete a set of files in the \Intermediate\ folder or 3) mark the DefaultCrypto.ini as something to track that could trigger a re-build of related pieces
Add code that registers the crypto keys via C++ code early enough before the engine needs them to mount any pak files
Any tips/guidance would be greatly appreciated. Thanks!
Steps to Reproduce
Specifically in terms of seeing that changing the DefaultCrypto.ini in <project>\Config\ doesn’t re-compile the binary:
Modify or add a DefaultCrypto.ini file to <project>\Config\
Trigger a BuildCookRun with the following arguments: -config=Test -project=./<project>/<project>.uproject -target=<project> -targetplatform=Win64 -unattended -utf8output -build -skipcook -skipstage
If the project was already compiled once, see that no modules/targets are re-compiled and the target is marked as up-to-date.
[Attachment Removed]
I ran some local tests and the crypto settings are not tracked as dependencies to the exe by UBT. Simply changing the ini does not trigger the compilation of the runtime exe in release 5.6. I’m not sure why it was working for you in version 5.6. Maybe there was another dependency that was changing.
The encryption key is added to the compilation through the Definitions header of the project’s primary module. This is the module that uses IMPLEMENT_PRIMARY_GAME_MODULE. The generated header will be under: <ROOT>\ProjectName\Intermediate\Build\Win64\x64\PrimaryModuleName\TargetName\PrimaryModuleName\Definitions.PrimaryModuleName.h
You can delete that file which will force its regeneration and in turn the compilation of the primary module.
I will log a feature request so that the crypto settings are part of the dependencies in a future release.
UBT isolates the generated code and the build products for each target\config combination
This depends on the settings of each modules, the target and the type of files being compiled. You will need to check the code in UEBuildModuleCPP.cs to figure out why the generated header will change.
[Attachment Removed]
Thank you for the detailed follow up, I will begin testing this approach tomorrow. I wanted to follow up on the specific of the path and the generated header file name.
Question 1: The path to the generated header file
For the path: is the correct way to build it: `<ROOT>\ProjectName\Intermediate\Build\PlatformName\x64\PrimaryModuleName\TargetName\ProjectName\`? From what I can see, when BuildCookRun gets invoked with the following `-config=Development+Test -target=Example+ExampleAsan -targetplatform=Win64`, I see the following 4 paths:
I’ve noticed 2 variations in the generated file name: Definitions.<PrimaryModuleName>.h vs just Definitions.h. Is one a legacy version of the other? Or is it a platform/target specific thing?
Upon some testing and checking target/config combination, can confirm that the suggested solution to delete the generated definitions header does force a proper re-compiling of the binaries with the correct keys registered.
Marking your initial response as the answer. Thanks for your help!