Deploying for Multiple Groups

A common requirement is to have different application functionality exposed to different sets of users based on their roles. The roles may be based on functional roles, such as customer, teller, and branch manager, where you want to expose distinctly different functionality to each role. The roles may also be based on some other type of group distinction, such as end users, beta testers, Q&A, and developers, where each role sees roughly the same functionality, but each role actually executes a different code base to get that functionality. For the purposes of this guidance, a division that requires different users to execute different code bases is considered to be a group.

With the role-based security in the .NET Framework, you can determine a user's role at run time to change the behavior of the application based on role. For example, as your form loads, you can check to see whether the user is a branch manager; if the user is not a branch manager, certain options on the screen can be made unavailable. When using the Composite UI Application Block, you can set roles for different modules in the profile catalog and use that to determine which modules are available to each role. Between these two capabilities, it is straightforward to handle requirements for role-based modification of application behavior on a single code base.

ClickOnce can be used to provide different code bases for different groups. A single user may be part of a single group or multiple groups, and if a user is part of multiple groups, the user needs to be able to run multiple versions of the application on the same computer at the same time. An example of this is a developer or tester who wants to be able to run both the beta version of an application and the production version of the same application side by side to compare functionality or features.

To meet this requirement, you can publish multiple versions of your application to the deployment server and direct users in different groups to the appropriate deployment manifest for the version that you want them to run. The different versions can even share some files on the server side if desired. For more information, see How to: Share Application Files Across Versions.

Usually in ClickOnce, when you publish a new version of your application, the default deployment manifest is overwritten with the new version's deployment manifest, and there is no way for client computers to deploy and run the earlier version from the server. If the application is configured to check for updates, the client computer will detect the new version and will be updated the next time it runs if it has connectivity to the deployment server. In fact, the installation engine in ClickOnce also uses the deployment manifest name to help distinguish individual applications. This means that even if you publish two different versions of your application to two different URLs, you will not be able to run them as separate applications on the same computer from the same user account unless they have a different deployment manifest name. When the second application is deployed to the client computer, it overwrites the deployment information for the first application if the deployment is signed with the same publisher certificate and has the same deployment manifest name. As a result, the usual versioning behavior of ClickOnce is not sufficient for you to execute more than one version of an application on your computer at any one time.

When you publish multiple versions of your application to target multiple groups, you have to distinguish them with different deployment manifests, with each having a unique deployment manifest name. The different versions of the application do not necessarily have to be distinguished by version numbers, although they should, and they can be placed in the same folder on the deployment server if desired. Because the deployment manifests have unique names, the URLs to them will be different, so the client computer will see the different versions as separate and distinct applications and will install both versions of the application on the client computer and allow them to run side by side.

Unfortunately, Visual Studio does not provide control over the deployment manifest name that is generated, so you will have to use Mage or a custom tool to modify the manifests after publishing from Visual Studio. For more information about how to support multiple user groups using deployment manifest naming, see How to: Publish Different Versions for Different Groups.