Friday, June 22, 2007

Developing on Vista - Part 2

To UAC or not to UAC?

Presenting At Victoria.Net SIGWhen I presented on this at the Victoria .Net SIG meeting a week ago, I wasn't quite sure of the general understanding amongst the group about User Account Control (UAC), so I asked the question, "Who here knows what UAC is?", and about 5 (out of 50) people put up there hands. I had intended on launching straight into my argument, but with the vast majority of people not knowing what UAC was, I had to explain a bit about UAC first, so I'll do the same here.

If you are already familiar with UAC, feel free to skip over this explanation and go on to Developing with UAC.

 

What is UAC?

You may have seen the very funny Mac Vs PC Advertisement that makes fun of UAC, although it is a bit of an exaggeration. Mal-ware has been a serious problem for Windows (as Apple are not backward in pointing out), and the reasons that mal-ware is such a problem stem from the way in which the vast majority of Windows PCs are used. By default, when you create a new user on a new Windows based machine, they are set up as an Administrator (ie have unfettered access to any part of the system, files, registry, hardware etc...). This means that unlike linux or unix based operating systems, you do not need to log in as a user with higher permissions to install software or make system level changes etc..., which significantly lowered the barrier to the general population being able to use PCs, and is part of the reason for the success of Windows as an OS in the home user market. It has also meant a lower barrier of entry to mal-ware which is why we have such a problem. In a unix or linux environment, if a user accidently runs a virus, or if a piece of mal-ware infiltrates the system through a user application, the most that it can do is infect files that the user has control over, which means that it won't infect any system files because a unix/linux user would never dream of running as an administrator when performing normal tasks

It's not like Windows XP forces you to run as an Administrator, in fact in many corporate environments that have a dedicated IT department controlling their network, users are configured to run as normal users on their own machines.Tasks like installing software and configuring networks and drivers are generally handled by the IT department using various remote administration technologies. This makes for a much more secure corporate environment, and means that users can't install malicious software accidentally.

Ideally everyone should be running as a normal (non-administrative) user when doing normal day to day activities, even if the computer is their own personal home PC. The reason people don't do this is 2 fold. Firstly because it is the default when installing a new operating system, and secondly, a lot of applications have been written for windows that for no good reason require Administrative access to system resources. So UAC is Microsoft's first attempt at fixing this problem.

In Vista by default when you create an Administrative user, Vista will generate 2 separate user tokens, one that has Administrative access to the system, and another that has normal user (restricted) access to the system. When the user is logged into Vista, by default the system uses the token associated with the normal user, but if an application attempts to do something that requires elevated privileges, Windows Vista will warn the user with a dialog asking if they started the program, and if it's OK to use the Administrator token to perform the operation. This means that if malicious software tries to infiltrate the system without being detected by the user, as soon as it attempts to do anything that requires administrative access, it's cover will be blown, and the user alerted to what's going on.

As with many things in Windows, you can actually turn UAC off completely, however, this just puts the user back into the position you were running Windows XP with Administrative privileges. A better approach is if an application requires administrative permissions (and really the only types of applications that should are system utilities that are performing low level administrative style tasks, not your general run of the mill user application), then you should use the "Run As Administrator" option to start the application. This means that you give that application the permission to run using your administrative token, while everything else uses your normal user token, protecting you from malicious software.

Now I'll be the first to admit that UAC isn't perfect, and especially as a developer, I do find myself getting a lot of UAC warnings as I perform certain tasks, but I personally think it's a step in the right direction. I also believe that for most normal users, these UAC warnings will happen so infrequently that they shouldn't be a problem.

 

Further reading on UAC:

 

Developing with UAC

Visual Studio 2005

When Vista first came out, and the early adopters in the development community first started using it as their primary development platform, there were many issues. One thing that did happen when you attempted to run Visual Studio as a normal user is that it would display a warning saying "You should run Visual Studio as an Administrator". In fact this was the official line from Microsoft, and as far as I'm aware still is. I also believe that this is WRONG! Service Pack 1 and the Updates for Windows Vista have fixed a lot of problems, and it is now possible to run Visual Studio and perform MOST of the tasks you do as a developer in normal user mode. The majority of things work just as they did on Windows XP. Developing Console Applications, Winform Applications, WPF Applications, and many more types of applications DO NOT require you to be running Visual Studio as an Administrator. However, there are some scenarios where you may still need to run Visual Studio as an Administrative user.

Most of the problems revolve around trying to debug into processes that you don't own. For instance if you are developing an ASP.Net application and you are using IIS7 instead of the the Visual Studio Development Webserver (Cassini), then debugging requires you to attach to the w3wp process. Not surprisingly, this requires you to have Administrative Privileges, and currently there is no way from within Visual Studio to elevate those permissions on the fly, so if you are intending on doing this, you'll need to start Visual Studio as an Administrator. Alternatively, you could use the Visual Studio Web Development Server (Cassini) to host your application while in development. Cassini quite happily allows you to attach and debug into it as it is started by the same user that started Visual Studio. It also has the advantage of allowing the "edit and continue" feature of Visual Studio debugging (something IIS7 or IIS6 can't do), and it is generally a little faster. Cassini will behave identically to IIS7 in the vast majority of scenarios, however there are some deficiencies with Cassini. It can't use the HTTPS protocol, in this case I usually find myself adding a configuration setting to determine if I am in development or production, and switching to use HTTP when in development. It also can't emulate subdomain scenarios properly. So if you need to test Single Sign On scenarios across subdomains, then you will need to use IIS7. There are also some other subtle differences in the way Cassini processes the ASP.net pipeline to the way IIS processes it. I am a firm believer in testing your application as close to your final production environment as is practicable, so I do recommend that final stage development testing is done against IIS, and not cassini, but you should only need to debug using IIS7 if you find a problem that only occurs when running the application under IIS7, and does not exhibit when running under Cassini.

Another thing that I have found to be problematic is installing assemblies into the GAC. Installing assemblies into the GAC is by it's very nature an administrative task, and requires elevated privileges. I have seen many projects that, as part of a post build step automatically deploy the newly created version of a shared assembly to the GAC. Obviously if you are running as a normal user, this post build step will fail, thus causing the build to "fail". Now personally I would question the need to install libraries to the GAC during development, and would encourage development teams to look at ways of privately deploying shared libraries during the development phase instead of deploying to the GAC. Adding a probing element, or a codebase element to the applications configuration file will allow you to share common assemblies amongst applications during development. However, if you insist on installing libraries to the GAC in a post build step, then you will have to run Visual Studio as an Administrator for that project to build.

There are some other minor glitches that are left over as a result of Visual Studio 2005 not quite being vista ready, (see Issues running Visual Studio 2005 on Vista as a normal user). Even running Visual Studio 2005 with elevated permissions there are still some minor problems on vista, (see Issues running Visual Studio 2005 on Vista With Elevated Privileges), but these issues occur infrequently enough, or there are adequate workarounds for them not to be a problem (at least in my experience).

 

SQL Server 2005

When Vista first hit the streets, SQL Server 2005 Service Pack 1 had already been out for some time, but unfortunately there were still lots of incompatibilities with Windows Vista. Most of us were forced to run SQL Server Management studio as an Administrator to tackle some of these issues. Service Pack 2 fixes a lot of these problems, and certainly after running the user provisioning tool, there is no longer any need to run SQL Server Management Studio as an Administrator anymore. There are still some issues mainly around Microsoft Visual Studio for Applications (VSA) used in SSIS script tasks, but beyond this, there are few significant problems.

See Windows Vista Considerations in the Service Pack 2 Readme document.

 

Why not just turn UAC Off?

Many developers argue that they are experienced computer users and as such feel somehow immune to mal-ware, and anyway, they run anti-virus software, so they are protected against malicious software attacks. They also argue that they constantly need to perform tasks that require administrative privileges, and therefore feel that turning UAC off all together will save them heaps of time, and put an end to all the UAC warnings.

Although dubious, let's assume for a moment that the first argument holds some water. I hope by now I will have been able to convince you that you don't need to run Visual Studio as an Administrator all that often. I would also argue that the effort of Clicking "Continue" from time to time on UAC dialogs when you do need to perform Administrative tasks is not going to cost you that much time in the grand scheme of things.

Another argument to keep UAC switched on is put very eloquently by Ian Griffiths, in his post UAC: Don't be part of the problem. Ian argues (as I did in my explanation of UAC) that part of the reason people feel they have to run as an administrator on Windows is because there are so many end user applications that require Administrative privileges for no good reason. He then goes on to argue that the reason that so many applications require elevated privileges is that they were written by developers who were running as Administrators on their own machines at the time of development, and were completely unaware that the code they were writing would not run without elevated privileges. he quite rightly says that this sort of behaviour in the linux/unix/OS X development community would be frowned upon, and the resultant applications would just not get used. Please DO NOT turn off UAC before reading Ian's article.

I would also argue that always running Visual Studio as an Administrator is just as bad (at least from the point of view of Ian Grifiths' argument) as turning UAC off altogether, because when you debug your applications, they will always be launched with elevated privileges, and you will never see potential normal user problems.

I come from a position of having developed as a normal user on Windows XP, and it is soooo much easier to develop with UAC on Vista than as a normal user on Windows XP. It is also much more secure. If you were developing as a normal user on Windows XP and needed to run something with elevated privileges, you would have to use the "Run As" command which would require you to type in your administrator password every time. The more times you are forced to type in a password the more chance there is of over the shoulder credentials theft. UAC simply requires you to validate that it was you who invoked the task that required the elevation of privileges.

 

Tips to help you stay on the wagon

Here are a few tips to help you run on Windows Vista and navigate the potential problems of UAC.

  • Add Visual Studio 2005 to the quick launch menu

Quick Launch

This not only makes it quick and easy to find, but on the rare occasions when you do need to run Visual Studio as an Administrative user,  you can simply right click the icon, and select "Run As Administrator"

Run As Administrator

  • If you find yourself needing to perform lots of administrative tasks, simply run a command prompt with elevated privileges and keep it open as you develop. Anything you run from this command prompt will automatically have administrator privileges, and you won't get asked to confirm the elevation of privileges.

I am sure that there are a lot of people out there developing on Vista who have come up with some really good stratergies for developing on Vista, and I'd love it if you could leave any other tips/suggestions as comments on this post.

 

Conclusion

If there is one thing I hope you take from this post it's you don't need to turn UAC off to develop on Vista. Also that you don't always need to run Visual Studio 2005 as an Administrator all of the time.

 

Links

 

Technorati tags: , , ,

Wednesday, June 20, 2007

Developing on Vista - Part 1

As promised, I am putting together a series of articles around setting up your development environment on Windows Vista. I have been using Visual Studio 2005 and SQL Server 2005 (amongst other development tools) on Windows Vista since November 2006, and I must admit that the experience hasn't been all plain sailing.

Pasha Bulker 2

However, with the release of service packs for both Visual Studio 2005, and SQL Server 2005 that address some of the problems, the situation now is much better than when I started. There has also been a lot of mis-information disseminated about how Visual Studio 2005 and SQL Server 2005 interact with UAC leading to some confusion about how we should run them.

In Part 1 Installing the toolset I hope to give some guidance around getting your development environment installed and running. In Part 2 To UAC or not To UAC? I'll explain the issues around User Account Control (UAC) in some detail, and hopefully convince you that you don't need to run Visual Studio 2005 as an Administrator all the time. In Part 3 I'll attempt to answer the question Why Move to Vista, and in Part 4 Tidying up I'll discuss what's not supported, give some general tips and tricks for developing on Windows Vista, and link to some further reading that might be useful.

Installing the toolset

As developers we all have various tools and utilities we just can't live without. I am a .Net developer, and as such I wish to limit this discussion to the Visual Studio 2005 and SQL Server 2005 toolset. I will talk about a few of the other tools that I have had dealings with, but it will by no means be a complete list. I encourage anyone who has experience (good or bad) with a particular tool on Windows Vista to leave a comment on this post.

Choose a Vista

The first step when taking the plunge into Windows Vista, is to decide on what version of Vista is appropriate SKU of Windows Vista. The good news is that Visual Studio and SQL Server are supported on all SKU of Vista. There are however some issues when running Visual Studio 2005 on versions of Vista that don't support Active Directory, so my general advice is to choose one of the following versions

Order of Installation

Since I started using Visual Studio 2005, and SQL Server 2005 back in January 2005 (yes that's right almost a year before they RTM'ed), I have installed the toolset many times, and had some success as well as some pain. I have developed the following order of installation based on this experience, and also on my experience since starting using Vista (November 2006).

  • Set up IIS 7
  • Install SQL Server 2005 Service Pack 2
  • Install Visual Studio 2005 Service Pack 1 With Vista Updates
  • Install any other tools that you can't live without.

I will go through these step by step.

Set Up IIS7

By default IIS7 is not installed when you first set up Windows Vista, this is part of Microsoft's attempts to reduce the potential attack surface of the base OS, and make it a more secure environment for everyday users. However, if you're intending on doing any ASP.Net development, or want to run SQL Server Reporting Services, you'll need to install it and configure it appropriately.

 

To Install IIS7, Go to Start->Control Panel->Programs and Features, and select "Turn Windows Features on or off". In the "Windows Features" dialog, select "Internet Information Services", and ensure that you enable the following features as a minimum.

  • IIS 6 Management Compatibility
    • Without this, you can sometimes get some cryptic errors when performing certain tasks about not having Microsoft Front Page Extensions installed"
  • .Net Extensibility
  • ASP.Net support.

Figure 1 shows how this might look.

 

IIS7 Setup

Figure 1

 

Install SQL Server 2005

Obviously you need to decide on what SKU of SQL Server you want to use. For developers this usually comes down to a choice between SQL Server 2005 Developer Edition and SQL Server 2005 Express Edition. I personally prefer to run SQL Server Developer edition on my primary developer environment because I often use features that are not available in the Express version. This does not mean that you can't install SQL Server Express as well if you need to develop against it, but I would suggest installing the developer edition first. So the sequence would be...

User Provisioning allows you to add Vista users to the sysadmin fixed server role, make sure you provision the user you develop under.

* Be careful when performing the user provisioning immediately after the Service Pack install. Because the service pack requires you to stop ALL SQL Server Services, and doesn't re-start them before asking you to perform User Provisioning, the user provisioning will fail unless you explicitly go and re-start the SQL Server services. Failing this, you can always run the User Provisioning tool from your SQL Server installation at a later point.

C:\Program Files\Microsoft SQL Server\90\Shared\SqlProv.exe

Install Visual Studio 2005

Again, you'll need to choose which SKU of Visual Studio you wish to run, but once you have made the choice, the installation procedure is as follows.

If you wish to start writing .Net 3.0 applications, then you'll also need to install the following

NB the extensions for WPF and WCF is a CTP release, and as with most CTP software, there are some problems with it (running either on XP or Vista), and as far as I'm aware, this is the state it is remaining in until Orcas is released (I guess MS need to have something to encourage people to upgrade to Orcas when it comes out).

Install any other Tools you can't live without

At this point, you can then install any other tools/utilities/plug-ins that you normally use. Just check with the manufacturers around each tools compatibility with Vista, I will discuss in a later post some tools that have issues, but my experience on the whole is that most tools work fine on Vista.

 

Conclusion

This will get you to a point where you are ready to start developing on Vista. Most things should work just as they did on Windows XP, however, keep in mind that these tools were specifically written for Windows XP, and there are still some notable exceptions to this rule which I will cover in my next post.

 

Technorati tags: , ,

Tuesday, June 19, 2007

.Net SIG Presentation Wrap up

Well, I must say I got a bit of a shock when I asked "How many people are using Vista as their primary development environment, and 4 people out of 50 put up their hands. Maybe it's just the Readify culture, but most of us at Readify are using Vista as our primary development environment, (some at Readify have been using it since before RTM), and I had expected that a significant proportion of Developers would by now be using Vista as their Development platform.

 

This surprise sparked a question. "Why is it that so few Developers are running Vista as their development platform?" I'm not suggesting that Vista will suit everyones needs, or that people should upgrade just for the sake of upgrading, but developers are generally NOT techno-phobes, and are usually fairly quick to adopt new technologies that increase their productivity, or even just for the novelty value.

 

I guess there are numerous reasons why this might be the case, but one that occurs to me is that the information required to set up your development environment on Windows Vista seems to be spread around various places on the web making it a significant research task to find all the details. There has also been some mis-information that has lead to confusion. This I feel I am in a position to rectify. As a resut I have decided to do a series of posts aimed at accumulating the best practices around setting up your development environment on Windows Vista.

 

As I promised in my presentation, here is a link to the slides from my presentation, however, I will over the next few days put together a series of posts that cover roughly the same concepts as in my presentation, but go a little bit more in-depth.

Friday, June 08, 2007

Latent bug syndrome

Today I have fallen foul of what I call the "Latent Bug Syndrome". This will hopefully help people understand just how complex software engineering is, and why bugs occur in software despite the best efforts of all involved. Let me explain.

Let's say you have a system like the following.

SystemA

where System A represents a fairly complex, fully featured, fully tested product that exposes cerrtain functionality to the end users. Now System A can be operating 100% perfectly (or at least for the overwhelming majority of scenarios that are encompassed by the exposed feature set), however there still may be a "Latent Bug" hidden deep within the underlying logic of this system that is never exposed to the end user because the exposed feature set never actually allows the system to get into the state that would cause this bug to exhibit. As a really contrived example, let's take the classic divide by zero problem

 

public stat double DoCalc(double val)

{

return 42 / val;

}

This function operates as expected under all conditions except where val = 0, in which case it throws an exception. If the exposed feature set only alows the user to select numbers from a drop down box that contains the numbers 1, 2, and 3, then every possible test that a tester can do will NEVER produce an error. Keep in mind this is possibly the simplest example one can find, in real life, the scenarios are far more convoluted. The wrong assumption from this is that System A has no bugs.

Now lets suppose that System A is augmented with System B as shown below.

systema_b

Now System B has the potenial of producing conditions in System A that not only were never tested, but were never even thought of by the original developers and testers of System A, and in my contrived example, a user input into system B may very well cause the value of the val parameter to be passed 0. The thing is that the developers (and testers) of System B are usually different to the developers (and testers) of System A, and often don't have access to the source code, or even if they do, don't have time to follow every code path through the interactions with System A accounting for every possible state that System A could possibly be in to find such a bug.

If the testers of System A are doing a good job, they may actually pick up the bug, then of course the blame game starts. Who is responsible for this bug, who's going to fix it why wasn't this bug picked up before etc....

So this happened to me today. Fortunately the bug never made it to a production system (and no it wasn't the divide by zero bug suggested above, it was infinitely more intricate), but it did make me aware that I had made some assumptions about System A that turned out to be less than 100% accurate.

 

So how can one guard against The Latent Bug Syndrome.

 

System A

  • Thorough unit tests of all public (and some times even private) methods exposed by system A will catch a vast number of these bugs.
  • Better documentation of publicly exposed methods to help developers integrating with your system understand what assumptions you are making about the input to a method, and what state you are expecting the system to be in.
  • Test Driven Development could actually go a long way to irradicating this all together because in TDD you only write code to satisfy the tests nothing less, nothing more, so you don't get the situation where there is code that under ALL conditions tested is never executed. However, I have yet to see a company embrace TDD to that extent as the sheer time involved is usually far too much to justify it commercially.

System B

  • Developers and testers of system B need to have a good understanding of how system A works, what it was intended to do, and how they are changing the way in which System A is being called. Understanding this may help you know where problem are likely to occur.
  • Know what your assumptions about System A are... and constantly question them.
  • Again unit tests are your friend.
  • wrapping your interaction with System A is also a good way of being able to respond to changes in System A if they occur.
  • Thorough end user testing (there is NO substitute).

Wednesday, June 06, 2007

VS2005 Project Templates Failing

I came across a problem recently where I went to create a standard Console Application project in Visual Studio 2005 and to my alarm I got a message saying

 

---------------------------
Microsoft Visual Studio
---------------------------
Could not find file 'C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\ProjectTemplatesCache\CSharp\Windows\1033\ConsoleApplication.zip\ConsooleApplication.csproj'

---------------------------
OK
---------------------------

 

This took me back a bit, as creating a Console application is one of the most basic tasks you would ever want to do in Visual Studio 2005. my next thought (after trying exactly the same thing 5 or 6 times) was to run visual studio with elevated priviledges, but alas this still didn't fix the problem. I checked and sure enough I could still create a Windows application no problems (with or without elevating my priviledges), so I just put it down to some kind of vista weirdness and continued on (using Winforms apps instead of console apps whenever I wanted to create a quick test). Today, however, I discovered that I could no longer create Web Service Applications as they crashed with a very similar error, and with a presentation on setting up your development environment on Windows Vista looming, I decided that I had better get to the bottom of the problem.... and so I did.

 

It turned out to be the Guidance Automation Toolkit and Guidance Automation Extensions packages I recently installed that for some reason had done some damage to the Project Template System in Visual Studio. now I guess fair is fair, both of these packages are in beta, and there are some known issues around running them on Vista (unfortunately I was not aware of these issues at install time). One of the big issues with the Guidance Automation Extensions is around uninstalling it. You get so far, and then a dialog pops up, no title, no message, just an OK button, and it stops uninstalling. fortunately I found a blog post by one Greg Duncan on how to uninstall the Guidance Automation Extensions.

 

I can now happily create console and web service applications again, but more importantly stand up in front of the Victoria .Net SIG next tuesday and talk confidently about running Visual Studio 2005 on Vista.

Tuesday, June 05, 2007

Speaking at Victoria .Net SIG

Just a quick note to say that I'll be speaking at the next Victoria.Net SIG meeting on the 12th of June at Microsoft building, Level 5, 4 Freshwater Place, Southbank. Turn up for Pizza and soft drink at 5:30 pm.

 

The topic of my discussion will be setting up your development environment on Windows Vista. Hope to see you there.