Problem:
You can’t move a "Click-Once" deployed application from one environment (or server) to another.
Details of problem:
If you work in a normal IT shop, you probably have multiple, duplicated environments set up for your code. For example a typical set of environments would be for:
1. Development
· Used by the developers while developing their code.
2. Staging/QA/Testing
· The developer usually places (or requests System Admins to place) their release candidates here for users to test and validate.
3. Production
· Once the users have validated the release candidate in the staging environment, the system administrators are asked to move it to production or the "Live" environment.
Each of the 3 environments usually have duplicated database servers and web servers, and potentially duplicated network shares and any other resources needed by an application.
If your work environment has good security procedures put in place, your developers probably don’t have access to make changes to the staging environment and they almost certainly don’t have access to making changes to the production environment. This is a win-win for everyone involved: It makes those in charge of IT security happy and it gives the developers plausible deniability when something goes wrong in an environment that they don’t have access to.
Most web applications are deployed, usually by the developer, to the development environment. Once the developer is happy with the code there, they will ask the system administrators to move that code to staging. The key here is that it’s the SAME binaries that the developer put in the development environment. The system administrator will likely make changes to the web.config file to change the database connection string(s) to point to the staging database(s) instead of the development one(s) and any other config changes needed to make the staging code use the staging resources and not the development resources. This connection string, for security reasons, is usually not provided to the developer. Later, after users test on staging, the system administrator will then move that same code to production, making the appropriate changes to the config files.
This process of moving the same binaries from environment to environment is critical to ensuring that what gets moved from one environment to the next is the actual code that was tested in the prior environment. Hence the problem…
To deploy a Click-Once application, you have to provide, at build time, from within Visual Studio, the URL from where the end users will be launching the application. YOU CANNOT CHANGE THIS AFTER DEPLOYMENT!!! This means, the deployment model described above, that is in common use, cannot work with a Click-Once deployed app. Once you build and publish from Visual Studio, the "launch from URL" is in the deployed files and the deployed files are CRC’d as part of the Click-Once deployment. When a user runs the application, one of the first things that happen is that the .NET Click-Once technology on the end user’s machine kicks in and validates that all the files are in the original condition they were in when deployed from Visual Studio by validating the CRC. If it detects that a config file (or any file) has been altered, it throws a security exception and will refuse to run the application.
The "Solution":
I put the word "solution" in quotes to imply that this is not really a solution. It is a work around that does not resolve the problem of needing to deploy a single binary image from environment to environment. Only Microsoft can fix that problem. Instead, this is a description of how you have to deploy to multiple environments and the deployment changes your system administrators will have no choice but to adopt. This is not a preference, but a technical requirement. There is no alternative with Visual Studio 2008. I have been told, BTW, that this will be fixed in Visual Studio 2010.
Here’s what you do:
After you’ve deployed to your development environment, take a snapshot of your code in whatever method you prefer; whether that’s making a copy of the entire solution to another sub-folder, or checking it into your source control repository and labeling it, or whatever other method you can concoct. You must do this because later, when you deploy to other environments, a significant amount of time may have passed and you may have continued on with developing newer features and your code will not be the same. You’ll need the older snapshot to rebuild to the staging environment, then again to the production environment.
Later, after your own testing in development, when you’re ready to deploy a release candidate, you’ll need to rebuild from that snapshot codebase, but making only the appropriate changes to make it build for the new environment (the "launch from URL" and the config file changes). Then again, some time later, after the users have tested and validated the staging code, you’ll need to rebuild again for the production environment, using that same snapshot, making the appropriate "launch from URL" and config file changes.
Alternate Solution:
Note: Most system administrators would not want to do this alternate solution, but it is a more secure strategy and removes the blame for differences in environments off your shoulders.
Pre-requisites:
· The system administrator who will be performing the move needs:
o The same version of Visual Studio you used to create it.
o All of the 3rd party and custom add-ons (like Telerik, LLBLGen, Oracle, DB2, or other database Providers and drivers, etc…) installed and configured.
o Access to your source control system or a copy of the snapshot of your source code.
o Knowledge of how to build and deploy Click-Once applications using Visual Studio.
o A compilable, error free, snapshot of your code.
1. When you ask the system administrator to move your code from dev to staging, you instead provide them with your snapshot of the source code, whether it’s a labeled version in your source code repository or a copy in a folder somewhere.
2. The sysadmin then configures, builds, and deploys your code to the staging environment.
3. Later, when the users have validated your staging deployment, you then ask the system administrator to redeploy that snapshot to production, where the admin will make the necessary config changes and build and deploy to production.
This actually requires less work for the developer, is more secure, and gives a little more insurance to the customer that what they tested is actually what’s being deployed to production. At the very least, it removes the blame off the developer’s shoulders if something is changed between environments.
RTM is an acronym for “Release To Manufacturing”. In the software industry, it’s usually used as a label for a certain released version of a piece of software. For example, before Microsoft releases a new version of Windows to the public, they’ll release several test versions (called “beta” versions) to a select few, then a larger release to some developers, then a test release that they believe is done, called a release candidate “RC”. Finally, once they’ve decided that no more changes will be made, they’ll release the product to the manufacturers (RTM) so that they can start mass producing DVDs for sale in stores and distribution with new PCs.
