Dev Chair : The Vista Tax
On the other hand as a .Net software developer, Vista is both a blessing and a curse. I want every single Windows user migrated to Vista as soon as possible because having the .Net framework included as part of Vista's standard installation is a very big deal. This means that application installers will no longer need to check for the presence of the .Net framework or provide a method to automatically download and install it if absent. This is a huge time and effort savings for the user as the framework is a large download. Also some users are turned off by the mere idea of downloading yet another component in order to run an application in XP. With the framework part of the OS, users will have one less thing to worry about.
Further, version 3 of the .Net framework contains a number of new technologies that are very useful for developers. Windows Communication Framework (WCF) provides developers many tools to incorporate communication protocol and web services in their applications quickly and securely. The Windows Presentation Framework (WPF) will further allow developers to write UI code in more abstract, and most importantly, testable fashion.
But, and there is always a but, Vista's improved security also brings along the UAC. To regular users, UAC will probably just another obstacle in their daily computer usage. But to developers, UAC presents a whole new dimension of complexity with regards to application installation and user interaction.
In an ideal world, an application running on Vista will only require administrator access/permission during the initial installation. All subsequent usage will be allowed even with the lowest user access level with the minimum amount of UAC intervention. If the application is relatively straightforward and does not have legacy dependencies such as COM components then just copying files to the Program Files directory should work fine. If legacy dependencies exist then UAC will kick in during the installation process and its effect can be different from what might have been expected. Microsoft acknowledges this is a complex issue and has a comprehensive range of MSDN documents detailing this topic. But there are infinite scenarios in real-world deployment so each developer must go through their existing installer with a fine-toothed comb to ensure the user experience is smooth and pleasant.
All these assume that the installer is created using Microsoft's own MSI technology which provides extended capability over other installers such as NSIS or Inno Setup, because MSI runs as a Windows service in Vista. This allows 'deep' access to the OS without triggering UAC as one would with non-MSI based installers.
This presents a dilemma to developers, such as myself, who currently do not use MSI. Should I spend time modifying and testing the existing installer so the user experience in Vista is optimum -- a process with an unknown volume of work involved -- or should I convert completely to MSI to take advantage of the deep hooks MSI provides in Vista; even if that means starting completely from scratch?
This is just one of many issues that developers need to grapple with when delving into Vista. I am sure I will find out more as I continue to sink deeper into Vista compatibility in the near future.