i'm looking for a way to manage application upgrades for my compact framework app.
let's say i have v1 of the app installed on my device, and v1.1 has been released. I want the app to make a call to my server to see if there is a new version. since a new version is found, i want to send down the new version of the app to the device and have it installed, replacing the old version.
my first thought was just to have the app download the .cab file and kick off the cab file just before exiting the app. this would mostly get the job done but it would prompt the user to pick the installation location if they have a storage card or other partitions on their device. i would like to prevent any user input and just have the new version of the app installed, replacing the old app.
i'm certain that there are others doing this already and i don't want to reinvent the wheel, here. what application management tools and systems exist for this type of process? how can I facilitate this type of process?
...
EDIT:
in spite of my previous searches before posting this, i just now found this question: How to Auto-Update Windows Mobile application
When I wrote one I relied on launching the .cab file. It was definitely the path of least resistance.
Otherwise, I'd write a simple "upgrade.exe" executable that gets distributed with your app. When upgrading, you'd download the new package, launch your upgrade.exe just before exiting your app, then have that program copy over the new files to your app.
Related
I need suggestions on how to update my application. The form application is going to be put on a drive for many users to be using non stop all day. What are ways to update the program or allow updates to the program while it being use? If I update the program and recreate a new build for it, trying to copy paste over the old application will not let me if someone else has it open. Open to any suggestions.
Option 1: Deploy the app with ClickOnce and set it to check for updates every time it runs.
ClickOnce:
In your project settings, click on the Publish tab.
From here you can configure where the app publishes to and if it should be installed or available online only.
Once you have it all configured you will use the Publish Now button to compile and upload your update to the publish location. Each time your users open the app it will check for updates at your set location. To have your app check for updates programmatically use code like the one found at this MSDN link - https://msdn.microsoft.com/en-us/library/ms404263.aspx
You should note that users will no longer run an exe directly and you won't copy your exe to the publish folder. Your users will have to click on a file that has the extension of .application. The users could create a shortcut to this .application file to place on their desktop or wherever they want.
Also note that if using ClickOnce and you publish a bad version (with a bug for instance) then your users have the ability to revert back to the previous version so that they can continue using the app while you fix the bug. Your users also have the option to skip an update so you'll want to inform them to never skip the updates.
Option 2: Create an app that publishes your main app
I'll admit that this answer is not a great way
You could create another exe for the purpose of publishing the main exe. The publishing exe will simply try to copy the new exe over the old one and keep trying until it is successful. It will be successful when all instances of the program are terminated.
Option 3: Use a database
Have your app check a database value that indicates an update is available. Prompt users using the app to shutdown and don't allow other instances to startup while the database value is set to update available.
You could use nUpdate, a free and open-source .NET-library for updating applications that also cares about the safety of your update packages which is an important fact. Many update routines do not validate the packages they downloaded, which can result in serious damage, if updates are replaced by malware (as it happened to the puush-service some time ago).
nUpdate is especially designed for Windows Forms-applications.
It is still being improved at the moment and the support for WPF-applications will be added soon, but the current version is very stable, yet.
I have version 1 of my Windows Phone App (w8.0) in the store which has been running for a while now. The app uses a SQL Server compact database for local persistence on the device.
I'm now ready to release v2 of my app (w8.1), which has a number of database schema changes. The question is how I can formally setup a test environment for the test team where testers can:
1...Install v1 of the app from the store
2...Run it up and do some light activity
3...Then upgrade the app on the phone to v2
4...Continue testing using an upgraded version of the database
Up to now all v2 testing has been done using a shiney new install of the app.
I know i can do this using Visual Studio, but this defeats the objective of the test i.e. a live user upgrading via the store.
I've tried using the app deployment tool, but this deletes v1 of the app (including the database) when it deploys v2. I was surprised it did this - I thought it would recognise the install as an upgrade. I can verify this because it deletes the database. I am using the same names/keys in the manifest, including an incremented version number.
For now I have a new (hidden) TEST app in the store where i've submitted v1 of the app. Once the testers are ready, I submit v2 of the app to the store which the testers then upgrade. Problem here is that it takes upwards of 12 hours for the store to publish the upgraded version.
I am aware that you can install an app from the SD cards, which is pretty close. Has anyone else found a good elegant way to do this?
You could use Windows Phone Power Tools to achieve this.
Here's the link: https://wptools.codeplex.com
Just install the old xap, do some stuff and then update to the new xap using the "UPDATE" button. If you don't change the app ID, it will surely work.
Hope this helps! :)
I prepared a simple quiz app for Windows 8 store. My app successfully passes on WACK just after building and creating local packages without login to store account, however it fails (perf test: launch was not detected) when I login to my store account, associate the app with a reserved app name and create packages to submit.
So, I submitted my app three times and it always failed requirement 3.8 since those packages fail. What should I do? Is there anything I miss? I'm dealing with this issue for many days but I can't find the right solution.
Regards,
Hakan
I downloaded and installed Visual Studio 2012 Update 1. WACK tool I use is the latest one. My Windows 8 account and Windows 8 Store account are same. However; I still have the problem.
That's what I'm doing;
I recreated my app project. Successfully builded the app and created (not store associated) app packages without login to store account on Visual Studio. After creating those packages, I started WACK on Visual Studio and app passed successfully. Then; I cleaned the solution and created the packages to upload store (I logged in to my store account on visual studio and chose the app name I reserved). After creating packages I started WACK again, but this time app failed with; "Launch was not detected" error.
I don't think there is anything else to do. I get bored after each unsuccessful submitting. What should I do? Does anyone have any idea?
Requirement 3.8 is very specific, and has nothing to do with your app's name. From the App Store Requirements:
3.8 Your app must meet the basic performance criteria on a low-power computer
The app must launch in 5 seconds or less
The app must suspend in 2 seconds or less
Did you test your app on an ARM based device? How much time does your app take to start up/ suspend?
Update:
If you are using the standalone WACK, it is possible that you are trying to certify the old version of your application. As I recall, when you associate your app with the App Store, your app's name AND package ID change. However, bits of the old app may still be around, which can cause the certification to be run on an app that no longer exists.
Something that may help is to first uninstall your app prior to creating the package. The other thing to try is to run the certification from within Visual Studio. I have found it to be more reliable than the standalone app.
We have a native, stand alone Win32 application that we use to generate .PDF files. It is command line driven to take one of our data files in and generate a PDF file. It works in conjunction with a print driver that is installed on the computer.
I know there are libraries for generating PDF files in .NET that we can use in Azure, however, there is specific type layout being carried out in our App that we must support, and that logic is not yet on the server side. This is a short term cheat, before we port (or rewrite) our 20 year old type layout engine out of C/C++. There is alot of code here with alot of complexity.
I see that we can now run native apps in Azure (yay). However, my issue seems to be that this native application requires a print driver installed. I have not been able to find any information about installing print driver in Azure worker role.
I found this discussion: https://stackoverflow.com/questions/9125385/printing-to-pdf-from-azure-worker-role. The end result of this is to use a PDF library on Azure, which is not something that will work for us.
Also, I am aware that it is not the best use of a server to fire up a process to generate a PDF file everytime somebody wants to preview their data file in our web site. We are planning on cheating by showing the user the PDF, when they want to preview our proprietary data format in a browser. This is Phase I of a project, and rewriting our 20 year old type layout engine in C# is going to take alot longer to accomplish, and we are talking about this (admitted hack) as a short term (in the bigger sense of things) measure.
How do I install a Print Driver in Windows Azure worker role? Is it possible? Are there any other options?
Many Thanks.
If you can do a command line, silent install of the Amyuni software that yms mentioned then you could run that as part of a startup task on your worker role, probably with elevated permissions. People use startup tasks to do all sorts of things and many of them have written blog posts about it or answer questions about them here on SO, but a good place to start would be the official documentation.
This may help: Amyuni PDF Converter is a PDF printer driver with an API exposed as a COM interface and as a net. assembly that allows you to silently install and uninstall the driver programmatically. This can be done by using the methods PDFDriverInit and DriverEnd from your application.
Once your application installs the driver, you can print to PDF using a memory stream as destination and upload it to a Microsoft Azure Blob Storage.
There are 2 ways of installing Amyuni PDF Converter:
1- Using the installation program provided with the package.
2- Copying the dll files to their corresponding folders and then calling the method DriverInit.
The complete process is explained here:
Using the Developer Version of the Amyuni Document Converter
About your specific scenario, if you have an application that uses Amyuni PDF Converter, then there is indeed a printer driver that should be installed with it. Your application could be installing the driver every time it is launched and removing it when it is closed, or it could be installing it only during the installation of your program.
If you do not have the source code of this application but you still have the license information of the library provided by Amyuni, you could try building a small application or batch script that just takes care of the installation process. You can contact Amyuni support for a link to the latest build of the version you are using.
You mentioned that you are using Windows Azure VM, so I am assuming that you have administrative rights on the virtual system and that you can connect to it using remote desktop and run any kind of applications.
Usual disclaimer applies
I have a Windows CE device that we are deploying, but we have complete control of the software installed on it.
This is not a typical Windows Mobile device, this is a headless device that the user will not interact with. I know that on PDA-style WinCE devices, the .cab file is the preferred application distribution method.
However, on a headless device, we will be writing some type of upgrade/patch server that will ping a server for updates, download them, and auto-install when they are available.
Do I still want a .cab file, or is a .zip (or even something else) better?
What are the requirements for a .cab file - what kind of restrictions / requirements might get in the way and be an annoyance? What are the benefits?
I'd stick with CAB as a package since even headless devices can use the CAB extraction tool. If you ZIP it, then you have to add a ZIP support library and app. CAB also has the ability to add registry entries and define far more disparate target locations than a zip (I want x.dll in \Windows but prog.exe in my program folder - try that with a ZIP).
One thing to keep in mind is that wceload (the CAB extractor) uses a UI by default, so you're going to want to use things like the /noui switch for it.
If you're true headless this may not be an issue (not done that in a long while) but a fairly common "headless" configuration has display support and either the display simply isn't hooked up or is something like a NOP VGAFLAT driver. This allows you to run a shell and have access to all the nice shell APIs, but adds to the challenge that GWES will render dialogs onto the non-existent display.
OpenNETCF also has a CAB Installer SDK that you can use to completely remove any UI with by creating your own installer app. This may or may not be useful depending on the how and when the install happens (through HKLM\Init or otehr for example).