I want to know if I can distribute a copy of a Windows 8 App using some form of package file, avoiding the need to get it from the Store. I want to target average users, not developers.
If you're targeting end users, i.e. consumers, then the answer would be no. I don't even see the advantage of bypassing the store in this case, since it only brings you a larger potential market for your application.
Sideloading of applications (the name used for installing them without publishing to the store) is supported only for the enterprise scenario to allow companies to install their own line of business applications which they don't want to publish in the store. There are multiple requirements for this to work which are not feasible for individual end users.
That being said, nothing prevents you from creating the appx package (Project > Store > Create App Packages... menu in Visual Studio) and distribute it to your users. Along wih the package a PowerShell script is generated (Add-AppDevPackage.ps1) which takes care of installing the application on another machine, including installing the certificate and obtaining the deceloper license (for which he will need a Live account). The user will require administrative privileges to run the script. And he will have to renew the developer licence every 30 day for the app to continue working. Because of all that this process is really only suitable for a small number of users who can test your app before you submit it to the store.
I found the link below as an answer to a previous question. It seems that you could easily install it using the temp folder and NSIS.
How to install a Windows 8 App Without Submitting to Store
The Windows Store is exactly the mechanism you'd want to use to target average users; it's the place they will go to discover and install new applications.
Technically, you can sideload applications; however, that mechanism is for distributing line-of-business applications within an enterprise. You can also install an application package directly on an end-user machine, but that will require a developer license on that machine, and that's explicitly contrary to your goals.
Related
Why is it a good idea to limit deployment of files to the user-profile or HKCU from my MSI or setup file?
Deployment is a crucial part of most development. Please give this content a chance. It is my firm belief that software quality can be dramatically improved by small changes in application design to make deployment more logical and more reliable - that is what this "answer" is all about - software development.
This is a Q/A-style question split from an answer that became too long: How do I avoid common design flaws in my WiX / MSI deployment solution?.
As stated above this section was split from an existing answer with broader scope: How do I avoid common design flaws in my WiX / MSI deployment solution? (an answer intended to help developers make better deployment decisions).
9. Overuse of per-user file and registry deployment.
Some applications won't run correctly for all users on a machine, because the user-specific data added during installation isn't correctly added to other user's profiles and registry. In other words the application just works for the user who installed the software. This is obviously a serious design error.
There are several ways to "fix" this, but the whole issue of deployment of per-user files and settings is somewhat messy for a few fundamental reasons:
How do you reference count components installed multiple times? (for each user on the machine)
What do you do with the installed data and settings on uninstall?
How do you deal with new files and settings to install that differ from the ones that are on disk and in the registry and have user-made changes? Surely you don't overwrite automatically?
There are no real clear cut answers, but there are several alternative ways to deal with the "problems". My preferred options are 2 & 3 since I don't think Windows installer should deploy, track or attempt to modify or worse yet, uninstall user data and settings at all - it is user data that shouldn't be meddled with:
9.1 Using Windows Installer Self-Repair or similar
The first option is to get settings and files and HKCU registry keys deployed properly via the setup itself or setup-like features. There are two major ways to do this: relying on Windows Installer "self-repair" generally triggered by an advertised shortcut, or using Microsoft Active Setup.
Self-repair is what happens when you launch a shortcut to start your application, and Windows Installer kicks in and you see a progress bar whilst "something" is being installed. What is typically added are HKCU registry entries and user-profile files.
There is also another alternative to achieve this, it is called Active Setup and is also a Microsoft feature. It essentially registers "something runnable" to run once per user on logon. This can be used to set up per-user data. Active Setup allows "anything runnable" to be executed - for example a copy of files to the user-profile. .
Both of these options mean that the user data and settings are copied in place once - and from then on they are not generally touched, but in the case of "self-repair" might get uninstalled for any user who actually runs the uninstall of the application (unless the setup is designed not to do so).
Although setting up user data with self-repair and Active Setup are "established" methods to get applications running properly, it seems wrong to track user data with Windows Installer components. Why? Because it is really user data that shouldn't be meddled with once initialized.
Accordingly my honest take on the whole issue is to try to avoid deploying user specific data or registry keys and values altogether, and this is what is described next as two other user-data deployment methods.
9.2 Application Initialization of User Data
The second alternative, and one that I find much cleaner, is to change your application executable to be able to initialize all per-user settings and files based on default setting and templates copied from a per-machine location or based on application internal defaults (from the source code) instead of writing them via your setup.
In this scenario Windows Installer will not track the files or settings that are copied to each user. It is treated as user data that should not be interfered with at all. This avoids all interference such as reset or overwritten user data during upgrades and self-repair (and manual uninstall and reinstall).
If there are cases where "fixes" must be made to application settings, this can be achieved by having the application executable update the settings for each users on launch, and then tag the registry that the update has been completed.
The overall "conclusion" is that your setup should prepare your application for first launch, it should not set up the user data and settings environment. All user-profile files and HKCU settings should be defaulted by the application in case they are missing on launch - this yields a much more robust application that is easier to test for QA personnel as well. This is particularly important for Terminal Servers where self-repair is not allowed to run at all. In such cases the application data will be missing if you rely on self-repair to put user data in place.
9.3 "Cloud" or Database Storage of User Settings
To take things a step further in today's "cloud environment" - and this is in my opinion the preferred option. Why should your application be restricted to files and registry keys and values? Why not store all user specific settings in the solution's database?
Full access, control and persistence for all settings without any deployment issues at all.
You do get new management issues though, and they must be shared between developers, system administrators and database administrators. But isn't the cloud pretty much the industry standard by now?
We have been struggling long enough with roaming profiles, corrupted user registry, mishandled user-profile data files, etc.... Developers, save yourself a lot of trouble, and create yourself some new database management issues instead of deployment issues - and start yelling at a whole new bunch of people! :-).
Settings in databases are:
Not suffering from "dual source problems". There is one instance, and it is updated in real time. Not like the synchronization problems seen with user-profile and "roaming".
Inspectable, manageable and patchable
Revisable (version control - can revert older settings)
You could even "tweak" all the user settings from your setup still by running database scripts as part of deployment, but if you are in a corporate environment - isn't the thought of just raising a ticket and then have your database administrator run the maintenance scripts with proper transaction support and rollback much more appealing?
Even if you are delivering a large, fat-client vendor application for general distribution and third party use (in other words not a tailored, corporate client/server solution where you are guaranteed to have a back end database), one should consider cloud storage of user settings by having users log on to a cloud using their email or similar and then synchronize settings in real time.
Such large applications generally always need to "cache" some settings files on the computer and in HKCU, but it seems more and more possible to save all settings in a single temporary file in the user profile area which is entirely "sacrificial" and even possible to delete if it is corrupted and then download the last saved settings.
Instead of hosting the cloud yourself, it is obviously possible to use company DBOs to configure their own company-wide cloud where they have full control of all settings, and can also enforce mandatory policies and restrictions for your software's operation. Not to mention the proper backup that is possible for all user settings.
I am attempting to write a small, lightweight client, using vb.net winforms, that can install without needing elevated privileges. Before I ask my questions, let me give you a bit of an idea of what it is supposed to do.
The app will start when Windows loads, set like this from the install, with a system/notification tray icon that can be clicked on to load up specific functionality. The application install from a website, or possibly a file share, haven't quite decided yet. This client will initially request user credentials for one of our web programs, and it will talk to an already built web service to determine what functionalities of our services they have licensed access to. After this, credentials will be encrypted and saved to the users pc locally. Every five minutes, the client will pass the credentials to the websites they have access to and check to see the status of jobs that are being processed, and download available reports if needed.
So, here is what I am trying to understand. If I configure this app as a ClickOnce application, once it installs from the url or shared drive, the user will not need to do anything else, correct? Or do they have to visit that url every time they boot up to reinstall/run the client?
Another thing, I wanted to get some opinions on the best ways to do some of the things this app will be doing. I have a good idea of where I am going with it, but I have no idea of which solution to go with yet.
For instance, what is the best way to store user passed credentials on their system for a "remember me"?
Also, is the best way to have the client install with automatically starting on windows startup to configure it to create a shortcut of itself in the windows startup folder?
I am trying to keep this as lightweight as possible, and using a very small GUI, so it shouldn't be too intrusive, so any ideas on how to ensure that, while keeping it from needing admin privs to install, will also help.
If I configure this app as a ClickOnce application, once it installs
from the url or shared drive, the user will not need to do anything
else, correct? Or do they have to visit that url every time they boot
up to reinstall/run the client?
Well if they need to reinstall it, they would have to download the setup.exe file again, but why would users need to do that? CilckOnce supports automatic updates. Visiting url is certainly not needed for running the program.
what is the best way to store user passed credentials on their system
for a "remember me"?
Probably storing them as application settings. Haven't used visual studio 2012, but in visual studio 2010 you have to right-click on project in solutions explorer, go to project propeties and then create variables in Settings tab. Then you can access those variables in code using My.Settings.variableName. Not sure about security though, if you need any.
As for privileges, I think you just need a privilege to install a program. Maybe you should publish a primitive clickOnce application and experiment with it and that will answer all your other questions about clickOnce.
I'm about to implement some unlock-functionality In-App-Purchase in an app. The client would like the functionality to be available the first two weeks after installing the app, and then go away until the user pays up.
I need the app to determine whether it has been previously installed, deleted, and installed again. If I can't do that users can just reinstall the app and get two more weeks for free.
Any ideas?
It seems all data is deleted when the app itself is deleted, which kind of limits my options. There is a server backend to the app. Is my best option to log something there or is there another way?
You can make use of the keychain in iOS. It will not be removed even if you uninstall the app. But you have to make sure you use the same provisioning profile across different versions of your application.
And, have a look at this utility
The problem is that recently on my company we need to make an installer, since anyone haven't worked with InstallShield Before we have a lot of questions about it.
So here are the questions:
Am I able to restore a database using InstallShield? I mean, giving to it the path of the .bak file and then run a script and recover the database on mssql?
Does Install Shield have configuration files, so I'm able to change the files that are going to be used, depending on the client and the software version we are installing? Nowadays we use our own setup, but we have to select the files manually, so when a client whants to install a software we have to go with them and do it, because is really complex. Now we need to change that by making an installer that can be configured here in our company by and IT member, then send the files and the installer to the client and he only press "Next, Next..."
Sorry for my bad english
You might find that treating the front-end software and database as two separate items is easier for you and your clients. While many vendors offer the ability to run scripts against SQL Server (and other databases) during the course of the installation, you'll find that there are all kinds of issues you need to contend with (do you need to first install SQL Server, does the user have permission to access the SQL Server, what if they are installing the software on a new pc but don't need the database created again, etc). None of these are showstoppers, but they do create headaches that you need to deal with.
By treating the database and front-end separately, you can build an installation package that installs your front-end software and related components on the target machine. This in and of itself can be tricky to deal with depending upon how complex your software is and the amount of references and prerequisites you need to manage.
When it comes time to manage the database aspect of the program, you may find that the majority of your clients are capable of restoring a .bak file to their SQL Server, and the ones that aren't can always be assisted (probably remotely) by your staff.
If you discover that this isn't the case, you can always create a separate "Server" installation package that manages the database aspect of the installation.
With regards to your question about InstallShield, you'll probably find better information from their website and \ or sales staff, but here's a list of their current features.
There are other vendors in the space as well, so look at all of them including InstallAware and my personal favorite Advanced Installer. Pick the one in your budget that offers the features you need. They all should offer trials as well. Download and use them before you buy to find one that works best for you.
Yes installshield can call a script that will restore a db, you just need
to do so in silent mode. and yes there is a cfg file for install shield.
the documentation will show this in detail
here is some documentation for version 12
http://kb.flexerasoftware.com/doc/Helpnet/installs hield12helplib/IHelpContents.htm
they are currently on version 2012, however if you are doing this
crossplatform, don't use installshield, but use installanywhere. it is cross
platform.
I'm looking for suggestions on keeping a program that is running on a network updated. Installation consists of 15 users, each have the program on their local pc, but they all access same date from sql server.
I am looking for a clean method that would allow me to update one folder on the network and for each computer to get updated when they run the program and the programs sees a later ver on that folder on the network. (Obviously I can do this inside the program itself since it won't allow being overwritten while opened.)
You should have a look at
ClickOnce is a deployment technology
that enables self-updating
Windows-based applications that can be
installed and run with minimal user
interaction.
Using ClickOnce Deployment in
VB.NET
ClickOnce - A new VB.NET 2005 Deployment Tool
ClickOnce Deployment for Windows Forms Applications
ClickOnce Deployment in .NET Framework 2.0
Another option is to create a second program that will check the network for an updated version of your application. Let's call this program "updater.exe".
You can run updater.exe on system startup like Adobe Reader or Sun Java do.
Or, when your application is started it can load updater.exe. If updater.exe finds an update, it can close/unload your application, download the newer version, restart your application and close itself.
astander's answer above is correct, you can use ClickOnce for this. Another option is creating this application as a web application.
Web applications basically work the way you described, the application's files reside in a web server, all the users connect to it using a browser, and to update the application you only need to update the files in the server.