Within federal computing systems, it is commonplace (and regulated) that a standard image be used when creating new machines that are going to be put on either NIPRNet (unclassified) and SIPRNet (classified) systems. While this is all fine and good, there is/was little or no control over what the user did after receiving said image, besides a loosely documented list of standard permission sets targeted to reduce malicious interaction. Something that is still being rolled out under some commands in the Air Force is called SDC, which stands for Standard Desktop Configuration, by which a user receives a standard pre-configured / packaged Windows image with common software. Included in the package are mechanisms that control the software that is in the future placed on the machine, and takes away a lot of rights from the user such as installing software packages as well as visiting certain web addresses. Besides the obvious conformity and maintenance benefits that this approach cultivates, it is also aimed at promoting better security as all users are ensured to have AV and Security packages up and running when they first get their machine, and masquerading malicious software cannot be installed by an unaware user.
While this all seems great and good from an aggregate benefits standpoint, SDC makes my life as a developer god damn terrible. Really bad. While I am a web developer, sometimes I don’t see a reason, it would just be easier to avoid, or a client application would provide a richer experience over building a web application / WebPart set. Unfortunately, I can build a great application using WinForm and WPF, however SDC won’t let me install my package since it is trying to deliver a non-standard software suite, and installing custom software is going to break that trend. So, either you have to fill out a stack of paperwork, or use ClickOnce.
ClickOnce as opposed to using the output from a VS.NET setup package uses two separate manifest files, the deployment manifest and the application manifest, the latter of which is meant to describe the application such as the files that build up the total structure of it, the former provided information such as software versions and other information such as update procedures. The deployment manifest is considered to be the starting point for the ClickOnce installation.
Back to how this relates to SDC stuff, my problem was I was unable, or had to go through a mound of paperwork, in order to install a couple SharePoint targeted, WinForms built, applications that some of my users needed access to. ClickOnce is non-intrusive to the users file system on their local machine, meaning there won’t be any registry entries, put anything into the GAC, etc. Furthermore, the files that are being used are stored in a ClickOnce run-time managed application store that helps to avoid SDC application collision as well.
Because of the above two conditions that ClickOnce promotes, I can install whatever fat / smart clients I want on my users machines now without having to go through any headache. If you are plagued by SDC and do some Windows development, I would encourage you to go the ClickOnce path. Yeah! :)