I'll have to refactor our team's “Software Factory” custom framework generator. It originally built in support for object generation to support null for value types. We achieved this by storing bit values to correspond to the member fields. This allowed us to have an object's property like object.Length and determine if it was null by having corresponding properties test for nullability.
int? length = null ... will essentially define a nullable int by C#'s mapping of int? to Nullable generic.
The boxing handling for the Nullable types is pretty interesting but I want to do more digging under the covers and will repost some findings before I migrate our factory system from the 1.1 framework to 2.0.
For more cool 2.0 changes (reference), this post by Patrick lists some pretty good stuff.
http://www.codeproject.com/books/net2_cs2_newfeatures.asp
Okay, so I'm one of those GUI freaks that like using a GUI if it exists over the command-line. Lately, I simply use the ASP.NET IIS Snap-In to switch a particular ASP.Net application on a server to the proper .NET version. After installing the latest and greatest .NET 2.0, I still didn't see the snap-in. Argh... When searching the net, I found a pretty good post that describes how to resolve it. It says that the Beta 1 uninstall didn't clean up that well and thus some manual registry cleaning needed to be done.
Basically, you search for all instances of 40607 (the beta 1 build of .NET 2.0). When you find the keys, delete em. Also, you must nuke the following entry:
HKEY_CLASSES_ROOT\CLSID\{7D23CCC6-A390-406E-AB67-2F8B7558F6F6}
The forum post at asp.net says to reregister with aspnet_regiis -i. When installing the redistributable, I saw the command aspnet_regiis -iru run. The guys at Microsoft made sure the install didn't break existing ASP.Net (1.1) applications (which the switches -iru do for aspnet_regiis). Smart if you ask me. I can recall that the B1 didn't do that, and it raised concerns as I plan our 2.0 technology roadmap.
I love to write code. It is fun. However, a successful project isn't just about coding it. It is making sure that all cylinders are firing. It is making sure the orchestra is in tune.
One such way to assist in making sure you've got the bases covered is to you have all your risks covered and some kind of mitigation plan to lowering their impact on your project. As I'm studying my .NET Solutions Architectures, I decided to take one of our risk matrix templates and put some cool stuff in it. It was a little coding fun but it is very handy in using it to do your risk analysis. I've taken the formula for risk analysis and built cool features into this Excel document.
One thing I've noticed when entering the industry, searching for the right document templates to use when starting a project as a lead developer isn't that easy on the internet. So, I'm hoping someday someone new to the software lifecycles needing a hand may find my templates handy. I'll post others later.
Features of Risk Document:
- Incorporates basic formula for risk impact = probability of risk * risk factor
- Uses conditional formatting to highlight rows of top[n] risk where n is configurable.
Feel free to have at it. Click here to download. Password to unprotect is 'unprotect' if you want to customize it further.
Some of us are bleeding edge. Others, well let's say that the sight of blood makes them faint. As a software engineer, one shouldn't fear the edge and must walk on it every so often in order to bask in its amazing glory. The glory of being pioneers in technology. I'd like to help others dive in. The water is fine. The technology is cool. In this section, I'm going to cover building a very simple website. Those familiar with the HelloWorld type of examples, we will do an ASP.Net 2.0 hello world. First we'll need to create the website. First you select an ASP.Net website, then you must pick the language.
Once you get used to some of the new features and play around with your hello world app. You will then want to run it to test it. The default setup for the web applications (at time of the RC release) does not automatically configure the web.config file. Luckily, VS prompts you for it and creates it for you (see below...). 
One thing to notice is that it doesn't run in IIS. I haven't truly tested it, but I assume you won't even need IIS to develop a web application. I thought that was cool. If you think about it, you could in theory develop an application on the same IIS machine and not worry about IIS configuration conflicts. For those who have done ASP.Net development on shared machines know exactly what I am talking about. You'll know that the system is running its
own web server process when you see the icon in your system tray (see below...).
Does it compile? Does it run? Good. Now how to I do something simple as publishing it? With the 2003 version, you would deploy it to an directory via file share or front page extensions using the copy method. It is a little different in VS 2005. In fact, you may initially be a bit frustrated hunting for it. The copy in the new version is more of a synch file process in case you are transferring your files (including sources). To deploy the site, use the publish web site option by right clicking on the web project.
Using the publish options, you will see that there is a target location that is prescribed for you. If you select the ellipses "..." you will have additional options (see image below and subsequent image).
You have various mechanisms for deploying the site. You even have the option from the IDE to create the web application folder so that you do not have to perform the extra IIS administration task. (Note that running framework versions side-by-side will still require this.) 
If you try and attempt to navigate to the published location, you will probably get an error like so. With most initial ASP.Net 2.0 options, you should immediately verify what framework version is associated with the published location. If you are running frameworks side-by-side, you could be running in the context of the previous framework version. A utility most of us should know by know is aspnet_regiis. You can do this via the commandline to upgrade it to the respective version. (tip: keep scrolling...there is another way!) 
After installing .NET 2.0 you will notice something different about the IIS admin tabs on accessing web application properties. There is now a tab at the end that allows you to pick the respective framework version. As an alternative to aspnet_regiis, simply pick the target framework version.
Voila! Say hello to my little friend! ;)
As an application architect, I constantly want to make sure that the "construction work" is going just fine. As I go through checklists of requirements, I can verify if we have code coverage over the system components and design specifications completed. When I feel we don't, I have to dig in to the internals and perform code/feature reviews with engineers. Even if we do have complete coverage, as time permits, I'll review code and provide tips on how to be better engineers for some and learn from others. In either case, I use the code reviews and "comments" together as a method to ensure that the code reflects the algorithms and improve future maintainability of the system.
I've always stressed commenting and, regardless of what some programmers might say, feel that it is essential to proper development when used the right way. Used the wrong way, a developer may feel that it is just another thorn in your side. The following methods are two of my favorites ways of exploiting comments in software engineering:
Aiding the Test-Driven FrontierI'm a big fan of the test-driven approach. As I write my stubs, I provide complete documentation of the software unit that I am planning to build. Along with the documentation for the stub, I'll write the algorithm behind the scenes in pseudocoded comments. I typically end with a NotImplemented exception as we all know that we haven't finished implementation yet.
Talking Through a Code ReviewWhen I review code, it helps that the variables used make sense and that the algorithm is clear and concise. The code itself becomes self-documenting. In the case that it isn't, comments come to the rescue. When sitting with one of my developers, I'll first make one pass stating what I believe it is doing. The developer corrects me if I'm wrong, and once we agree on its algorithm we document each line. One should be able to rip out all the code, leave the comments, and still be able to rewrite it based on the algorithm as described by the new comments. With a fresh set of comments in-line, we then verify the correctness of the algorithm. The unit tests updated and the world is good!