Current guidance given to users is that if any of the config values needs to reference environment variables, that they should not be added to the config, but should rather be specified at the command-line. There isn't any reason for this though. Resolve-PackageParameters can be updated to call [Environment]::ExpandEnvironmentVariables() to resolve any config value that has environment variables specified.

We sometimes have difficulty debugging submissions that use the Update-* cmdlets. The Update-* should have more Verbose output to help in this scenario. When a patch switch is provided, the cmdlet should write that the switch is present and, if possible, the new value being used.

Currently, the logger outputs timestamps (which are super useful for diagnosis), but they default to local time. 

When StoreBroker is used in conjunction with web applications, being able to output UTC timestamps will simplify correlating with other log sources that do the same.

Per GitHub security vulnerability analysis
we need to upgrade Microsoft.Data.OData to version 5.8.4 or later in RESTProxy/packages.config .

CVE-2018-8269 Details: A denial of service vulnerability exists when OData Library improperly handles web requests, aka "OData Denial of Service Vulnerability." This affects Microsoft.Data.OData.

For example:
<package id="Microsoft.Data.OData" version="5.8.4" />

PNG is the only supported image type per MSDN documentation. Given that, we should help users identify problematic screenshots as early in the process as possible (which would be when they try to create their StoreBroker package.

Update-ApplicationFlightSubmission uses switch “UpdatePublishMode” (StoreIngestionFlightingApi.ps1@1271).
In this function, Patch-ApplicationFlightSubmission is called sending “UpdatePublishMode” parameter (StoreIngestionFlightingApi.ps1@1368)
Patch-ApplicationFlightSubmission expects “UpdatePublishModeAndVisibility” (StoreIngestionFlightingApi.ps1@1586)

If Update-ApplicationFlightSubmission is called with -UpdatePublishMode as documented, this value will not be correctly propagated to Patch-ApplicationFlightSubmission.

StoreBroker provides piece-meal cmdlets for interacting with the various parts of the StoreAPI, as well as convenience cmdlets that perform broader tasks using these individual cmdlets.

When users perform the first submission to a new flight, we provide them with the commands to run that will successfully complete their first submission. Even still, users experience some difficulty completing this scenario, whereas there is not as much difficulty completing subsequent submissions. StoreBroker can provide a convienence cmdlet (or alter an existing cmdlet) that both creates the new flight and completes the first submission to that flight, that way the user is protected from these specific issues.

The Start-SubmissionMonitor should allow the shell to know the result by returning a status variable, which will be very useful in automated build servers.

Hi I am trying to access Azure Blob from the sample C# Console Application (for Retrain Azure Machine Learning Models Programmatically) and ran into this problem.

I am wondering if this is caused by the version of Azure Portal (maybe the codes are meant to access the classic Azure portal as indicated by Microsoft DOCs), or is caused by the package Microsoft.WindowsAzure.Storage (referenced to :\Users\user\source\repos\ConsoleApp1\packages\WindowsAzure.Storage.8.7.0\lib\net45\Microsoft.WindowsAzure.Storage.dll)

I have installed both: PM> Install-Package Microsoft.AspNet.WebApi.Client and Install-Package WindowsAzure.Storage -Version 8.7.0

static void UploadFileToBlob(string inputFileLocation, string inputBlobName, string storageContainerName, string storageConnectionString)
{
// Make sure the file exists
if (!File.Exists(inputFileLocation))
{
throw new FileNotFoundException(
string.Format(
CultureInfo.InvariantCulture,
"File {0} doesn't exist on local computer.",
inputFileLocation));
}

        Console.WriteLine("Uploading the input to blob storage...");

        var blobClient = CloudStorageAccount.Parse(storageConnectionString).CreateCloudBlobClient();
        var container = blobClient.GetContainerReference(storageContainerName);
        container.CreateIfNotExists();
        var blob = container.GetBlockBlobReference(inputBlobName);
        blob.UploadFromFile(inputFileLocation, FileMode.Open);
    }

Severity Code Description Project File Line Suppression State
Error CS1503 Argument 2: cannot convert from 'System.IO.FileMode' to 'Microsoft.WindowsAzure.Storage.AccessCondition' ConsoleApp1 C:\Users\user\source\repos\ConsoleApp1\ConsoleApp1\Program.cs 116 Active

Any help or clues appreciated.

Shortened paths (like c:\program~1 for c:\program files) don't get expanded by Resolve-Path. This normally wouldn't be a problem except for instances of logic where we retrieve a list of files under that path, and then attempt to parse out that root path (example: in PackageTool, when we do this:

$split = $xmlFilePath -split $PDPRootPath, 0, "SimpleMatch | Where-Object { -not [String]::IsNullOrWhiteSpace($_) } | Select-Object -First 1
$language = $split -split "\", 0, "SimpleMatch" | Where-Object { -not [String]::IsNullOrWhiteSpace($_) } | Select-Object -First 1

In a scenario like that, the full name of the file will be expanded and not the shortened version, thus the initial part won't be correctly lobbed off.

We need to do something like this:

$inputPath = (Get-Item -Path $inputPath).FullName

for any $inputPath that we get from the user where a scenario like this might be possible. That will ensure that the path is expanded before we operate on it.

Just discovered this undocumented behavior of Dev Center API.
I have one app under my account that is Unavailable for anyone, only for testers with redeem code can get it.

If I query submission details for this app, the API returns for this submission pricing->priceId=Base. But When I try to update this submission and update for instance only the package, with the same pricing value, it ends on this error:

400 | Bad Request
The remote server returned an error: (400) Bad Request.
InvalidParameterValue : You must select a valid base price
MS-CorrelationId: 3e90dc80-cd4f-4ec9-a1eb-d99cf8e837ab
At C:\Users\marti\Documents\WindowsPowerShell\Modules\StoreBroker\StoreBroker\StoreIngestionApi.psm1:1984 char:9

It looks like Price Tier "Base" is not valid in the top "pricing", even though the Dev Center API returns it in this case. When I changed the priceId to "Free", submission update.
Expected behavior - if Dev Center API returns "priceId" : "Base" for any submission, it should accept it back when updating that submission without throwing errors.

Note, I know this is probably not the best place to report these types of errors. I've already tried to report several similar errors through the Dev Center Feedback form but with no success or answer. If you know better place where to report errors in the Dev Center APi, please, let me know!

Write-Log currently outputs both to the console and the text log file.  

For some server applications, store broker can be invoked through a non-interactive console, which causes Write-Log to fail if console logging is enabled for a given log level (typically the default or "Info" level and above). 

If the console is non-interactive, there is no point logging to it anyway, so console output should be suppressed.

Environment

• ModuleVersion 1.18.1
• PSVersion 5.1.17134.228
• Windows 10 - 1803

Summary

Again, this may be more of an issue on the Store backend (Fiddler suggests that StoreBroker isn't interfering) but I am having trouble with getting InAppProductSubmissions to succeed. All I am attempting to change is pricing from Free to a TierX, now that our account is configured with a payout. Sometimes they stick on CommitStarted, though I also got "Submission has active validation errors which cannot be exposed via API, please visit https://developer.microsoft.com to see the issue." (No details were available on the dashboard)

Based on inspections from Fiddler, it seems to be an issue with isAdvancedPricingModel. Creating a new submission, it is $true, but the Store returns $false when I PUT the changes. (I am able to use the advanced tiers if I create/edit/commit the submission within the portal, and browsing the tiers within the portal only shows the advanced set)

Code

$submission = New-InAppProductSubmission -IapId $IapId -Force
Set-InAppProductSubmission -IapId $IapId -UpdatedSubmission @{
    id = $submission.id
    pricing = @{
        isAdvancedPricingModel = $true
        priceId = "Tier1152"
    }
}

Results in a request:

PUT https://manage.devcenter.microsoft.com/v1.0/my/inappproducts/.../submissions/... HTTP/1.1

{ 
  "id":"...",
  "pricing":  {
    "isAdvancedPricingModel":  true,
    "priceId":  "Tier1152"
  }
}

and response:

HTTP/1.1 200 OK
Content-Length: 1088
Content-Type: application/json; charset=utf-8
MS-CorrelationId: 373dc845-b94b-4608-9535-257842daae67
MS-RequestId: ed6e6429-ab2f-4921-88ab-921319fdef33
MS-CV: f+l06wOq2EGbiCO+.8
MS-ServerId: 101112022
Date: Tue, 28 Aug 2018 19:52:17 GMT

{"id":"...","pricing":{"marketSpecificPricings":{},"sales":[],"priceId":"Tier1152","isAdvancedPricingModel":false}}

Expected

isAdvancedPricingModel shouldn't change with the PUT, especially since documentation says it is read only.

Other small question that doesn't seem worth its own issue: I have thousands of in-app products that I'm working toward processing, and will need continued updates with price changes. I'm seeing ~30-60 seconds each, mostly spent waiting on the server in Cloning current submission. Is there a better way to batch this work that I'm missing? My understanding is the REST API is the official way, but it's so slow.

When a client script uses a variable with the same name used in a ValidationScript that references other parameters by name, the validation can cause a false positive, because PowerShell will see the client's script variable in the validation script.

An example of this is when calling Update-ApplicationFlightSubmission sending required parameters and specifying the "-Force" switch without specifying the SubmissionId parameter, but the client script defines a $SubmissionId variable:

$submissionId = "123456..";
Update-ApplicationFlightSubmission -Force;

At this moment, the validation script for Update-ApplicationFlightSubmission will fail because it expects NOT to see a variable called $submissionId, which is now visible since the client script defined it.

This is fixed by moving the validation from the Validation Script to the function body for any ValidationScript that references other parameters.

This is confirmed to happen in Update-ApplicationFlightSubmission, but this should be changed in any ValidationScript code.

Issues like we've seen with #71 would apparently be easier to diagnose on the API side if we were able to provide the activityId property associated with the API call. That property is only ever seen when there is a 500 / Internal Server error, and the response would look something like this:

{"statusCode":500,"message":"Internal server error","activityId":"abcdef01-2345-6789-abcd-ef0123456789"}

Similar to Production submissions, the API has now added support for isMinimalResponse to new flight submissions. StoreBroker needs to be updated to take advantage of this, similar to what was done for Issue #122.

Version: '1.8.1'
OS: 1703 (15063)
PowerShell Version: 5.1.15063

I've been using the tools for a couple of months now with no problems. I went to make a submission today and I keep seeing this error:

Write-Log : 2017-05-02 17:17:15 : adobin : Cannot convert argument "accessCondition", with value: "Open", for
"UploadFromFile" to type "Microsoft.WindowsAzure.Storage.AccessCondition": "Cannot convert value "Open" to type
"Microsoft.WindowsAzure.Storage.AccessCondition". Error: "Invalid cast from 'System.IO.FileMode' to
'Microsoft.WindowsAzure.Storage.AccessCondition'.""

It seems to be fixed if I run the command as an admin but I would prefer to not have to do that as it seemed to work before. Is this by design?

See this blog post.

Specifically, adding support for trailers and some additional screenshot types.

Hi,
this should probably be changed - the Getting Your AppID section in SETUP.md is a bit confusing. It shows AppIn in format 0ABCDEF12345 but then it uses App Name in the command.
I found my AppId in Dev Dashboard and was wondering for few hours why the command is not working. The command should either use "id -like 0ABCDEF12345" or the difference between App name and Id should be described in a better way. Or just point the developer to the App management -> App identity section in Dashboard where the AppId is located.

Related issue that should probably be fixed as well - more meaningful error messages (should I create another ticket?).

If this command

Get-Applications -GetAll | Where-Object primaryName -like "*<appName>*" | Format-Application

does not find any app, only this error message is displayed. I had to dig through the source code to discover that $ApplicationData in Format-Application is null and Write-Log then receives invalid Message parameter. This pointed me to wrong AppId in the command.

Write-Log : Cannot validate argument on parameter 'Message'. The argument is null or empty. Provide an argument that is not null or empty, and then try the command again.
At C:\Users\marti\Documents\WindowsPowerShell\Modules\StoreBroker\StoreBroker\StoreIngestionApplicationApi.ps1:303 char:18
+        Write-Log $($output -join [Environment]::NewLine)
+                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidData: (:) [Write-Log], ParameterBindingValidationException
    + FullyQualifiedErrorId : ParameterArgumentValidationError,Write-Log

According to the API documentation for the listing's image object, here, there are many image types that are not supported by StoreBroker.

Currently, PackageTool strictly supports screenshot images according to this map:

                        $imageTypeMap = @{
                            "DesktopImage" = "Screenshot";
                            "MobileImage"  = "MobileScreenshot";
                            "XboxImage"    = "XboxScreenshot";
                            "HoloLensImage" = "HoloLensScreenshot";
                            "SurfaceHubImage" = "SurfaceHubScreenshot";
                        }

We can easily change to allow the user to specify any image type in the PDP.xml and use that value directly. We can keep the existing image type map for back-compat reasons. Making this change would allow users to upload additional images besides screenshots, such as 1080x1080 images for the Store logo, which is recommended by the Store

A tenant is limited to 20 requests per minute.
If that is exceeded, future requests will get back a 429 error until the next minute arrives.

We should update Invoke-SBRestMethod to auto-retry requests that fail due to 429 errors with an exponential fallback timeframe. We should also consider randomizing the initial wait time to minimize the number of retries each instance may have to do.

To fully fupport IAP's, we need to have a PDP-like XML schema that can describe all the metadata that a PDP has, and then we need to create New-IapSubmissionPackage to generate the json/zip payload for use with the existing IAP functions.

Environment:

• ModuleVersion 1.17.0
• PSVersion 5.1.17134.165
• Windows 10 - 1803

This may be more of a failure with the Store backend than StoreBroker, but using this command:

Update-InAppProductSubmission $IapId $dataPath -UpdateListings -UpdatePricingAndAvailability -Force -AutoCommit

Sometimes, the backend returns 503, but actually creates a submission. Since the -Force check has already been done, the subsequent retry produces an error:

DONE (FAILED) - Operation took 8 second(s) [Cloning current submission for IAP: ...]
WARNING: 2018-07-26 11:25:03 : AdamHewitt : 503 | Service Unavailable
The remote server returned an error: (503) Server Unavailable.
InvalidOperation : This operation cannot be completed at this time. Retry your operation using exponential backoff.
MS-CorrelationId: c01d1257-1685-4217-b46d-dc11c11ccb9d
WARNING: 2018-07-26 11:25:03 : AdamHewitt : This status code (503) is configured to auto-retry (via
$global:SBAutoRetryErrorCodes).  StoreBroker will auto-retry (attempt #1) in 1 minute(s). Sleeping...
DONE (FAILED) - Operation took 5 second(s) [Cloning current submission for IAP: ...]
Write-Log : 2018-07-26 11:26:09 : AdamHewitt : 409 | Conflict
The remote server returned an error: (409) Conflict.
InvalidState : In app product already has an in-progress submission

Expected: the retry should succeed unless the service is still unavailable. Either by checking again for a pending submission (and deleting it) or use the created submission and continue.

Per the MSDN documentation, neutral is the default value for ProcessorArchitecture.

Read-AppxMetadata in PackageTool.ps1 should be updated to default to neutral when it comes back with an empty or null value.

In ConvertFrom-ExistingSubmission.ps1 if user enters relative -OutPath and launches the script from non-default folder, the OutPath folder is created in a wrong place and the $xml.Save($filePath) throws an exception because it can't find the target nested folder.

.\ConvertFrom-ExistingSubmission.ps1 -AppId "ABCDEFGH" -Release "Master" -PdpFileName "PDP.xml" -OutPath "PDPOut"

This creates the OutPath folder in Extensions directory, but $xml.Save($filePath) expects it in StoreBroker root directory.

Expected solution: Ensure-PdpFilePath should return absolute path where the OutPath folder was created.

What you want to achieve / what is the problem that you want to address.

I tried to publish my application with the storebroker module but when I monitored the submission using Get-ApplicationSubmission I get this issue:

Status : CommitFailed
Status Details [Errors] :
     code                  details
     ----                  -------
     InvalidParameterValue Validation error: MultipleInstancesOfGamingOptions

What have you tried so far.

If I publish my application manually within the dev center with the same .appxbundle, I can reach the 'certification process' with no issue.
I checked your USAGE.md, but I can not figure it out the problem.

By checking the application submission, I have the following game options :

Gaming Options
     Genres                          :
     isLocalMultiplayer              : False
     isLocalCooperative              : False
     isOnlineMultiplayer             : False
     isOnlineCooperative             : False
     localMultiplayerMinPlayers      :
     localMultiplayerMaxPlayers      :
     localCooperativeMinPlayers      :
     localCooperativeMaxPlayers      :
     isBroadcastingPrivilegeGranted  : False
     isCrossPlayEnabled              : False
     kinectDataForExternal           : Disabled

Would you have some information about that issue ?

In the first question in the FAQ the command

Set-ApplicationSubmission -AppId $appId -UpdatedSubmissionId $sub

should probably be

Set-ApplicationSubmission -AppId $appId -UpdatedSubmission $sub

Just noticed this strange behavior. We're using the StoreBroker for publishing new beta flights for our UWP app. Recently the app caused certification failure error "1201" and since then the StoreBroker fails with Error 500.
In case of app certification issue, the server should not return 500 error, but rather some more helpful 4xx message.

ModuleVersion = '1.10.0'

Write-Log : 2018-11-28 10:12:21 : gitlab.runner : 500 | Internal Server Error
Vzdaleny server vratil chybu: (500) Vnitrni chyba serveru.
InternalServerError : An internal server error occurred while processing the operation.
MS-CorrelationId: ed267ef2-5ab1-4d34-b503-209b9042c2c5
At C:\Users\gitlab.runner\Documents\WindowsPowerShell\Modules\StoreBroker\StoreBroker\StoreIngestionApi.psm1:1984 char:
9
+         Write-Log $newLineOutput -Level Error
+         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
    + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Write-Log

My package has localized listing data, but the screenshots have nothing to localize - they are language/region agnostic. I'd like to be able to submit a common screenshot to be used everywhere, rather than creating required the folder structure per language and duplicating the file N times.

Minor clarification to the wordings in "Manual Submissions" around patching in values from the json file into the submission payload.  

From @danbelcher-MSFT 's comment in #94, we can consider simplifying the initialization of the global configuration variables that we have by using a centralized helper method, and powered by a hashtable with variable name and default value.

We currently have three separate Initialize-*GlobalVariables methods across Helpers.ps1, StoreIngestionApi.psm1 and Telemetry.ps1, and they all follow the exact same pattern (with the exception of the initialization behavior of $SBLogPath and $SBLoggingEnabled.

With the change in the latest version of the Windows SDK 10.0.17763 the default packaging format for UWP Store submissions has changed from AppX to MSIX, are there plans to update the Store Broker scripts to support this packaging format along with the bundle and upload variants?

Customer has requested that New-SubmissionPackage adds some additional metadata on the packages that it processes to the json that it creates.  All of this information (except for Min OS Version) is already gathered and embedded into the new name for the APPX -- this is just about making that same data more easily consumable via JSON.

Specifically:

• Minimum Target OS Version
• Array of targeted device types (e.g. Mobile, Desktop, Team, etc...)
• Version
• Array of targeted architectures.

This information will then need to be stripped out by Patch-ApplicationSubmission since those properties will be invalid with API interaction.

Need to review the new API's and see the best way to expose them.

User feedback is that the ConvertFrom-ExistingSubmission.ps1 and ConvertFrom-ExistingIapSubmission.ps1 scripts should be callable as normal StoreBroker functions.

To make this a non-breaking change, the script files should remain, but should invoke the actual function instead so that existing callers remain unaffected.

Per pull #105, it would be great if we could find a way to automatically maintain the contributor list within CHANGELOG.md, as well as ways to possibly auto-tag master whenever a new change gets pulled in.

More info on the library can be found on the GitHub page.

We'll need to add a new NuGet dependency (Microsoft.Azure.Storage.DataMovement) which builds on top of the pre-existing dependency on WindowsAzure.Storage. The NuGet package brings in a number of other dependencies too, and I'm not yet sure if the rest can be ignored for our scenarios. More investigation will need to happen.

Right now, in Set-SubmissionPackage, after we create the $cloudBlockBlob we call the member method UploadFromFile(). It looks like with Azure Storage DML, we'd instead call TransferManager.UploadAsync
. Calling async methods from PowerShell is not typical, but initial testing indicates we'd be able to call it by calling [Microsoft.WindowsAzure.Storage.DataMovement.TransferManager]::UploadAsync(...).GetAwaiter().GetResult(); which would turn it into a synchronous call.

We'd also probably want to follow some of the DML best practices around increasing the default connection limit and turning off 100 continue.

If that works, that would retain existing behavior where StoreBroker just sits there until the upload completes. If we want to do one better, we could look into what it would take to display true upload status (percentage uploaded/remaining as opposed to just time elapsed), by leveraging SingleTransferContext and registering a ProgressHandler to report back status as the upload occurs.

Currently we have -AddPackages which will simply append the packages from the StoreBroker payload to the cloned submission, and we have -ReplacePackages which will remove all current packages and only keep the ones within the StoreBroker payload.

The Store apparently has a maximum limit of 30 packages for any submission, and some teams that flight frequently hit this limit more than once per month, which has required manual intervention via the Dev Portal. Generally, most of those packages are redundant, meaning that they'll never be given to the user because there is a newer package with all the same characteristics (min OS version, architecture, platform, etc...) that the Store will give to users instead.

As of commit ...b805db4, StoreBroker inspects all of the appx files in the payload and adds additional relevant metadata about those packages to the final json. This additional metadata should be sufficient for determining which packages will become irrelevant once the cloned submission is published.

The goal for -UpdatePackages would be to mark only those redundant packages as PendingDelete, leaving the existing ones as Uploaded. It would then add the new ones as PendingUpload, as it already does today for the other two switches.

PackageTool.ps1 uses the $script:jsonConversionDepth parameter when writing compressed JSON. This tells the ConvertTo-Json cmdlet how deep it should expand objects. Currently, this value is undefined and so ConvertTo-Json uses the default value of 5. This results in the output JSON not being fully expanded. The fix will be to define the script variable referenced and give it a value of 20.

For example, the Format-* cmdlets generally accept multiple objects from the pipeline but do not work for directly passing a collection via parameter.

This works:
$sub1, $sub2 | Format-ApplicationSubmission

but this should also work:
Format-ApplicationSubmission -ApplicationSubmissionData ($sub1, $sub2)

Currently the Read-AppxMetadata cmdlet extract the package, any packages inside the package until it gets to the AppManifest.xml. This can take more than 5 minutes for large packages.

We should consider using IAppxManifestReader to save 5 minutes or more per build for large packages.

Hi,
we're noticing (500) errors when cloning flight submission, see below.
Any idea, what's wrong? This script worked fine previous two weeks, the issue started today.

2017-10-25 11:41:02 : gitlab.runner : VERBOSE : Using PROD service endpoint
2017-10-25 11:41:02 : gitlab.runner : VERBOSE : Cloning current submission for App: 9wzdncrdn1b1 Flight: e7a5bd58-a0e0-40e5-a7d7-05322af7b5e1
2017-10-25 11:41:02 : gitlab.runner : VERBOSE : Accessing [Post] https://manage.devcenter.microsoft.com/v1.0/my/applications/9wzdncrdn1b1/flights/e7a5bd58-a0e0-40e5-a7d7-05322af7b5e1/submissions [Timeout = 0]
2017-10-25 11:46:03 : gitlab.runner : VERBOSE : DONE (FAILED) - Operation took 268 second(s) [Cloning current submission for App: 9wzdncrdn1b1 Flight: e7a5bd58-a0e0-40e5-a7d7-05322af7b5e1]
2017-10-25 11:46:03 : gitlab.runner : VERBOSE : Executing:         Set-TelemetryException -Exception $ex -ErrorBucket $errorBucket -Properties $localTelemetryProperties

2017-10-25 11:46:03 : gitlab.runner : VERBOSE : Executing:             Flush-TelemetryClient -NoStatus:$NoStatus

2017-10-25 11:46:06 : gitlab.runner : ERROR : 500 | Internal Server Error
Vzdálený server vrátil chybu: (500) Vnitřní chyba serveru.
 : Internal server error

The store backend will support sending isMinimalResponse when a new submission is created. This will help the backend to reduce the load and increase the success rate of the creation of the submissions using the API.

At the moment, the only functions that specify OutputType are those that PSScriptAnalyzer complained about. We should consider adding `[OutputType()] to all functions for consistency.

We'd like to support a simpler installation option of StoreBroker using NuGet (and publish the package through nuget.org)

The package should include:

  \Documentation\*
  \Extensions\*
  \PDP\*
  \StoreBroker\*
  \*.md
  \LICENSE

Some users are attempting to upload their zip files to a submission whose fileUploadUrl has already expired. When they do so, they see this error:

Exception calling "GetResult" with "0" argument(s): "The transfer failed: The remote server returned an error: (403) Forbidden. Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature.."

We should look into either catching/parsing that error and providing a more helpful one (the fileUploadUrl is typically only valid for 24 hours after the submission has been created) or we should just add a new FAQ to address this issue, in order to help users out.

Currently, when retrieving a specific image for a language's listing, StoreBroker will throw a warning if multiple images are found with the same name under the language's image folder. StoreBroker then picks the first image it found.

Instead, StoreBroker should throw an exception and not attempt to resolve the ambiguity. We should handle this as a breaking change and increment the major version of the NuGet package.

The Store API limits an individual ClientId to 20,000 - 30,000 requests/24 hours.
If a proxy is serving enough customers, it's possible that the proxy might hit that limit and thus all users might be blocked until the cool-off period expires.

A potential workaround is to create multiple ClientId/ClientSecrets associated with the same Tenant, and have the proxy automatically rotate between them, round-robin style, opaque to clients (so that clients don't have to change anything on their end).

This would require changing the configuration schema that is used for the proxy, and then altering the logic used for retrieving the correct access token.

This is probably not the best place, where to report it, but I'm getting this error whenever I try to connect to Windows Store submission API:

(503) Server Unavailable, Account service is experiencing issue. Please try again later.

Same happens when I try to connect to the backend manually in my test app.
Not sure, if this is just problem of my app, account or global, but in case it's global, any chance you could ping the right people that could fix it? Thanks!

With PR #100 , advanced listing support was added for the media assets (like trailers and additional assets) as well as for gaming options. However, there are a couple additional listings metadata text fields that should be added to the PDP, New-SubmissionPackage and then Patch-ApplicationSubmission as well:

From the docs

• shortDescription - Only used for games. This description appears in the Information section of the Game Hub on Xbox One, and helps customers understand more about your game. 500 characters
• shortTitle - A shorter version of your product’s name. If provided, this shorter name may appear in various places on Xbox One (during installation, in Achievements, etc.) in place of the full title of your product. 50 characters
• sortTitle - If your product could be alphabetized in different ways, you can enter another version here. This may help customers find the product more quickly when searching. 255 characters
• voiceTitle - An alternate name for your product that, if provided, may be used in the audio experience on Xbox One when using Kinect or a headset. 255 characters
• devStudio - Specify this value if you want to include a Developed by field in the listing. (The Published by field will list the publisher display name associated with your account, whether or not you provide a devStudio value.) 255 characters

Also: trailer title length is wrong...should be 255 characters -- Need to update the PDP schema, sample and ConvertFrom-ApplicationSubmission script