Unreal Engine 4 is available for Win10 UWP app dev now

KAEPS133 · May 15, 2017, 12:11pm

Alright tested and played a bit with UWP and run into another issue. After uploading a .appx to the store I get the error Invalid package identity name and Invalid package family name.

I tried several combinations of adding PolygonArt. infront of the Project Name and so on but it did not help. I tought on changing the entire Project name to PolygonArt.UnrealEngine4TestTest App by updating the folder and .uproject but it’s a to long file name for UE4. The app is running fine on my local PC but uploading failed due to invalid names. Any idea what I need to change?

anonymous_user_537a337d · May 15, 2017, 3:27pm

I’m working on trying to get my project packaged for the Windows Store. Unfortunately I’m encountering an error for signing:



UATHelper: Packaging (UWP (x64-64bit)): CommandUtils.Run: Run: C:\Program Files (x86)\Windows Kits\10\bin\x64\signtool.exe sign /a /f "E:\UEUWP\Source\UWPLongshotHero\Build\UWP\SigningCertificate.pfx" /fd SHA256 "E:\UEUWP\Source\UWPLongshotHero\Saved\StagedBuilds\UWP\LongshotHero.appx"
UATHelper: Packaging (UWP (x64-64bit)): signtool: SignTool Error: An unexpected internal error has occurred.

Does anyone know how to remove the certificate from the UE4 Property pages?

I know how to remove the certificates from my machine [C:>CertMgr] but that doesn’t help with this problem. I don’t know how to tell UE4 to remove the certificate.

[EDIT 2017.05.17 @ 12:25PM MST]
I’m not certain my steps are correct but I found a key in the BUILD folder (I think), which I deleted, and ran the packaging again. Near the end of the packaging process the key generation window popped automatically, and I selected NONE for the password. I thought about CANCEL and the possible repercussions from that choice, meaning the packaging may have failed. So I chose none. The build/packing was successful, my APPX file is 4.2GB in size. Now I’m uploading to the store to see if I got the settings correct or not. I think I may have missed one. . .which I’ll know shortly.

anonymous_user_537a337d · May 15, 2017, 8:30pm

I’m running into the same problem you are. Different versions cause different errors.

Are you getting prompted for the certificate password?

Now I’m building again, and thinking of unzipping the contents and manually setting the values in the manifest. The Store is asking for:



Package/Identity/Name:   9999RvBGames.ProductName
Package/Identity/Publisher:   CN=10ABCDEF-FFFF-AAAA-BBBB-123456789ABC
Package/Properties/PublisherDisplayName:   RvBGames

Likewise, the AppManifest.xml has a few interesting keys, which I believe matchup as shown below:



<?xml version="1.0" encoding="utf-8"?>
<Package xmlns="http://schemas.microsoft.com/appx/manifest/foundation/windows10" xmlns:uap="http://schemas.microsoft.com/appx/manifest/uap/windows10" xmlns:mp="http://schemas.microsoft.com/appx/2014/phone/manifest">
	<Identity Name="FlyingGameTemplate" ProcessorArchitecture="x64" Publisher="CN=RvBGames" Version="1.0.0.0" />
	<Properties>
		<DisplayName>Flying Game Template</DisplayName>
		<PublisherDisplayName>RvBGames</PublisherDisplayName>
		<Description>Flying</Description>
		<Logo>Resources\StoreLogo.png</Logo>
	</Properties>
	<Resources>
		<Resource Language="en" />
	</Resources>
	<Dependencies>
		<TargetDeviceFamily Name="Windows.Universal" MinVersion="10.0.10240.0" MaxVersionTested="10.0.10586.0" />
		<PackageDependency Name="Microsoft.VCLibs.140.00" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" MinVersion="14.0.0.0" />
	</Dependencies>
	<Capabilities>
		<Capability Name="internetClientServer" />
		<Capability Name="privateNetworkClientServer" />
	</Capabilities>
	<Applications>
		<Application Id="AppFlyingGameTemplate" Executable="UEUWPFlying\Binaries\UWP64\UEUWPFlying-UWP64-Shipping.exe" EntryPoint="AppFlyingGameTemplate.App">
			<uap:VisualElements DisplayName="ms-resource:ProjectName" Description="ms-resource:Description" BackgroundColor="#000040" Square150x150Logo="Resources\Logo.png" Square44x44Logo="Resources\SmallLogo.png">
				<uap:SplashScreen BackgroundColor="#000040" Image="Resources\SplashScreen.png" />
			</uap:VisualElements>
		</Application>
	</Applications>
</Package>

The elements and attributes that look the most interesting are:



<Identity **Name**="**Package/Identity/Name**" **Publisher**="**Package/Identity/Publisher**" />
<Properties>
   <**DisplayName**>Description of Game?</DisplayName>
   <**PublisherDisplayName**>**Package/Properties/PublisherDisplayName**<PublisherDisplayName/>
</Properties>

Assuming that I am setting the correct values in the UE4 settings, I am getting an unexpected error, which I’ll enter on GitHub if it is the case:

And from the manifest we can see why:



	<Identity Name="1101RvBGames.LongshotHero" ProcessorArchitecture="x64" Publisher="CN=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX" Version="1.0.0.0" />
	<Properties>
		<DisplayName>**1101RvBGames.**LongshotHero</DisplayName>
		<PublisherDisplayName>RvBGames</PublisherDisplayName>
		<Description>Longshot Hero</Description>
		<Logo>Resources\StoreLogo.png</Logo>
	</Properties>

I’m hoping the 1101RvBGames. is the problem in the DisplayName. I’m uploading it now, which has taken over an hour to do so.

[EDIT 2017.05.16 @ 12:26PM MST]
Well, that didn’t work because the message digest wasn’t correct, something I thought was going to happen but felt it was the quickest test.

Now I’m trying a slight modification I made to Engine\Config\UWP\UWPEngine.ini file:



;***************************************************************************************************
Package.Properties.DisplayName=$/Script/EngineSettings.GeneralProjectSettings:ProjectDisplayedTitle$
;***************************************************************************************************

DisplayName was set to ProjectName, so I’m expecting (incorrectly maybe) the manifest will be populated with the right data.

anonymous_user_582995091 · May 16, 2017, 8:14pm

I think the trouble with using ProjectDisplayedTitle is that it’s an FText, not FString, which the build tools don’t properly understand so you may still get an incorrect value.

For now the simplest is probably to add a [Game]\Config\UWP\UWPEngine.ini in which you set Package.Properties.DisplayName to a literal value of your own choosing. Alternatively for a one-off you can hand-edit the appxmanifest, and then re-run makeappx from the command line.

Really though this field should have a value something like ms-resource:ProjectName where ProjectName is a key in a localized resw file (that gets compiled into the resources.pri file which ultimately goes into the appx). The process for doing this properly is kind of half-baked at present - resw files are actually being generated to an intermediate directory, but there’s no current mechanism to the [Game]\Intermediate\Deploy directory, but there’s no mechanism to put localized source content into them. I’m experimenting with some small changes as a stopgap improvement for this. Will update here if they work out.

anonymous_user_537a337d · May 16, 2017, 9:07pm

Re-running the makeappx is nice to know about. Thank you for that tip

Okay, so I was able to upload my project to the Windows Store, even with the above change. A problem I encountered with the verification process was that, again, my names didn’t match. The solution was rather easy though:

From the Dev Center, go to App Management, Manage app names, and entered the name I needed
Return to the Submissions, Packages, and select Retry

Retry was a nice choice, it eliminated the need to re-upload my package again. It is worth noting that you can enter several names for the same product on Windows Store.

As it stands now, I’m using the below from the Project Description page in the UE4 Editor:

Project Name <- Package/Identity/Name
Company Distinguished Name <- Package/Identity/Publisher
Company Name <- Package/Properties/PublisherDisplayName
Project Displayed Title <- a name contained in the Windows Store list of reserved app names

Is this correct or not?

Initially the first problem I ran into was that I had to change the UE4 Editor Project Name to match the Windows Store XXXXXX.MyGameName. This caused an error due to the Project Name being used for the Display Name. After the upload to the Windows Store the validation process reported there was mismatch between the Display Name and Reserved names. If I had known better, I might have been able to just add the XXXXX.MyGameName to the list and be done with it.

anonymous_user_537a337d · May 16, 2017, 9:09pm

Yes, that may be an issue. I believe though that the values are pulled from the INI file, which the change above uses. I’m not stating that as fact, just surmising.

[EDIT 2017.05.16 @ 3:26PM MST]
That was funny, I saw the effects of using the FName field in the manifest. It had the namespace localization macro as part of it:



NSLOCTEXT("[/Script/EngineSettings]", "0E530AFC44260274FBA09C8EC0BDCCA1", "Longshot Hero")

Well, at least there is a workaround

[EDIT 2017.05.16 @ 7:52PM MST]
After I reverted my changes and used the original source from GitHub, my build and upload to the Windows Store worked. Again, for anyone else that may stumble on this problem:

Add XXXXX.GameName to the reserved names under App Management :: Manage App Names

anonymous_user_537a337d · May 16, 2017, 10:50pm

I’m still waiting on approval for the XboxLive Creators Program. I’m a little confused though because under my Account Settings I have an Xbox One Developer console. It seems odd to have access to development on the Xbox but not the Live Services. Is that for local testing only then? Shoot (pun intended), XNA Creators Club had access to some form of the Live Services, if I remember correctly.

anonymous_user_582995091 · May 17, 2017, 7:19pm

Alright, new batch of changes just went in. Relevant to active issues in this thread:

The package DisplayName, PublisherDisplayName and Description are now bound to localized strings. These can be authored in resw files located in [Game]\Build\UWP[culture]\resources.resw. Building and deploying will automatically generate stubs for you if these files don’t already exist. You can then open them up and adjust the string values to match your Store display name etc. in your various territories. It’s a little clunky that you can’t just use UE’s localization system and formats, but it should help for now.
There are a couple of new settings in the UWP platform settings menu. One in particular flags the title as using Xbox Live via the Creators Program, per my proposal earlier in the thread. Another allows you to set the compiler version used for your project independently of the IDE (and is the only way to control the compiler used when building via the Editor) - it’s the same as the compiler version setting on the Windows platform page.

A reminder on the Xbox Live Creators Program: you still need to be accepted into the program for the new setting to have any effect. Again, the need for acceptance is temporary to the early stages of program rollout. And if you have access to Live already through a different program (e.g. ID@Xbox) you should not enable this setting.

anonymous_user_537a337d · May 17, 2017, 7:56pm

For debugging, what build configuration do you use for UWP?

Normally I use DebugGame Editor for the Win64 Platform, and it works well. I noticed that twenty-five projects are skipped for Debug Editor, and DebugGame Editor for UWP64. Also, the actual game project isn’t included in the build or deploy. What is the correct choice?

[EDIT]
Debug appears to be working. . .

Now I understand the issue of COOKED and UNCOOKED. I have to resolve it though.

Are we still able to modify our game in the Editor while debugging with Visual Studio?

anonymous_user_537a337d · May 17, 2017, 9:13pm

For the Cook on the Fly issue I setup a shortcut to the UWP UE Editor, then modified the Target to load my project with the needed switch:



E:\UEUWP\MICROSOFT_UWP_UNREAL\Engine\Binaries\Win64\UE4Editor.exe \MyDir\UWPSource\MyProject.uproject -run=cook -cookonthefly

A few log messages later the console output stops at:

And from Visual Studio, with Debug UWP64 built, pressed F5 and my game executed properly.

anonymous_user_537a337d · May 17, 2017, 9:26pm

Visual Studio isn’t honoring my breakpoints for: Debug, DebugGame, . . .

anonymous_user_582995091 · May 18, 2017, 12:38am

You probably need to manually point VS at the pdb file. It doesn’t get copied into the temporary layout used for running under the debugger (we skip it because tends to be a large file), so it’s not automatically located adjacent to the exe. This is a one-time thing - after you’ve done it VS will remember the association.

Open up debug->windows->modules, locate your exe (probably at the top), right-click and hit load symbols, then locate your pdb (in [Game]\Binaries\UWP64).

anonymous_user_537a337d · May 18, 2017, 6:05pm

;710446:

Alright, new batch of changes just went in. Relevant to active issues in this thread:

The package DisplayName, PublisherDisplayName and Description are now bound to localized strings.

There are a couple of new settings in the UWP platform settings menu. One in particular flags the title as using Xbox Live via the Creators Program, per my proposal earlier in the thread. Another allows you to set the compiler version used for your project independently of the IDE (and is the only way to control the compiler used when building via the Editor) - it’s the same as the compiler version setting on the Windows platform page.

A reminder on the Xbox Live Creators Program: you still need to be accepted into the program for the new setting to have any effect. Again, the need for acceptance is temporary to the early stages of program rollout. And if you have access to Live already through a different program (e.g. ID@Xbox) you should not enable this setting.

Thank you .

anonymous_user_537a337d · May 18, 2017, 9:03pm

I just got approval of Xbox Live Services

I’m doing some cleanup on my UI now and should finish no later than tomorrow. Afterwards, I’ll start the XboxLive integration and can provide updates to anyone that may be interested.

Should I stay in this thread or start another one?

anonymous_user_537a337d · May 19, 2017, 7:05am

This may be a dumb question: can we access other UWP API’s, particularly the UI:

anonymous_user_582995091 · May 19, 2017, 5:39pm

The build system is set up so that you have access to APIs for which the ‘API Contract’ is listed as ‘Windows.Foundation.UniversalApiContract’ anywhere in C++ code. APIs under Windows.UI.XAML, however, will mostly not work, even though they’re in the universal contract, because we don’t create the UE game window as a XAML window. While there are docs out there that discuss overlaying XAML UI on a DirectX panel, that’s not the approach I’d typically recommend to games - instead I’d encourage you to draw your UI as you always have, to your game’s swap chain. That way you don’t have to go relearn how to get the perf and look you’re after, and it’s much easier to ship multiplatform.

UI APIs that pop external windows are typically not part of the XAML space and, per above, will work. The ones games are most likely to need (notably message box, and Xbox Live UI) should be wrapped with UE interfaces (e.g. FPlatformMisc::MessageBoxExt, methods of IOnlineExternalUI) again to facilitate multiplatform dev. But if you do need to add something more, say a FilePicker for some reason, you can. Be careful to only interact with Windows UI from the main game thread though, otherwise you’ll hit exceptions from violating the UWP threading model.

If you need to use a WinRT API outside the universal contract you can do that too! But you’ll need to add a reference to the contract from the build.cs file of the module where you wish to use it.



		string StorageApiMetadata = VCEnvironment.GetLatestMetadataPathForApiContract("Windows.Gaming.XboxLive.StorageApiContract");
		if (!string.IsNullOrEmpty(StorageApiMetadata))
		{
			PrivateWinMDReferences.Add(StorageApiMetadata);
		}

anonymous_user_537a337d · May 19, 2017, 8:26pm

;710446:

Alright, new batch of changes just went in. Relevant to active issues in this thread:

The package DisplayName, PublisherDisplayName and Description are now bound to localized strings. These can be authored in resw files located in [Game]\Build\UWP[culture]\resources.resw. Building and deploying will automatically generate stubs for you if these files don’t already exist. You can then open them up and adjust the string values to match your Store display name etc. in your various territories. It’s a little clunky that you can’t just use UE’s localization system and formats, but it should help for now.

There are a couple of new settings in the UWP platform settings menu. One in particular flags the title as using Xbox Live via the Creators Program, per my proposal earlier in the thread. Another allows you to set the compiler version used for your project independently of the IDE (and is the only way to control the compiler used when building via the Editor) - it’s the same as the compiler version setting on the Windows platform page.

Okay, I can see everything that you mentioned, and it makes sense. But I am running into a problem with the manifest in that ms-resource:ProjectName, ms-resource:CompanyName, and ms-resource.Description are the final results in the fields:

Am I doing something wrong?

A note: I can confirm that the resource.resw was created for each supported language.

anonymous_user_582995091 · May 19, 2017, 8:35pm

That looks right to me!

The ms-resource:<resource key> syntax indicates to the system that the value needs to be looked up at runtime from the compiled package resources (this is the resources.pri file, generated by the makepri.exe step in the build process). If you run the packaging step now to create an appx, and then double-click that to install, you should see the strings you entered into your resw files, selected based on the current OS language/locale settings.

anonymous_user_537a337d · May 19, 2017, 8:50pm

The APPX, and its manifest, were generated from the UE4 Editor package command (File->Package). Both contain what I provided above.

If I understand you correctly I should delete the existing APPX file, and regenerate it again with the makeappx command. Is that correct?

anonymous_user_582995091 · May 19, 2017, 9:20pm

The final manifest should look just like what you provided. What do you see in the appx installer UI when you double-click the appx that the Editor package command generated for you?