Let us suppose that I have created two MSIX packages and that they are independent of one another. However, I want to make them into a "related set"; I want one of them to be my "main package" and the other to be an "optional package" that installs alongside the main package. I have used MakeAppx.exe to unpack both MSIX packages on my machine, and I'm looking at the two packages in the filesystem, in particular at the AppxManifest.xml files.
I know that for the optional package, the MainPackageDependency element (from XML namespace http://schemas.microsoft.com/appx/manifest/uap/windows10/3) may be added to the `Dependencies" element in AppxManifest.xml. However, I believe that in order for the two packages to form a "related set", I also need to add something to the AppxManifest.xml of the main package. I do not know what it is that I need to add there.
The focus of this question is what changes I need to make to the main package. Once those changes have been made, it would remain to re-pack the MSIXes and sign them. You may take it for granted that I know how to accomplish those steps.
The MSIXes are intended to be side-loaded (not distributed via the Microsoft Store) and they both contain executables.
What I have tried
I have tried modifying only the package that is meant to be the "optional package" in the related set. The result of this is that when I try to install both packages, the main package installs successfully but on attempting to install the optional package, the following error message displays:
A related set cannot be updated because the updated set is invalid. All packages in the related set must be updated at the same time. (0x80003d17)
The following error appears in the Windows error logs:
The optional package with centennial content OptionalPackageName_21.4.0.0_x86__0rk1t7bybtkaw is not in a related set and it is required to be in a related set specified by the centennial main package MainPackageName_0rk1t7bybtkaw.
I do not know what the terms "centennial content" or "centennial main package" mean and have had no success searching for them online.
I have tried adding a PackageDependency element to the Dependencies element in the AppxManifest.xml file of the main package, with the Optional attribute (from XML namespace http://schemas.microsoft.com/appx/manifest/uap/windows10/6) set to "true". This yielded the same results as described above. It is my understanding that this is not the correct approach because the PackageDependency element is used to declare so-called "Framework dependencies", which are a different kind of dependency.
I found a Microsoft documentation page that suggested that a file named "AppxBundleManifest.xml" might be the vehicle for information about optional packages. I therefore tried adding a file named "AppxBundleManifest.xml" to the main package, with content modelled on that of a file of the same name that Visual Studio created for me when I was trying to work with a sample project I downloaded from GitHub. However, this file is not packed by MakeAppx.exe when it runs; it prints the following message:
MakeAppx : warning: Ignoring footprint file "AppxMetadata\AppxBundleManifest.xml".
I do not know what the term "footprint file" means, nor why the file is being ignored.
I have tried browsing Microsoft's documentation of the AppxManifest.xml file schema, but I did not notice anything helpful there.
I have tried installing a trial version of the paid-for software product "Advanced Installer", because it boasts support for this feature and I thought I might be able to crib from the MSIXes it produces. However, while I can create my optional package using this software product, I cannot figure out how to create the main package. The vendor has documentation online, but as far as I can tell they have changed the relevant parts of their application's GUI since writing that documentation, and I cannot figure out where the relevant options are in the version I downloaded. Specifically, this page appears to suggest that the "Builds" widget (listed under the "Package Definition" category) ought to contain an "Optional packages" tab; in fact, there is no "Optional packages" tab there.
I have tried working with a sample project that Microsoft made available on GitHub. However, while I managed to get it to "build", I have not succeeded in getting it to create actual MSIX files. It does create AppxManifest.xml files, but there is nothing in those files that is obviously the missing element from the file in my own project.
Why am I not using Visual Studio to create the packages?
We want to use WiX to create the MSIXes. Unfortunately, the WiX Expansion Pack does not yet support optional packages or related sets. I was hoping that there would be some tweak that we could apply to the MSIXes produced by WiX (e.g. editing the XML in the AppxManifest.xml files) that would give us what we want.
What was going wrong here was that I believed erroneously that related sets could be created in the form of individual packages, compiled using MakeAppx. What you actually have to do is to use MakeAppx in two steps:
Use MakeAppx to create packages.
Use MakeAppx again to create a bundle from the packages you already created. (Use a "mapping file" that specifies one or more optional packages under the heading [ExternalPackages])
This can be gleaned from the Microsoft documentation if you read between the lines, but it's not explicitly explained anywhere that I saw.
It's easy to gloss over the need to create bundles if you've already read about other MSIX-related topics before coming to this one, because bundles are motivated in documentation elsewhere as a means of combining together into a single unit multiple versions of your package that target different architectures. If that isn't a concern for you then you may believe you can disregard them. Well, they can be used for that purpose - but they can (indeed must) also be used if you want to create related sets. You can have a bundle that has only one essential package, and for only a single architecture.
One more gotcha: To create an msixbundle requires a minimum Windows SDK version (10.0.18362.0 I think).
Related
I am not sure I have the terms quite right here, so give me some rope.
I have a class library project which when built with release config, generates a nuget package on build via the setting under project properties.
When I look at the package using nuget package explorer, the contents looks like this:
This makes sense, it matches the build folders output.
However what I am trying to achieve is changing that output to be lib\net462\plugins\dll.
Any ideas on the easiest way to achieve this? I cannot see any options for configuring the contents output on the package.
I have another auto generate method that can help you achieve the requirements you want.
Since you are based on release, right click your project and then click 'Properties', go to 'Build Events', then using command like below in the 'Post-build event command line':
cd ..
cd ..
dir
nuget pack -OutputDirectory lib\net462\plugins\dll -Properties Configuration=Release
The above is just an example/idea, it is using default package configurations, your situation may be a little different.
For detailed information about the nuget pack, please refer to this official document:
pack command (NuGet CLI)
As you can see, I can generate the package to the path I want:
The above method is useful for many different types of projects.
By the way, the UI between you and me is different, on my side, there is no 'Package' section in the project properties(netframework class library):
So please share your VS version and if possible, please also share a screenshot of the project type you selected.
For someone coming from the manual SSIS package creation and modification paradigm using Visual Studio and TFVC, I'm struggling to 'grok' the BimlStudio and source control workflow.
I've got a BimlStudio project that emits SSIS projects (dtproj files) and associated packages, connections, etc. I want to put it all under source control (.biml and .dtsx files) using BimlStudio and TFVC.
How can I more precisely manage my source code changes than what I seem to be able to do currently.
Let's say I have a single package I need to change. The package (like all of my packages) is defined via external metadata (metadata that is not part of my BIML project). The only place I make a change is in that metadata.
After making the external meta-data change, I build my BIML project.
Since the entire project is re-built, it emits an updated package with the change from the external metadata included, and emits updated instances of packages where no change occurred.
I open up my updated project in Visual Studio.
Using a file "diff" tool, I compare any of the packages with their prior build version. Each "diff" shows that every package has all new GUIDs for all of it's various components.
Since all of the packages' internal GUIDs change with each BIML build, I get this insane amount of "noise" surrounding my one change. Yes, I could assign static package GUIDs via the package metadata, but I'm not going to do that for every sub-component in my package. Or am I? (Please say no)
One could argue that since I know what changed, I only check in the one package. But life happens. I leave my work on Friday, come back on Monday and be like, "What change did I make?" Or I hand over my work to another developer and they need to know what changed, etc.
How do I best work through this?
Additionally, are SSIS artifacts (and all other files in my BimlStudio project's output folder) even included under BimlStudio's source control or just the .biml, .bimlproj, .bspcap and .mst files?
If SSIS artifacts are not included in BimlStudio's version control, then they would be free to be added to TFVC via Visual Studio, correct?
This is the approach we've used:
Do not check in SSIS packages. In a BIML solution the SSIS packages could be considered build files. Use an ignore file to exclude them. Because they are dynamically created they will always change on re-create as you say.
(Assign static GUIDs to connections)
I've created an MS Word add-in using my Mac, and want to begin the process of submitting it for validation to AppSource. However, the process requires a package to be uploaded, and I haven't been able to find any documentation whatsoever on how to compile my project into the sort of package expected.
The page where you upload your package lists the following file types as being acceptable: .msix, .msixbundle, .msixupload, .appx, .appxbundle, .appxupload, .xap. I've downloaded Visual Studio for Mac, as there's some documents which describe using VS to compile a project to these sorts of packages, but see no way to import my existing project folder – nor any way to start a new Word Add-in project (or anything that sounds similar.)
My project is a React-based add-in created using the Yeoman office project generator (https://github.com/OfficeDev/generator-office), consisting of your standard React project structure (package.json, webpack config files, src/components) as well as my manifest.xml file.
Edit:
To be clear, there is indeed a place within the Submission process which says:
Drag your packages here (.msix, .msixbundle, .msixupload, .appx, .appxbundle, .appxupload, .xap) or browse your files.
However, when I attempt to upload my manifest.xml file using this interface, I receive the following errors:
- You must provide a package that supports each selected device family (or uncheck the box for unsupported device families). Note that targeting the Xbox device family requires a neutral or x64 package.
- You must upload at least one package. If you are using market groups, then each market group must have at least one package.
- You must fix all package validation errors before submitting.
- Package acceptance validation error: manifest.xml is an unknown package type. Please name your file with the appropriate file extension.
I've used manifest validation tools on my current manifest, and they tell me it's structurally valid as well as possesses all required fields. This, as well as the list of accepted filetypes mentioned in my comment below, is what leads me to believe that I'm expected to upload a specific compiled package type.
In order to submit a Word add-in for publication to AppSource you need to submit your add-in via the Seller Dashboard. You will need to submit a .xml manifest file.
For more information on how to submit your add-in to SellerDashboard please see here.
I have a wix booststrapper project, which cannot be localized like the normal WiX project.
If I extract the hard code string from the booststrapper.wxs file, then the compiler output errors:
Light.exe : error LGHT0100: The localization identifier xxx has been duplicated in multiple locations. Please resolve the conflict
Has anyone some experience in boostrapper internationalization?
Would you give some suggestions?
This issue is discussed here:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Votive-Light-LGHT100-error-when-more-than-one-localized-wxl-td7587802.html
In short, if you include two or more .wxl files you will see this error. The trick is to mark the extra localized wxl files as Build Action = None in the Properties window for the actual wxl files in the solution project tree.
If you are using a main one (or a copy) like RtfTheme.wxl, that one can remain as type Embedded Resource. This is the default type Visual Studio seems to assign wxl files added to the project but only one can ever be marked as such. So long as you have Payload elements that bring in the rest they do not need to be marked as Embedded Resource and, as experienced, it will fail the build if they are.
Additionally, the following post describes a very nice way to organize all these localization files: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/My-experiences-making-a-multi-language-bundle-td7208949.html
That the logical follow-up for the my previous question: "How to check all projects in solution for some criteria?"
I was given quite a good answer to use CustomAfterMicrosoftCommonTargets, CustomBeforeMicrosoftCommonTargets. They do work, so I decided not to stop in the middle.
Issue is that I don't want machine-wide tasks. It's not a good idea neither for me (it will affect other builds. sure, this can be handled, but still), nor for my teammates (I don't want to let them put something in system folders... ), nor for build server.
What is needed: solution to be built from scratch out of source control on clean machine with either Visual Studio or MSBuild.
It appeared that Custom*MicrosoftCommonTargets are regular properties.
So, how to specify this property? It works pretty fine when to set it from command line.
That's strange, but it appears that bit of magic present here: property passed as command line parameter to one build is transitively passed to all nested builds!
That's fine for build server. But this won't work with Visual Studio build. And even declaring solution-level property won't help: neither static, nor dynamic properties are transfer to nested builds.
...I have a hacky idea to set environment variable on before solution build and erase it on after. But I don't like it. Any better ideas?
I use a bit different technique then #Spider M9. I want that all projects in solution tree/all subdirectories from current directory use extended build throw Custom*MicrosoftCommonTargets. I don't like to be forced to change every new project to import custom targets/props.
I place special file, let's say msbuild.include, in the root directory and my custom targets loader for every project tries to find it in ., ..\, ..\..\, and so on. msbuild.include contains flags that triggers execution of custom actions. If loader can't find this file it disables loading all custom targets and stoppes. This gives me ability to use my build extensions with projects from work repositories and to not use with opensource projects.
If you are interested in I can publish loader. It's a pretty simple and elegant solution.
For example I can sign any assembly in all projects in all subfolders with my key.
I always set up every project to import a standard .props file. Use the GetDirectoryNameOfFileAbove property function (see MSDN) to find it. Do this as the first line of every project file. Once established, you can redirect from that file to other imports. Another trick is to have that standard import (that would obviously be under version control) import conditionally another .props file only if it exists. This optional file would not be in version control, but is available for any developer to create and modify with their own private/temporary properties or other behavior.