I've worked on two different source control methodologies in my brief software career, the SourceSafe exclusive checkout way, and the Vault - edit, merge, commit route.

I've used three applications, Microsoft SourceSafe 6.0, SourceGear Vault (3.5) and currently Microsoft SourceSafe 2005.

They methodologies both have their benefits, clearly the SourceSafe way gives security, you know no-one else is going to be editing your code, and there will be no horrible merge when you check-in. But the major (and personally I think it's a deal-breaker) drawback is that when working in a team of developers you can very easily get into a deadlock situation where developer A needs access to FileB (which developer B has checked out) and developer B needs access to FileA (which developer A has checked out). The usual result of this situation is an 'undo check-out' by one of the developers, or them going 'renegade' and disconnecting from the source control (which will result in a merge).

I recently encountered the deadlock situation above, rolled back my file, waited for the other developer to check-in his changes and then went to reapply mine - problem was - I'd forgotten what I'd done, I'd taken a copy of my original edited version, but suddenly realised - if I just check in my change - I'll just overwrite the other developers code - which led to a large amount of reading the history of the file to try to reapply his changes - to cut a long story short - not a good method!

The Vault route allows you to just do your work, deadlock doesn't occur and this is exactly what we want. Both of us can have the code checked out and the last one checking in has to do a merge. The automatic merge tools are brilliant these days, and if they can't do it, then manual is the way - again, good tools can help this immensely. Vault is the only program I've used to do this and I can't help but praise it, if I ever (again :)) make the source control decision, I'll be heading straight to Vault!

With the advantages there, why don't more people do the edit/merge/commit source control? Fear seems to be one of the biggest stoppers - questions always arise: What about merging? That *always* goes wrong! To be fair, SourceSafe hasn't made merging easy, and I have yet to use CVS etc so I can't comment on those tools, but having a good tool makes this just not a problem.

I decided to make more time to read books relevant to my job - and what is also essentially my hobby. I've always approached the act of reading technical books as a chore, something I should do - but don't want to. But I think in the last year or two I've changed in a subtle way meaning that I now really want to learn to be a better developer.

I guess when I first entered the heady world of work - firstly I was happy to even have a position - and secondly I was learning so much at the time I didn't have time to sit back and read technical books - or rather - I chose to read more broad science books instead. I did read the odd computer book - Hackers and Painters was one I enjoyed reading, and obviously my collection of various O'Reilly books on C#, ASP.NET etc. But I haven't looked for the more seminal texts, Code Complete, The Mythical Man-Month and the like. I've decided to start working my way through Jeff Atwood's list of books to read, then maybe I can add some of my own :)

I decided to change all that and last weekend finally ordered myself a copy of The Mythical Man-Month from Amazon. It arrived yesterday, and I've found myself reading it as much as I can, and amazingly (for a book published in 1975) relating to it!

I can see the mistakes that I've made in the past, and those of management highlighted in all their details. The actual 'Mythical Man-Month' essay of the title is something I've definitely heard happen in my current place of work (the addition of extra people to a delayed project being a baaad thing). You can try and tell 'em but they don't listen!

Anyways - it's a book I would recommend just based on what I've currently read (and that's only the first 5 essays). If you're a developer, you owe it to yourself to read it! (By the way - if you do read it, it's probably good to learn a bit about the OS/360 system first!).

Caching

Important stuff this, caching makes the pages load faster for the user, and that's a good thing - most users leave sites (they're visiting for the first time) if the load time is longer than 2 seconds (I think, I read it somewhere - will hunt it out). We don't want people leaving before they've seen the wonders of chrisweb do we!!

We learnt about the 2 main places to do the caching - data caching (the back end stuff) and output caching (when the page is cached).

Using the Cache class is where we get into the data caching, basically assigning data into an indexed Cache - looks a bit like it acts as a Dictionary does. We also learnt that we can set the cache to expire etc whenever we like via the 'Cache.Insert' method.

The next step was the use of the SqlCacheDependency class for connecting to SQL2000 and 2005 databases, notifications of changes etc.

Onwards to the output caching (a rollercoaster of caching fun!), this prevents pages being dynamically created on every request if nothing is changing (or at least parts of a page). This is set up using the OutputCache tag on the page, and setting the corresponding elements up correctly. We learnt how this populates an instance of the HttpCachePolicy class and how that is accessible.

We saw how you can define the location of the cache, and how it's possible to cache multiple versions of a page based on the VaryByParam element, and how Page fragment caching can be done via user controls, or substitution

Diagnostics and Error Handling

Two major topics - one day?? Tough work - specially on the last day! Anyways - on with the handling!

3 Major topics in this:

• Tracing,
• WebEvents
• Error handling

Tracing - generating loads of information about how a page is accessed etc.

We covered how to generate the auto trace stuff, and how to write our own custom output. How to generate it on an application level (via the... yes - you guessed it, web.config) and even how to write to the System.Diagnostics.Trace output!

The next step through our diagnostics wonderland was the health monitoring framework - lots of providers to write to different locations - event logs etc.

Which nicely put us into the WebEvents territory - how to create and raise events, the (by now standard) configuration changes needed etc.

Then onto error handling! Setting up custom error pages, how to handle exceptions (Application_Error) and how to save that info when it happens.

Then it was all finished.

AJAX

This was briefly covered as we had some time left over after the previous two topics, and felt it was worth a quick view - and I mean quick. I think it was mainly an explanation of what AJAX actually is and does - which is worth knowing :)

I won't go into this one in detail as we didn't really cover it and it's an 'extra' topic, not a standard curriculum lecture.

Conclusions for the course?

Personally the course was useful - I was lucky enough to be attending it as I'd won it at a conference (DevWeek 2007) that I'd attended earlier in the year - so effectively didn't have any money invested into the outcome.

I think it gave a good overview of the technology - and in some respects (as I mentioned earlier) I think that's all you can really expect. In the next month or so I will be (hopefully) using ASP.NET a lot more as I move jobs from my current WinForms based one towards a more ASP.NET orientated position, and this will reinforce my skills (actually it's one of the reasons I took the course).

I think I now know (more or less) where to actually look for the stuff I would need to do the things I want to do - and that's the real benefit. I can go an look up stuff online, or in books where as before I would have had to just 'browse'.

All in all - a good course setting me up nicely for my next role!

Day 4 and the daily route of Shoreham-by-sea to London was briefly interrupted when I wangled a night in London with one of my old school mates - thanks FaceBook!

Right then, onto the day's topics, 2 UI style sections, and one about state, UI being one of my best topics - I was looking forward to this day!

Master pages and Themes

Who, what, where, why?? Ok, we only answered the what and why aspects, but basically learned that the master pages and themes are basically there to provide consistency on the site - so you don't end up with different pages looking significantly different to each other. This is a good thing, and I'll be honest, I had messed around with master pages before - and loved 'em.

The master page basically provides a 'template' for the content on a page, the theme providing the look. So if on every page you want a 'ChrisControl' in the top left hand side - you'd put it on the master page.

We learned how to write, use and play with the master pages - pretty easy stuff, once you've got the hang of a basic site (which by now you'd hope to have).

The next step were themes - I hadn't touched these - in fact, I'd used the master page as a kind of theme myself (naughty). A theme consists of .css files, .skin files and the resources (pictures etc). This riled some members of the class, .skin being seen as an MS rewrite of css, which was described as 'typical', 'bad' etc, with lots of shaking of heads.

Whilst I can sort of see what they're coming from, I think they didn't really read some of the stuff .skin files can do - particularly the use of SkinID's. I never know - not having really done css I can't really comment, but I can't see how they can't be complementary.

Anyways - that was about it for this topic, then again it didn't need to be much more!

Navigation

This was an introduction to the navigation model of ASP.NET 2.0, which standardises the navigation on a site, and in a nice way. The navigation is stored as an xml file (web.sitemap) and displayed using a provider (SiteMapProvider) and controls (SiteMapPath etc).

The controls provide (as expected now) a good level of customisation via the templates (still think it's a great idea!).

The next section (after detailing some of the controls) stepped into the use of security trimming in the SiteMap - firstly setting it (in your friend and mine - web.config) and then extending the .sitemap file to have custom attributes for things like 'loggedIn' etc.

The next step was defining a custom provider - presumably this is for those uber-cool sites with truly amazing menu designs :)

Client State

Client state concerned itself with the various ways to store state on behalf of the clients. Basically this is how a client can keep track of it's motions etc through a site - i.e. so when you press 'checkout' it doesn't automatically lose all the goods in your basket onto the floor. To that end we covered the two beasts:

• Session based
• Profile based

We went through how to use the Session class in ASP.NET and some of the pitfalls (memory usage etc), and how to configure it for use. Basically a list of how to set it up and how we can persist the user data (state servers), and onto the obligatory SessionStateStoreProviderBaser (provider :)).

Then come the Profiles - persisted, per-user data, best of all - this is customised data, it's not restricted to a previously defined idea of what a profile should be.

We learnt how to define the configuration (hello web.config) and then use the Profile class to read and save the data accordingly (and delete if need be).

Day over!

Another successful day, I really liked the navigation and themes stuff. I'd often wondered how people had written the 'breadcrumbs' stuff, and assumed it was hard labour - now we know!

This stuff wasn't overly complicated, and didn't have the 'wash over' effect of yesterday - I can see how this is used almost immediately, and I think it'll take minimal effort to remember it - (famous last words).

Validation

This is the ability to validate a page (input fields etc) from both the client and the server side. Validation is important to prevent XSS (cross site-scripting), SQL injection etc, and to make sure the user isn't being a doofus :)

The validation topic mainly covered the use of all the Validation controls available in ASP.NET, the:

• RequiredFieldValidator,
• CompareValidator,
• RangeValidator,
• RegularExpressionValidator and
• CustomValidator controls,

and the ValidationSummary control to display the results.

A quick recap of the event sequence brought us to the 'how is validation done on the server side' portion of the lecture, covering the Page.IsValid property and the IValidator interface.

The next step was the use of validation groups - useful with lots of parts on a given page. Then, errr, that was that. Done.

Data Binding

As I mentioned before - this is a big one - quite important, and one of the bits I had had issues with. I didn't exactly struggle with it, I just wasn't sure I was doing it the right way - which is actually part of the struggle - you can be taught how to do things one way, but in practical terms you end up doing it a different way. For example - I was taught how to program at university, but I learnt how to do it practically at work.

Anyhews, back onto topic, binding data to a given control (in our case, the ubiquitous GridView and List), was nice and easy (not quite up there with WPF and Expression Blend :)). It's really about knowing what can be a data source, and then which properties accept those sources.

After being shown the basics of binding, we delved into the world of templates, which I was personally very impressed with - templates are ace! This was exactly the sort of stuff I was looking for when I was playing around with the out of office system, and it was there all the time!

The next step (whew!) was the data source controls - SqlDataSource - pretty much what it says on the tin, and then the ObjectDataSource, again a ronseal type class - but a very cool one, allowing you to use your business objects for binding.

To go with the SqlDataSource were the parameters, then updating the data itself, back to the parameters for inserting etc.

The ObjectDataSource then comes into the foray, bringing with it more flexibility and other niceness! This section was essentially the equivalent of the SqlDataSource, but (obviously) from the ObjectDataSource point of view.

Conflict detection was next on the hit list, closely followed by the data object parameter and then editable templates.

Cripes, that's that lot done! Onto....

Security

You'd expect a large chunk of time to be devoted to the all important security section of the course - and you'd be right, admittedly it doesn't cover all aspects - how could it? For starters we're only really looking at ASP.NET, not the security configuration of IIS or your firewalls etc!

There are 3 main objectives of the security section:

1. Explore the basic ASP.NET security features;
1. Accessing authenticated client information
2. Controlling client authentication and authorization
2. Describing forms-based authentication
1. Building our own authentication system
2. Using roles
3. Storing passwords safely
3. Looking at the Membership and Role providers

So, onwards!

Part 1 - this mainly covered the use of the IPrincipal and IIdentity interfaces, and how the security is configured in the web.config file (along with everything else!).

We saw how to setup the web.config file to allow clients access to given pages, using the 'authorization' element, and the hierarchy and how that works.

The next step was to look at Windows Authentication - i.e. active directory stuff - a lot of this seems to require IIS being setup correctly, to provide the authenticated / not authenticated stuff to the site.

Part 2 - Forms!

The stuff of dreams, provided your dreams are about ASP.NET forms authentication. This covered how the use of forms as an authentication mode was set up (yes, that web.config file again!), and the various niceties that gives us (auto redirection to the login page for example).

The FormsAuthentication class then made an appearance for the hashing of passwords for checking against, well, I guess whatever backend you have (though tradition says this should really be a database).

The MembershipProvider then shows up - this does use SqlServer / Express for the backend - setting it up using aspnet_regsql. The MembershipProvider wraps up a lot of what would be hard graft into a nice simple to use API. The really nice things were the implicit usage of the MembershipProvider by some controls:

• Login
• LoginView
• PasswordRecovery
• etc

The next step was into the roles side of things, bringing in the RolesProvider, again uses the SqlServer / Express backends - and really works with the MembershipProvider.

Conclusions

Day 3 was a long-un, lots to get the head around - and that's a good thing. The day goes quickly when you're stimulated by the environment, and that's pretty much what this did.

These are probably some of the more important topics to cover, and to be honest I feel I don't really know them that well. I guess when they are put into practice it will become clearer and easier to get to grips with, and hopefully as second nature to me as developing WinForms currently is.

Just a quicky really -  yesterday, I was cleaning up some folders and did my usual deletion technique of SHIFT+DEL, permanently erasing my files, after all - I know what I want to get rid of, I don't need a recycle bin!

But, accidentally, I manage to delete the root work directory, I don't know how exactly - I'm still puzzled by this, needless to say - it wasn't my intention.

I work on my local machine, choosing to eschew the server based development for a number of reasons, (the main one being that I have 2 screens, and that doesn't work so well over remote desktop), and this leads to one issue - backups.

With source control, it's not so much of a problem, worst-case scenario - I end up rewriting the bug fix, feature - sure - a pain, but it could be worse, but a lot of the stuff I deleted were those little projects, you know the type - quick ones to test out a bit of code for example - and they weren't source controlled.

Gah! I didn't really want / need to lose them - ahh but what's this? A 'Restore' option when I right-click on the folder? Yes - I'd forgotten, I'd backed up the entire of my work folders, could it work?

...Begin restore...

...2 Hours later...

It's there! Yes! Thank you vista!

I know that this isn't a 'vista' thing, and that had I implemented a backup solution with a third party I would have been just as ok, but this was quick easy and a huge relief.

As a side note - 5 minutes to delete all the files - 2 hours to recover? What's that about???

Configuration

This is something I confess I should have known a bit more about than I did, it's not *massively* different to the WinForms version. However, as it happens I hadn't ever really used the .Config files, so learning from (almost) scratch it was.

Brilliantly easy is all I could really say - the configuration API makes it a doddle to get stuff in / out of the config. The structure makes sense and the hierarchy is good too.

The fact that you can do config for a given page, or even a sub dir is great stuff. But, onto how the course taught it, basically - started with a basic config file, extended it to show the hierarchy, and then progressed onto how to read and update the data.

We next worked into the Custom config sections, which are pretty cool in themselves, allowing us to write custom sections defined how we want, and how to write the classes to handle it.

The final part of the config lecture was about protecting the config - important if you're storing the connection strings etc!

Overall this was a good lesson - good coverage of what was needed, and showed us how to do basic stuff, but open to reading in more complicated things.

Custom Controls

It must be noted that this is the first of two parts on Custom Controls (though having said that - we never got to the second part - which was classed as a 'if-we-get-there type lesson). I had messed around with custom controls on my "out of office" web site I was working on.

Basically the lesson covered the architecture of the controls on ASP.NET and then onto how to build and use the controls.

We began with a coverage of the Page, viewing it as a control though, instead of the previous overview-y way - explaining what constitutes a Page etc. We next entered the realms of creating custom controls - again - something I've done in the past - in WinForms and briefly in WebForms. The curious thing here was how much time was spent doing it by code, rather than with the designer. I can understand this for the first one or two, but for any complicated control surely it's easier to design it via the IDE - it's a pretty good IDE for doing that!

We covered adding in specific configuration for controls, and how to deal with it, then we covered how to use the ViewState etc.

To be honest a lot of what followed pretty much mirrored WinForms controls - creating composite controls etc adding events and properties. Basically if you can do that, you can do the WebForms equivalent.

This was a good topic for beginning control design, and pretty much applicable to WinForms and WebForms, (I guess with different base classes) but if you're using the IDE it's a pretty similar affair.

So, it's been 2 weeks since I attended the above course in London and said that I would go over it in a bit more depth. I'm at a loose end at the moment and think I'll get right on to it.

Overview.

Firstly, the course is a 5 day course up in sunny/rainy London (cross out for your own experience) run by Developmentor UK (www.develop.com/uk). Ok, the course itself is actually run in the US as well in a variety of locations, and I assume the course is pretty much the same.

The instructor for my week was Niels Berglund, and there were oooh, 12 of us in the class, so not too full. A wide range of abilities there, from those with no C# experience, those who'd develop (and do still) in ASP.NET 1.x and ASP (old skool) and people who'd had little or no ASP.NET experience whatsoever (me). It also stuck with the traditional 'computer' demographic of one female in the group :)

The course is run in a kind of 'university' (or at least my uni) way - albeit in a more compressed fashion - a lecture on a particular topic, followed by a lab session. With the lectures lasting anywhere up to 2 hours, and the labs usually 1 hour.

Architecture.

The first topic is all about the Architecture of ASP.NET, a good place to start - it's always important to learn how the things you're doing work, not just how to make them work.

The information covered in this section was a basic overview of how the interweb works with basic pages, inspecting request / response information etc. Then we expand into dynamic content - which for use is ASP.NET.

A discussion on how the ASP.NET runtime works with IIS (which is handy) - discussing the handler aspect of it etc. Even showing how to write our own Handler (using the IHttpHandler interface).

We then covered the HttpApplication events, BeginRequest etc, and the order they're fired in. Things I've come across with my limited experience of ASP.NET, and good to know the order. Kind of like the Form events I guess, generally made sense.

Next was the usual (and expected) 'Hello World' ASP.NET page :) followed with a discussion over code-behind pages etc, classes, inheritance - stuff you really ought to know before developing pages - of most interest in here was how to use the 'Inherits' tag in the <@ Page> element, which proved useful when converting the default demo aspx pages into code behind pages.

A brief coverage of precompilation and the deployment structure of a site followed and ended the topic. To be honest, I never really thought of the precompilation aspect, whenever I've 'developed' a site, I've always done my usual WinForms technique of SHIFT+CTRL+B, precompiling be default.

Lunch

Sandwiches

Web Forms

The building blocks of ASP.NET, the equivalent to the aptly named 'WinForms'. Basically this topic covered things like the page lifecycle, (events etc), in more detail than before. Basic event handling (again not above how WinForms do it, but with that crazy 'AutoEventHandle' thingy.

Web controls were covered briefly - but then this was the Forms topic, not the controls topic (which was to come later), how to += to the control events - exactly the same as WinForms (ace).

The next area was the ViewState. An area scary to the WinForms developer, an unknown, a there-is-no-equivalent-in-WinForms object...  Topics like disabling the ViewState and even enabling it.

That pretty much covered the WebForms topic, not a huge topic, and a lot of it I sorta knew from my practicing (except ViewState stuff), as they most closely link to the WinForms I'm used to.

The Day Overall?

Fairly slow to be honest, and I guess it's important to be honest about how the day went. I think a lot of the slowness stemmed from the fact that I had messed around with these things before, and from my perspective we were covering the beginning stuff for everyone to get up to a similar standard.

The lab work was pretty easy - again - probably down to my limited experience, and the fairly easy concepts introduced.

How often do you use public readonly members? Throughout my own code, I rarely use them, generally just using a private member, providing a property to access it if needed. But in work I use them quite a lot - any member that is only instantiated in the constructor gets readonly status.

This is a sort of 'standard' for the coding here, though I'm not 100% sure it's the best solution. The argument goes that instead of using properties, using readonly members can look like a public getter, for example:

class TheIntyClass {
    public readonly int TheInt;

    public TheIntyClass(int theInt){
         TheInt = theInt;
    }
}

So if we're using the class we can just do:

Console.WriteLine("The int is: " + TheIntyClass.TheInt);

Personally, I don't like this as much as using a property - the main reason being that in my opinion this goes against one of the concepts of OO development - Encapsulation - Data Hiding. This essentially provides direct access to the underlying data, which from my understanding isn't ideal. If I change 'TheInt' to actually be a string:

public readonly string MyInt;

Then I now need to rename the member, add a public getter and make sure the name is the same.

private readonly string myInt;

public int MyInt { get { return (int) myInt; } }

Sure - this isn't a big problem with new refactoring tools (VS2005, Resharper etc), but just feels wrong.

Another side reason I dislike the public readonly member is that when using intellisense the member has the member icon (as expected), whereas the property has a property icon. :)

I want to make it clear that I don't have a problem with readonly itself - I find it has it's uses and it's important to have it.

Oh yes, two posts, one day, exciting for all you readers out there (hello Steve), so what has happened you ask? Well, Security has happened. Oh yes, Forms based, Windows based, None based. We even briefly covered Passport authentication, (when I say briefly I mean that it was mentioned that Passport auth existed).

I have to say - I'm pretty impressed with the Forms authentication we've (mostly) delved into, it seems pretty powerful - and (fortunately) pretty easy to get into...

I'll probably write about all the topics a bit later on, saying where it went right, wrong etc etc but wanted to dazzle you all (again, a quick nod to Steve), with two posts..

Put a spork in me, I'm done.

Welp, Day 3, and yes things are speeding up nicely, already done and dusted with Validation ( a nice easy topic ) we're onto Data Binding, a big'un. It's good though - these are the issues I had when I started writing my ASP.NET version of the internal Out of Office system. How to view only specific columns etc.

I managed to cope with this in my OOO page by using some controls the company had bought (XCeed UltraGrid (I think)), which gave me an easier and more intuitive (from a WinForms point of view) API. I've always found the DataGrid controls to be unwieldy, but now I'm slightly (emphasis on the slightly) coming around to them...

Next up is security - I'm interested in this a lot - hopefully it'll cover how to allow users to login and link to the Active Directory stuff... (Win authentication etc).. We'll see, fingers crossed etc..

What are my impressions of the course so far?
Well - the first two days were a bit slow to be honest, (a lot of it I had a existing knowledge of) - and our instructor has a nasty habit (though not recently) of going off on a tangent and getting 'lost'. I used to have uni lecturers like that... I didn't go to those courses on a regular basis :) As I said, it does seem to have improved today though... We'll see how tomorrow pans out!

Well, things picked up at the end of yesterday, resulting in a couple of 'lab' sessions - based on the Architecture and the Web Forms aspects. To be honest, the Web Forms is certainly the stuff that interests me the most...

I'm currently working on getting the labs stuff setup on this machine - which will give me more opportunity to practice - I have run into SQL Express issues though - just got the install - so fingers crossed I can get it working!

Anyhews, today has started with a 'review' period, (hour or so) and now we're onto 'Configuration' (Web.Config etc). Custom controls and Validation are next... Looking forwards to those - I've only tinkered with custom controls briefly...! Never validation!

So, here I am, at the essential ASP.NET 2.0 course run by developmentor. This is a course I won from the DevWeek conference I attended ooh, 4 months ago now... exciting stuff.

Why did I choose ASP.NET over say WPF, C# 3.0 etc? Well - basically I wanted to get experience in the 'other half' of .NET, the bit I feel I'm missing.

Anyhews, so far - Day 1, seems to be going ok, we're starting slowly with the architecture of ASP.NET - important I guess if you actually want to be able to code properly you gotta know the basics. It is a 'slow' bit, as there is little to no coding at the moment. Though I suspect this will increase soon!

More info later....

So, I've been teaching myself ASP.NET 2.0 in preparation for a course I'm attending in ooh, just over a week now, and it seems to have been going ok.

I used to shun ASP.NET - I'm sure there are other WinForms developers who do the same - assume that web development isn't really development at all. But I decided about a month or so ago to really try to get into it, and I have to say, I think I'm a changed man.

The problem I've always had with regard to web development is that it's never seemed proper in my eyes. WinForms leads to executables, fast code and well - compilation. It was unfair of me to be prejudiced against ASP.NET.

The last week or so I've been converting one of the internal applications used at the company (to book vacations etc) from a VB.NET - ClickOnce deployed WinForms app, to an ASP.NET site (for internal use only - obviously :)), and the experience has been pretty good, it hasn't proved to be that hard at all to get the site up and running - which I've been very pleased and excited about.

The biggest problem I currently face is trying to figure out how to layout the site. With WinForms - it's easy, anchoring, layout just a click and drag. But with WebForms, do we still use tables? I remember using tables when I did some old sites years ago. But equally I remember recently reading a site about using grids? Lines? Didn't there used to be a 'Layout' mode for VS2003 - did this get removed from VS2005? Hopefully someone can answer this, or better - the course will teach me all!