I upload app to MS Partner Center with version 1.0.0.0. If I need to change package, but save the same version number, I delete corresponding test flight and submission, but when I upload app again I get this:
'Appx packages (including previously published and currently uploaded)
must be uniquely identified by their full names. You have provided two
packages with the full name
some.default.name.1.0.0.0_Neutral_~ which have
different contents. Please remove one of these packages, or increment
current package versions to continue
So I am wondering is there any other place, maybe somwhere in Azure AD where the packages are stored?
Related
An action was taken last month to delete deployments from an Application that was made available as required install earlier last month. There are no longer any deployments associated with the package but some users have reported that they just got the application installed on their computer from the same package.
Not sure why would that be as there are no associated deployments with the package anymore. The original application package was pushed out to user collection.
Any help identifying potential causes would be greatly appreciated.
You can try installing the Configuration Manager Support Center on a model device, then search the Content tab for the application.
If it does appear there, it might indicate a problem with policy update. Check the PolicyAgent.log and PolicyAgentProvider.log for possible errors.
It may also be because of dependency / supersedence, check the references tab in the application's Properties.
If it does not appear you can check the AppEnforce.log to verify that the application installation was performed by the SCCM Agent, and at what time.
Microsoft announced and open-sourced winget, a package manager for Windows.
When entering winget source (after installing it), it can be seen that it supports adding sources.
winget source provides the following subcommands:
add Add a new source
list list current sources
update updates current sources
remove removes current sources
reset resets sources
By entering winget source list, the default source is displayed (as long as the sources were not changed):
C:\Windows\System32>winget source list
Name Arg
-----------------------------------------
winget https://winget.azureedge.net/cache
As sources can be added using winget source add, how can source repositories be created?
How does a repository has to be structured or is there just not enough documentation to answer this question?
I think this question is on-topic for Stack Overflow as the main reason to add sources is (in my point of view) to create alpha/beta channels for programs or similar.
winget 1.0 introduced a new REST API for custom repositories. The API and a reference implementation are provided by Microsoft at github.com/microsoft/winget-cli-restsource/. The reference implementation uses C# and allows self-hosting on Azure. Hosted offerings are also becoming available, such as https://winget.pro.
Before winget 1.0, the structure of winget repositories looked roughly as follows:
The remote repository should have a source.msix file. You may refer to the example at the default repository: https://winget.azureedge.net/cache/source.msix
One can find details about MSIX itself on the Microsoft Docs website.
Actually the source.msix is a zip package with contents structured in a pre-defined fashion (just rename it to source.zip and unpack):
Assets/
Public/
AppxBlockMap.xml
AppxManifest.xml
AppcSignature.p7x
[Content_Typex.xml]
The main data file seems to be Public/index.db. It is an SQLite database containing information derived from Community Repo Manifests. It has a quite simple structure to understand.
Another concern is the MSIX should be signed by the developer. One should change Windows settings in order winget to accept packages signed by third parties. See below for details.
Note that winget doesn't accept an HTTP repository, it requires only the HTTPS one with a trusted certificate.
The most interesting tables in index.db are manifest and pathparts. The first matches application's name, version, etc. to pathparts, and the latter points to the manifest YAML-file.
For example: https://winget.azureedge.net/cache/manifests/RubyInstallerTeam/Ruby/e70d-2.7.2.yaml (a cache of github/winget-pkgs/manifests/RubyInstallerTeam/Ruby/2.7.2.yaml).
winget uses this cached manifest for application installation.
In order winget could add the third-party source repository (when the source.msix signed by third-party certificate) one should allow installing sideload apps.
Summarizing the above the overall sequence seems to be the following:
Download the source.msix from the winget's default repo: https://winget.azureedge.net/cache/source.msix
Unpack it as a ZIP-package or using the MSIX Packaging Tool to get the index.db file from Public directory.
Edit this SQLite DB (I've used the DB Browser for SQLite for that) leaving only your application (tables ids, monikers, names, versions).
Set the path to YAML-manifest in pathparts table (one record per each path element). E.g. for /manifests/MyCompany/MyProduct/1.0.0.yaml the table should be like:
Edit the manifest table by adding the record that unites all related records.
Save the edited index.db, overwrite it in source.msix using the MSIX Packaging Tool, sign the MSIX with your own code-signing certificate.
Upload both the manifest (see Manifest Specification for details about manifest itself) and source.msix to your server (e.g. to myserver.net/repo/source.msix and myserver.net/repo/manifests/MyCompany/MyProduct/1.0.0.yaml).
Use:
winget source add myrepo https://myserver.net/repo
winget install MyProduct
You can deploy a private REST source to Azure using the reference implementation.
It is also possible to create your own implementation referencing the Swagger API.
WinGet 1.0 has just been released, and Microsoft has also released a reference implementation of the REST API source so it’s possible to host your own private repository.
It's called WinGet.RestSource and can be cloned from here; because it’s an Azure solution, next to Visual Studio 2019 you also need an Azure subscription.
I found that getting WinGet.RestSource up and running and pushing packages to it (currently) isn't that easy, but for anyone who's interested, I've written 2 blog posts about this:
Hosting your own WinGet private repository
Adding a package to your private WinGet.RestSource feed using its API
As of July 2020, as clarified by How to Update Winget Source List:
Winget is a really young application in terms of software age and currently, only has a single source/repo available for it, Microsoft's official Winget repository.
Thus sub-commands such as add and remove aren't of use yet.
So it seems as a pretty easy Task, I created a VSIX which I uploaded a few days ago. Some days later I fixed some issues and now I want to update the extension on the marketplace.
I went ahead and took a look at the MSDN which states the following:
Unsigned all user extensions do not get updated automatically. You should always sign your extensions.
So therefor I went on an tried to sign my VSIX as explained here. Which tells me to do the following:
Search for VSIXSignTool from VisualStudioExtensibility and install the NuGet package.
After downloading the package, I searched for the given location which should be in your project's local packages location. Which makes me wonder, cause I do not have any local packages folder for this project. Furthermore I should sign my extension with the following command:
VSIXSignTool.exe sign /f <certfile> /p <password> <VSIXfile>
Which makes me wonder, what kind of certificate that should be, what should be the password be, a new password?
Anyway, lets assume I somehow mange to do that, how would I 'update' the extension than? Just upload it again as a new package with a new VSIX-Id?
To sum it up, this are my questions:
How/Where do I download the VSIXSignTool
What parameters do I need to pass into the VSIXSignTool command provided above
How do you really update the extension on the marketplace and do I need a new VSIX Id
I suggest first try to update your extension without signing. Just increase the version number and on the marketplace site click Manage - ... (More Actions) - Edit - Upload Extension/Edit package.
VSIXSignTool requires a code signing certificate that needs to be purchased.
i want to change the package name for Android project dynamically related to selected configuration in Visual Studio.
For example, if i want to have same app twice in Google Play Store, one with postfix full and one with postfix free. So i want to have one configuration for release full and one for release free, without changing the package name manually each time i select a configuration.
A more complex scenario could include also changing app icon and app name.
Is there a smart way to do this? Maybe a Nuget plugin?
Best regards,
Moritz.
I need some help regarding Install4J and the auto online update function.
We have a JRE bundled Install4J installer which works fine. We use the auto online update functionality which works fine, too. All this functionality in integrated to a continuous integration process in TeamCity.
Unfortunately the update installation setup file has a size of around 100MB which is inconvenient to download if we only want to apply a patch or a minor update.
As far as I have understood from other similar questions and the Install4J documentation the right way to deal with that is using a second project file with another application ID and setting up an Add-On-Installer which only contains relevant files and points to the full installer application ID.
To enable the auto online update functionality I have to upload the update.xml file from the Add-On installer, am I right?
By the way, does the Add-on online auto update procedure automatically detect the locally installed version correctly?
But in that case we have to adapt the add-on installer each and every time we are deploying a new patch or minor feature which is difficult to implement in the CI process.
Is there a way to configure an Install4J installer so that it automatically gets the information online which elements have to be updated so that the download size is as small as possible and we could just use one default add-on installer which contains all sources beside the JRE bundle?
Something like an online incremental update procedure which is managed internally by Install4J?
Thank you.
You should never use the add-on installer for updating, because it cannot change the version number.
In order to get smaller update installers, you create a second project where the distribution tree only contains the changed files - or at least does not contain some large files that did not change. To do that, you simply copy the original installer and delete the files in the distribution tree that you do not need to update.
Then you build two sets of installers, those for a new installation and those for the update.