I believe my latest commit will help, but per my comments on the associated issue there’s a deeper problem that we’re selecting the 2015 toolchain despite requesting 2017 on the command line.
Thank you @ for working on this. I’m trying your last commit now. . .
[EDIT]
Using the latest commit with VS 2017 (ver 15.2) I was presented with the Retarget dialog:
After the retargeting the Project Name is labeled slightly different (notice the Visual Studio 2015):
@ - Thank you again for the update. I’m happy to report that I am able to build Visual Studio Win and UWP versions of my game without any errors. Tomorrow I should have time to test packaging as well.
Btw, will the project name with Visual Studio 2015 appended to it (Win64 version) have any ill effect? The UWP project displays as normal.
I’m getting the following error message when trying to login to any of my test user accounts on Win10.
I’ve setup the sandbox correctly through Device Portal, and can login to the account fine through the XboxLiveAccountTool.
On XB1 I’m getting a fatal error on boot. Specifically inside XboxLiveContext->RealTimeActivityService->Activate() which is called from FOnlineSubsystemLive::GetLiveContext().
The callstack -
msvcr110.dll!_invoke_watson(const wchar_t * pszExpression, const wchar_t * pszFunction, const wchar_t * pszFile, unsigned int nLine, unsigned __int64 pReserved) Line 129 C++
vccorlib110.dll!__abi_FailFast() Line 18 C++
Microsoft.Xbox.Services.dll!`Xbox::Services::Tournaments::__ITournamentServicePublicNonVirtuals::TournamentService:: [Microsoft::Xbox::Services::Tournaments::__ITournamentServicePublicNonVirtuals]::__abi_Microsoft_Xbox_Services_Tournaments___ITournamentServicePublicNonVirtuals____abi_GetTournamentsAsync'::`1'::catch$1() C++
msvcr110.dll!_CallSettingFrame() Line 51 Unknown
msvcr110.dll!__CxxCallCatchBlock(_EXCEPTION_RECORD * pExcept) Line 1265 C++
ntdll.dll!RcConsolidateFrames () Unknown
Microsoft.Xbox.Services.dll!Microsoft::Xbox::Services::Tournaments::TournamentService::[Microsoft::Xbox::Services::Tournaments::__ITournamentServicePublicNonVirtuals]::__abi_Microsoft_Xbox_Services_Tournaments___ITournamentServicePublicNonVirtuals____abi_GetTournamentsAsync(Microsoft::Xbox::Services::Tournaments::TournamentRequest ^ request, Windows::Foundation::IAsyncOperation<Microsoft::Xbox::Services::Tournaments::TournamentRequestResult ^> ^ * __abi_returnValue) C++
XboxOne-Debug.exe!Microsoft::Xbox::Services::RealTimeActivity::__IRealTimeActivityServicePublicNonVirtuals::Activate() C++
> XboxOne-Debug.exe!FOnlineSubsystemLive::GetLiveContext(Windows::Xbox::System::User ^ LiveUser) Line 711 C++
XboxOne-Debug.exe!FSessionMessageRouter::SubscribeToMultiplayerEvents(Windows::Xbox::System::User ^ SubscribingUser) Line 138 C++
XboxOne-Debug.exe!FSessionMessageRouter::FSessionMessageRouter(FOnlineSubsystemLive * InSubsystem) Line 108 C++
XboxOne-Debug.exe!SharedPointerInternals::TIntrusiveReferenceController<FSessionMessageRouter>::TIntrusiveReferenceController<FSessionMessageRouter><FOnlineSubsystemLive * __ptr64 const>(FOnlineSubsystemLive * const && <Args_0>) Line 129 C++
XboxOne-Debug.exe!SharedPointerInternals::NewIntrusiveReferenceController<FSessionMessageRouter,FOnlineSubsystemLive * __ptr64 const>(FOnlineSubsystemLive * const && <Args_0>) Line 180 C++
XboxOne-Debug.exe!MakeShared<FSessionMessageRouter,1,FOnlineSubsystemLive * __ptr64 const>(FOnlineSubsystemLive * const && <Args_0>) Line 1678 C++
XboxOne-Debug.exe!FOnlineSubsystemLive::Init() Line 419 C++
Looks like it’s something to do with the Tournament subsystem. Not something we need for this game actually, but I’m not sure how to turn it off…
@Sparkash - as I recall 80860003 was caused by a mismatch between service and client side configuration of the application. I suspect this is not a Creators Program title? In which case make sure to leave that box unchecked in the Project Settings. Also make sure that your build is turning out an AppxManifest.xml with Package/Identity/Name and Package/Identity/Publisher values that exactly match Dev Center. If you have the latest version of the code then there are now dedicated fields for these in the UWP Project Settings page (Packaging section, Advanced display); if not specified, or on older versions of the source, these come from the Project Name and Company Distinguished Name in general project settings.
XDK title issues are best dealt with through private support channels.
@anonymous_user_1267f45c - the 2015 suffix shouldn’t be a problem. It’s just indicating that the projects are in 2015 format. For UE projects this is independent of which toolset is used when building. If you want to switch everything to 2017 format and toolset you can re-run GenerateProjectFiles with -2017 on the command line.
Good to know. On a separate issue, I’m trying to debug the XSAPI and REST code, which are DLL’s, and have them added to my VS Solution:
https:///Microsoft/xbox-live-api/blob/master/LINKTOSOURCE.md#how-to-link-against-the-xsapi-winrt-uwp-source
My build output is: <Game>\Binaries\UWP64\AppX\Engine\Plugins\Online\XboxOne\OnlineSubsystemLive\ThirdParty\XSAPI\UWP.2017.07.20170710.01\lib\x64\v140\release
After pressing F5 in VS the REST DLL is overwritten from the script:
How can I disable the overwriting? Possibly rename the source folder 
Also, I noticed that the source folder already has the PDB present for both DLL’s:
Engine\Plugins\Online\XboxOne\OnlineSubsystemLive\ThirdParty\XSAPI\UWP.2017.07.20170710.01\lib\x64\v140\Release
Are these coming from a Microsoft Server?
[EDIT]
I see the D appended to the REST DLL (cpprestd_uwp_2_9.*).
I am trying to make the HDR changes to work in in UWP. The HDR implementation seems to rely on the AMD_AGS and the NVAPI libraries. These were giving me linker errors for UWP. I found an “amd_ags_uwp_x64.lib” library which fixes my errors for AMD_AGS but I have not been able to find a replacement library for NVAPI. The linker errors are complaining about a few functions in NVAPI, including “NvAPI_DISP_GetDisplayIdByDisplayName”, “NvAPI_GetErrorMessage” and “NvAPI_Disp_GetHdrCapabilities” which I believe are needed to detect if an NVIDIA card can support HDR. Has anyone tried this? Is there something I could use to replace nvapi64.lib for UWP?
Files inside the Binaries/UWPxx/AppX directory are deployed by Visual Studio. It does this based on the {project_name}.build.appxrecipe file, which UBT creates (see UWPDeploy.GeneratePackageAppXRecipe). You’re likely to have a hard time preventing VS from doing the copy as part of deployment, so your best bets would either be to get your self-built binaries into the recipe, or else run without re-deploying.
For the former: easiest is probably to change the definition of XSAPISubDir in OnlineSubsystemLive.build.cs to point at a directory where your dlls live (make sure it’s a subdir of the plugin).
For the latter: make no code changes, build-and-run your game as normal, copy in your edited dlls, then instead of debugging again normally go to the Visual Studio Debug menu, select Other Debug Targets -> Debug Installed App Package…, then choose your game from the list offered.
Note that the cpprest dll is manually loaded - it lives in a path that is not searched by the normal UWP dll location rules - and as such you’re going to have to change OnlineSubsystemLive.build.cs no matter what to account for the ‘d’ suffix. Though I should also say that if you find yourself debugging much inside cpprest you’re probably off in the weeds.
Yes, I found that out Instead, I added the projects to my solution and directed the output to the original location:
MICROSOFT_UWP_UNREAL\Engine\Plugins\Online\XboxOne\OnlineSubsystemLive\ThirdParty\XSAPI\UWP.2017.07.20170710.01\lib\x64\v140\Release
This approach appears to partially work in that the correct DLL’s are present but I believe debugging is a problem.
I stumbled onto the Debug Installed App Package, which does seem useful. . .at the moment though debugging isn’t working for me: https:///MICROSOFT-XBOX-ATG/MICROSOFT_UWP_UNREAL/issues/129
Thank you for the note.
You’re correct, we’re not a Creators Program title. I’ve tried setting the publisher to the exact string that’s referenced on XDP (we’re not using Dev Center), but I’m still getting the same error.
Might there be something wrong with my signing certificate? I’m using a local development one that I created just to allow me to install package builds.
If you’re not using Dev Center then I’d recommend get in touch with your Microsoft rep for the Xbox program you belong to.
Certificates are definitely not the issue though. You can use a self-signed certificate for a package and access Live just fine, regardless of Xbox program. Or you can use an unpackaged (and so completely unsigned) build.
@ - At the moment debug isn’t working for me: https:///MICROSOFT-XBOX-ATG/MICROSOFT_UWP_UNREAL/issues/129
Do you have any suggestions?
I am currently flummoxed by this one. Somehow your exe (remember the ‘real’ one is in Appx/{project}/Binaries/UWP64) doesn’t match the pdb. But if it’s not fixed by a rebuild and redeploy then I really don’t know what’s going on. Will update if I have any bright ideas.
I’ve followed up with those issues with on our private channel.
When attempting to build a UWP64 package within UE, I’m getting this error -
UATHelper: Packaging (UWP (x64-64bit)): signtool: SignTool Error: An unexpected internal error has occurred.
UATHelper: Packaging (UWP (x64-64bit)): CommandUtils.Run: Run: Took 219.665472s to run signtool.exe, ExitCode=1
UATHelper: Packaging (UWP (x64-64bit)): Program.Main: ERROR: AutomationTool terminated with exception: AutomationTool.CommandUtils+CommandFailedException: Command failed (Result:1): C:\Program Files (x86)\Windows Kits\10\bin\x64\signtool.exe sign /a /f "D:\MyGame_416_uwp_merge\ueproject\Build\UWP\MyGame_temp_cert.pfx" /fd SHA256 "D:\MyGame_416_uwp_merge\uepr
oject\Saved\StagedBuilds\UWP64\MyGame.appx". See logfile for details: 'signtool-2017.07.20-17.48.26.txt'
Seems my certificate is failing now. I’ve checked the certificate, and it’s issued to ‘No Publisher’. My uwp appxmanifest has Publisher=“CN=No Publisher” set in the identity tag. What other information might it be failing on?
This was working previously with 4.15.
The logfile mentioned should be in Engine\Programs\AutomationTool\Saved\Logs. What does it say? In particular is there an error code from signtool? Common cases are here.
Also, not sure what commit you’re on, but a fairly recent one added a button in the project settings UI that will generate a certificate for you. You might see if using that makes any difference.
Sorry, had read the details of the text file and saw that it implied that my ‘publisher’ field was incorrect. To clarify the contents are :
Done Adding Additional Store
Error information: "Error: SignerSign() failed." (-2147024885/0x8007000b)
SignTool Error: An unexpected internal error has occurred.
Thanks for the common cases link - I can see that the publisher didn’t match (I was missing the ‘O=’ section). Editing that to match will hopefully sort it.
Regarding the automatic certificate generation - I’m on the latest commit, but I don’t see the option in the project settings UI. Any reason it wouldn’t be available to me?
Ah, I see you’re way ahead of me. Publisher mismatch is indeed the normal reason for that error. Have you tried manually running SignTool with the debug option?
C:\Program Files (x86)\Windows Kits\10\bin\x64\signtool.exe sign **debug** /a /f "D:\MyGame_416_uwp_merge\ueproject\Build\UWP\MyGame_temp_cert.pfx" /fd SHA256 "D:\MyGame_416_uwp_merge\ueproject\Saved\StagedBuilds\UWP64\MyGame.appx
As for the generate button, it should be on the UWP page of project settings, in the packaging section, and look something like
Can’t think of any reason why it wouldn’t be there for you - it’s unconditionally added to the layout. I did realize while grabbing that for you that it’s a little fussy right now - you need to delete the existing .cer, .pvk and .pfx before it will work, and if you change publisher/identity/name you may need to close and reopen the settings window before trying to generate.
One last thing - I see you’ve changed the file name of the certificate in use (not Build/UWP/SigningCertificate.pfx). That ‘feature’ didn’t seem particularly useful, and wasn’t ever exposed through editor UI, so it’s gone in the latest and we just always use the default location. Don’t think that’s related to your current error since the command line to signtool indicates your custom location is in use, but it might become relevant as you try to make changes to pinpoint the problem.
@Sparkash - adding to what @ wrote, the UWP Page is accessed by scrolling the side menu on the Project Settings page:
And an example of my settings for a test project I have:
