I have a game. At first, it was published as a beta version in the Play Store. Then we uploaded the release version, so the beta version was deactivated automatically. However, in the store, I see that the app has a "Beta" label in its name. What should I do to make the "Beta" label disappear from the game's name?
Since you are a beta developer, the application will have the "(Beta)" suffix after the name.
However, if you check the application's page while being logged out, you will see that the suffix is not visible for the public.
Related
I uploaded my app to play store recently as .aab bundle with version code 3.6، after full rollout my app is succssfully published on play store, now my problem is that after publishing I discovered that the app is not working correctly with some locals eg "Arabic, Hebrew" so I created another aab file to fix the problem but unfortunately I forget to change the version number, to make the issue worse my workstation got corrupted hard drive and it's refusing to boot and my upload signing keys are not part of source control so I can't create new aab with 3.7 as version.
usually when the app is not published I can delete the release and then delete the appbundle from bundle explorer and reupload with same version.
Can I as desperate resort delete the app completely and reupload the same aab after creating new app?
Can I talk to google play store support and ask them to remove the release?
I tried to revert to a previous release 3.5 so that I can delete
the currently active one but with no luck
google play says I cannot revert to 3.5 because it doesn't allow users to upgrade!
Update: I just contacted google play support and asked them to change my upload signing keys, I had to wait for 48 hours until the keys became active.
I have a traditional Win32 desktop app written in C++/MFC that I have packaged as a UWP app for the Microsoft store using the desktop-bridge facility in Visual Studio 2019. It is currently published on the store, and users have been downloading it successfully.
I now need to release an update. I have incremented the Version numbers in the Packaging tab of the Package.appxmanifest and have a package just-about ready to submit to the Store. I hope (expect?) that current users will get their existing copy of the app automatically updated if they have set that choice in the Store app itself, or if they manually check the Store for updates. However, I am not sure whether that is actually true. Do I need to do anything within my program itself to make that happen?
Thanks for any help.
Yes, desktop bridge apps published in the Store update automatically.
I am developing a chatbot azure service, which I want to integrate within Microsoft Teams. So far everything is working but the "re-install" of the package in the Microsoft Teams.
I created a publish "folder-profile". Then I zip the result with the manifest.json and the icon files inside. I go to the Manage Team section and in the Apps tab I select upload a custom app. Then I choose the .zip file and the service seems to be there(Actually it is there)
It works, but when I create a new version and I repeat the described steps, it seems like Microsoft Teams is still using my old code.
I test the chatbot in the Chat by using #"APP-ID" and I see how my changes work, but installed as an App for the "Team" keeps the old version.
I tried to uninstall it, check if the bot is gone(it is gone) and then upload again, but some kind of cache is there and the bot behaves like in the previous version.
Any idea how is the correct way to deploy new versions of my app in Microsoft Teams?
I think you need to upgrade the version number in the manifest.json file (you can do it in the manifest.source.json before to generate your zip).
I have a small solution that is composed out of 2 main projects a Mvc4 Web Api and a silverlight 5 Application. I've configured and deploy the application initially on the Azure platform and it all went great, but ever since when I deploy again the silverlight project does not get pushed and the online site has the old version.
I should mention all works great with the azure simulator on my local dev machine.
Anybody had a similar issue?
Regards,
I would suspect first (as Simon suggests) that the browser likely still has the previous client cached and loads that instead of downloading your new client.
You can use the version number in the code on your page that hosts the silverlight app to help. While it's easy for you to clear the cache - you don't really want to have to tell users to do that whenever you update.
Set the version to whatever your latest assembly version is (silverlight client project assembly), this will force the browser to download the client if the cached version is a lower number.
<param name="source" value="AppPath/App.xap?version=2.0.0.6"/>
Ok,
So after pulling my hair out, I finally figured out.
I have to change the build configuration to release in VS do a rebuild and then do publish because apparently the azure project does not do rebuild on the project when you publish it.
To solve this issue you'll need to identify the source of the problem (is it a client side problem where you have a caching issue or not). Even though you say caching isn't the problem we'll need to be sure about this first.
What I suggest is that you do the following first:
Activate Remote Desktop on your role
Connect through RDP and save this file to the role: http://support.microsoft.com/kb/841290 (fciv.exe)
Find the *.xap file (usually in E:\sitesroot) and get its checksum (using fciv.exe)
Modify the Silverlight project locally (maybe change a label or move around an element) to make sure its hash has changed.
Redeploy the application
Connect through RDP and use fciv.exe to get the checksum of the *.xap file once again
Compare both checksums
If the checksums are different, then it means that the deployment worked correctly and the Silverlight xap has been updated. If the checksum is the same, the problem lies with the deployment.
Please let us know the result so we can help you find the solution.
The following issue just crept up on me. The steps mentioned below had worked just fine until about 2 days ago.
When I deploy a update to a solution (of web parts) to a SharePoint 2010 server I don't see the update. The solution does get installed, but from what I can tell the installed web parts are over a month old (nothing new is installed).
I do the following steps through PowerShell:
retract the solution from the web app
remove the solution
add the solution
install the solution to the web app
I have tried restarting the Web App, restarting IIS and also restarting the server. Nothing seems to work.
I notice that after I remove the solution it does get removed from the GAC. After I add/install it the solution does reappears in the GAC.
Am I missing something? Am I overlooking a step that I should be doing? Something to try?
I never deactivated/reactivated the Feature.
After following the same steps I mentioned in my question I just deactivated, then reactivated, the Feature and everything started to working fine.
This is an easy thing to I can start to implement with my solution updates. However, why did I never have to do this step before?
In general, you should check your ULS log to see which version of your solution is running. If you see the old one, then you can be sure that your activated site feature is still bound to the old version. In this case you have to Inactivate the site feature indeed to loose that tie and then Activate to bind to the new one (it appears Activate always ties the site feature to the newest version of the solution).
Maybe you had not to do this earlier, because you did not change the version number of your solution, appearing as the same version in GAC on the server. In this case you had your site feature already pointing to the correct version of your solution, therefore didn't have to reset the feature.
You have probably checked, but just in case. Make sure that the powershell script is not adding a month old package.
Is the problem in the web part code or the configuration? The configuration usually unghosts itself sooner or later and refuses to update from the solution - you can update the file in the gallery manually if anything has changed there. For most updates there won't be any changes because existing web parts won't get updates applied anyway - they will use new code but old configuration.
If the problem is the code itself, does the assembly appear to the system to be unchanged? All the hardcoded full name references in SharePoint config files mean that usually you are deploying a new assembly but with the same version numbers. This can mean that the system doesn't bother making the update. I have found it very useful to update AssemblyFileVersion (which does not affect binding) on every build and have a page in _layouts that displays the file versions of all the loaded assemblies so I know exactly what is running.