Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Microsoft provides an identity name and family name that the program won't accept #120

Open
ncodeyx opened this issue Aug 3, 2019 · 4 comments

Comments

@ncodeyx
Copy link

ncodeyx commented Aug 3, 2019

Microsoft provides an identity name and family name starting with numbers. When attempting to build with supplied packageIdentity and packageName, i get the following error:

MakeAppx : error: Error info: error C00CE169: App manifest validation error: The app manifest must be valid as per schema: Line 26, Column 18, Reason: '238....' violates pattern constraint of '([A-Za-z][A-Za-z0-9])(.[A-Za-z][A-Za-z0-9])*'.
The attribute 'Id' with value '238...' failed to parse.

Microsoft doesn't allow me to upload it to their store without this being fulfilled.

@ncodeyx ncodeyx changed the title Microsoft provides an identity name that the program won't accept Microsoft provides an identity name and family name that the program won't accept Aug 3, 2019
@ncodeyx
Copy link
Author

ncodeyx commented Aug 3, 2019

Looks like only identityName needs to be filled out and not the family ID. You should make this more clear in the documentation.

@jameshfisher
Copy link

Duplicate of #82

jameshfisher added a commit to jameshfisher/electron-windows-store that referenced this issue May 5, 2020
There's a lot of terminological/conceptual confusion in the current API.

An .appx file should have an `AppXManifest.xml` which looks like the following,
omitting unimportant elements:

    <?xml version="1.0" encoding="utf-8"?>
    <Package ...>
        <Identity Name="12345MyCompany.MyApp" ... />
        ...
        <Applications>
            <Application Id="MyApp" ...>
                ...
            </Application>
        </Applications>
    </Package>

Notice that there are two separate identities: the Package Name, and the Application Id.

When you run `electron-windows-store`,
it generates an `AppXManifest.xml` from the config you supply.
[The template is here](https://github.com/felixrieseberg/electron-windows-store/blob/master/template/appxmanifest.xml)
and it looks like:

<?xml version="1.0" encoding="utf-8"?>
<Package ...>
  <Identity Name="${identityName}" ... />
  ...
  <Applications>
    <Application Id="${packageName}" ...>
      ...
    </Application>
  </Applications>
</Package>

Notice in the variable names:
it calls the package name `identityName`,
and calls the application id `packageName`.
These template variables are subtituted by the user-supplied config like so:

    lib/convert.js:      result = result.replace(/\${identityName}/g, program.identityName || program.packageName)
    lib/convert.js:      result = result.replace(/\${packageName}/g, program.packageName)

This means, to create a correct `AppXManifest.xml`,
you need to call it like so:

    const convertToWindowsStore = require('electron-windows-store');
    convertToWindowsStore({
        identityName: '19463Vidrio.Vidrio',  // This is actually the package name!
        packageName: 'Vidrio',  // This is actually the application id!!
        // ...
    });

This is very confusing, and has led to many tickets:

    electron-userland#82
    electron-userland#114
    electron-userland#103
    electron-userland#120

The best way forward would be to introduce a separate `program.applicationId` config,
which is used in preference to the `packageName`.

What is the correct/recommended format for a package name?

I created an account on [the Microsoft Partner Center](https://partner.microsoft.com/en-us/dashboard/windows/overview)
with the name `MyCompanyName`.
I then created a new Product on [the Microsoft Partner Center dashboard](https://partner.microsoft.com/en-us/dashboard/windows/overview)
I chose the name `FooBarBazTest`.
Under "Product Identity", Microsoft says:

    Include these values in your package manifest:

    Package/Identity/Name: 12345MyCompanyName.FooBarBazTest
    Package/Identity/Publisher: CN=6D79A3CE-7EB5-466E-8EE1-D370291F7800
    Package/Properties/PublisherDisplayName: MyCompanyName

Note the package name `12345MyCompanyName.FooBarBazTest`.

I am building an `.appx` package using [electron-windows-store](https://github.com/felixrieseberg/electron-windows-store).
This is not strictly relevant -- the important things are that this tool
makes a file which looks like this:

    PS C:\Users\james\vidrio\windows2> type .\myelectronapp\pre-appx\AppXManifest.xml
    <?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:rescap="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities">
    <Identity Name="19463Vidrio.Vidrio"
        ProcessorArchitecture="x64"
        Publisher="CN=James Fisher, O=James Fisher, STREET=77 Broadwater Road, L=London, S=London, PostalCode=N17 6EP, C=GB"
        Version="0.3.0.0" />
    <Properties>
        <DisplayName>Vidrio</DisplayName>
        <PublisherDisplayName>Vidrio</PublisherDisplayName>
        <Description>No description entered</Description>
        <Logo>assets\SampleAppx.50x50.png</Logo>
    </Properties>
    <Resources>
        <Resource Language="en-us" />
    </Resources>
    <Dependencies>
        <TargetDeviceFamily Name="Windows.Desktop" MinVersion="10.0.14316.0" MaxVersionTested="10.0.14316.0" />
    </Dependencies>
    <Capabilities>
        <rescap:Capability Name="runFullTrust"/>
    </Capabilities>
    <Applications>
        <Application Id="19463Vidrio.Vidrio" Executable="app/Vidrio.exe" EntryPoint="Windows.FullTrustApplication">
        <uap:VisualElements
        BackgroundColor="#464646"
        DisplayName="Vidrio"
        Square150x150Logo="assets\SampleAppx.150x150.png"
        Square44x44Logo="assets\SampleAppx.44x44.png"
        Description="Vidrio for Windows">
            <uap:DefaultTile Wide310x150Logo="assets\SampleAppx.310x150.png" />
        </uap:VisualElements>
        </Application>
    </Applications>
    </Package>

It builds this using this template:
https://github.com/felixrieseberg/electron-windows-store/blob/master/template/appxmanifest.xml

This comes from this config:

  await convertToWindowsStore({
    name: '19463Vidrio.Vidrio',
    packageName: 'Vidrio',  // Pre-Electron Vidrio was using the name '19463Vidrio.Vidrio' but this is not even valid according to makeappx?!
  });

 makes the following call to `makeappx.exe`:

PS C:\Users\james\vidrio\windows2> & 'C:\Program Files (x86)\Windows Kits\10\bin\10.0.18362.0\x64\makeappx.exe' pack /d myelectronapp\pre-appx /p myelectronapp\19463Vidrio.Vidrio.appx /o
jameshfisher added a commit to jameshfisher/electron-windows-store that referenced this issue May 5, 2020
There's a lot of terminological/conceptual confusion in the current API.

An .appx file should have an `AppXManifest.xml` which looks like the following,
omitting unimportant elements:

    <?xml version="1.0" encoding="utf-8"?>
    <Package ...>
        <Identity Name="12345MyCompany.MyApp" ... />
        ...
        <Applications>
            <Application Id="MyApp" ...>
                ...
            </Application>
        </Applications>
    </Package>

Notice that there are two separate identities: the Package Name, and the Application Id.

When you run `electron-windows-store`,
it generates an `AppXManifest.xml` from the config you supply.
[The template is here](https://github.com/felixrieseberg/electron-windows-store/blob/master/template/appxmanifest.xml)
and it looks like:

<?xml version="1.0" encoding="utf-8"?>
<Package ...>
  <Identity Name="${identityName}" ... />
  ...
  <Applications>
    <Application Id="${packageName}" ...>
      ...
    </Application>
  </Applications>
</Package>

Notice in the variable names:
it calls the package name `identityName`,
and calls the application id `packageName`.
These template variables are subtituted by the user-supplied config like so:

    lib/convert.js:      result = result.replace(/\${identityName}/g, program.identityName || program.packageName)
    lib/convert.js:      result = result.replace(/\${packageName}/g, program.packageName)

This means, to create a correct `AppXManifest.xml`,
you need to call it like so:

    const convertToWindowsStore = require('electron-windows-store');
    convertToWindowsStore({
        identityName: '19463Vidrio.Vidrio',  // This is actually the package name!
        packageName: 'Vidrio',  // This is actually the application id!!
        // ...
    });

This is very confusing, and has led to many tickets:

    electron-userland#82
    electron-userland#114
    electron-userland#103
    electron-userland#120

The best way forward would be to introduce a separate `program.applicationId` config,
which is used in preference to the `packageName`.
jameshfisher added a commit to jameshfisher/electron-windows-store that referenced this issue May 5, 2020
There's a lot of terminological/conceptual confusion in the current API.

An .appx file should have an `AppXManifest.xml` which looks like the following,
omitting unimportant elements:

    <?xml version="1.0" encoding="utf-8"?>
    <Package ...>
        <Identity Name="12345MyCompany.MyApp" ... />
        ...
        <Applications>
            <Application Id="MyApp" ...>
                ...
            </Application>
        </Applications>
    </Package>

Notice that there are two separate identities: the Package Name, and the Application Id.

When you run `electron-windows-store`,
it generates an `AppXManifest.xml` from the config you supply.
[The template is here](https://github.com/felixrieseberg/electron-windows-store/blob/master/template/appxmanifest.xml)
and it looks like:

<?xml version="1.0" encoding="utf-8"?>
<Package ...>
  <Identity Name="${identityName}" ... />
  ...
  <Applications>
    <Application Id="${packageName}" ...>
      ...
    </Application>
  </Applications>
</Package>

Notice in the variable names:
it calls the package name `identityName`,
and calls the application id `packageName`.
These template variables are subtituted by the user-supplied config like so:

    lib/convert.js:      result = result.replace(/\${identityName}/g, program.identityName || program.packageName)
    lib/convert.js:      result = result.replace(/\${packageName}/g, program.packageName)

This means, to create a correct `AppXManifest.xml`,
you need to call it like so:

    const convertToWindowsStore = require('electron-windows-store');
    convertToWindowsStore({
        identityName: '12345MyCompany.Ghost',  // This is actually the package name!
        packageName: 'Ghost',  // This is actually the application id!!
        // ...
    });

This is very confusing, and has led to many tickets:

    electron-userland#82
    electron-userland#114
    electron-userland#103
    electron-userland#120

The best way forward would be to introduce a separate `program.applicationId` config,
which is used in preference to the `packageName`.
@jameshfisher
Copy link

Should be fixed in #131; in the mean time the correct (but confusing) way to use this package is like so:

const convertToWindowsStore = require('electron-windows-store');
convertToWindowsStore({
    identityName: '12345MyCompany.Ghost',  // This is actually the package name!
    packageName: 'Ghost',  // This is actually the application id!!
    // ...
});

@jameshfisher
Copy link

I've since come to the conclusion that the right way to use electron-windows-store is to write your own AppxManifest.xml, and pass this in, like so

const convertToWindowsStore = require('electron-windows-store');
convertToWindowsStore({
    manifest: '.\\AppXManifest.xml',  // For many reasons, we write should own
    packageName: 'Ghost',  // Still needed for filename 'Ghost.appx'
    // ...
});

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants