MSIX Support: Generate AppxManifest.xml (part 1)#187
MSIX Support: Generate AppxManifest.xml (part 1)#187JoshBashed wants to merge 6 commits intomoreSwift:mainfrom
AppxManifest.xml (part 1)#187Conversation
AppxManifest.xml (part 1)
f1edc27 to
ee92679
Compare
|
@stackotter the commit is ready. if u have free time pls review |
a9535e9 to
7cb1fa6
Compare
7cb1fa6 to
343139c
Compare
| return icoFile | ||
| } | ||
|
|
||
| static func prepareMSIXIcon( |
There was a problem hiding this comment.
The GenericWindowsBundler should only perform operations that all Windows bundlers require. These MSIX operations should happen in the MSIX bundler. Given that this PR doesn't fully tackle MSIX bundling, maybe just make a basic MSIXBundler that wraps GenericWindowsBundler and houses these MSIX-specific operations. It's ok if the MSIXBundler doesn't actually produce an MSIX yet, because I can merge this PR into an MSIX feature branch and then merge that branch into main once your series of PRs has landed to finish off the feature.
| static func prepareMSIXIcon( | ||
| iconPath: String?, | ||
| context: BundlerContext, | ||
| skipIfPresent: Bool = false, |
There was a problem hiding this comment.
Why is this skipIfPresent parameter necessary? We should generally recreate the icon every time in case it has changed (because we don't track enough information to be able to tell which build operations can be skipped yet)
| } | ||
| } else { | ||
| image = Image<RGBA>.init( | ||
| width: 300, height: 300, pixels: Array(repeating: .init(0, 0, 0, 0), count: 300 * 300) |
There was a problem hiding this comment.
When wrapping arguments, put each one on a separate line (just as a code style thing that I generally try to follow in this repository)
| return try Image<RGBA>.load(from: Array(imageData)) | ||
| } | ||
| } else { | ||
| image = Image<RGBA>.init( |
There was a problem hiding this comment.
Don't need the explicit .init
|
|
||
| case fullTrustProcess = "desktop:FullTrustProcess" | ||
|
|
||
| var category: String? { |
There was a problem hiding this comment.
This category property should be computed on AppxDesktopExtension itself, because I believe this is essentially just computing the enum tag? It seems weird having to skip all the auxiliary fields when computing the enum tag; took me a sec to figure out what was going on.
There was a problem hiding this comment.
Same for the other instance of this pattern below
There was a problem hiding this comment.
It made the most sense to do it here because the coding key defines what item should be encoded. Let me know how you would like me to continue with this. Should it be a function? func getCategory(forCodingKey key: CodingKey)?
This pull request introduces initial support for MSIX packaging on Windows, by generating
AppxManifest.xml.Summary
MSIXBundlerConfiguration).windowsPath(relativeTo: Path)for creating relative windows paths.windowsNametoBuildArchitecture. This could be renamed tomsixNamebecause windows uses different names for these architectures depending on where it is uses.AppxManifestCreatorto createAppxManifests.xmlfrom bundler contexts and additional metadata.GenericWindowsBundlerto prepare icons for msix and to createAppxManifest.xml.GenericWindowsBundlerBundleStructure.swiftto supportAssetsdirectory. This is where the icon goes.Progress
AppxManifests.xmlwhenmsixfield is present.icon.