The project I am working on right now is a software factory that will eventually allow it's users to build software that controls robots and other devices in a laboratory.
Today I wrote a service that monitors the power on the machine it's running. The idea is the service will raise an event if the machine loses power, and will then monitor the remaining life of the UPS. This will allow the system to save any data to disk before the UPS gives up the ghost.
To write this I used a class that is new to .NET 2.0 called PowerStatus. This is a very useful little class.
First of all you can check various useful properties relating to your machines power supply. 
Also you can handle the PowerLineStatusChanged event which will fire when the Power State changes. In this event you can tell if the Power is connected or not and if the computer is about to resume or suspend.
There is a great code example and sample application here.
For weeks now, there has been a buzz about a big announcement at the Mix '07 conference. Well, in his keynote, Ray Ozzie made the following announcements:
Expression Studio is shipping today - See here for the details. One of the interesting elements of Expression Studio is that it includes the standard edition of Visual Studio 2005. As I mentioned in my last post, I haven't seen the developer experience for Silverlight. Hopefully with this will be at least similar to what developers already expect.
Silverlight Streaming - A companion service to Silverlight. The idea is to allow Silverlight applications to be posted to a set of Microsoft servers in the cloud. From this cloud, the applications can then be delivered to client browsers through your web site. First I've heard of this, so if I misunderstood this 'third part' of the Microsoft strategy, I'll correct it later.
Scott Guthrie announce that Silverlight includes a cross-platform .NET Framework. As of 20 minutes ago, there was a preview for this functionality that was available on the web. While it is a Beta version, it does have a "Go Live" license.
Silverlight can be downloaded from here. The SDK can be found here.
More to come
I'm hoping that someone reads this post and corrects me. But I'm not holding out much hope.
I don't normally use TableAdapters, but for a small application I decided that they seem like a reasonable choice. And so long as I was using them on my development platform, all was well and good. The problem arose when I delivered the application.
Like any good developer, I store the connection string to the data store in the configuration file. Which is what I did for this application. When I defined the TableAdapters, I pointed the connection string property to the same setting. Or so I thought. But what actually happened was that the connection string was actually stored in the DLL that contained the adapters. Hard-coded. As in not modifiable through the config files. And, naturally, this wasn't discovered until deployment.
So I started to look for ways to have the TableAdapter pull the connection string from the config files. I figured that this would be a fairly common scenario, so it should be address. Not so much
Apparently there is no way to automatically have TableAdapters use config settings. The "solution" is to use the fact that TableAdapters are partial classes to create a write-only ConnectionString property. It looks like the following:
public partial class FormTableAdapter
{
public string ConnectionString
{
set
{
System.Data.SqlClient.SqlConnection conn = new
System.Data.SqlClient.SqlConnection();
conn.ConnectionString = value;
this.Connection = conn;
}
}
}
}
Then, where the adapter is instantiated in your code, you set the ConnectionString property to the value from the config file.
To me, this is unacceptable. I was already a little skeptical of TableAdapters (I don't like the DataSet and the data access code in the same assembly), but this takes the cake. It almost seems like they were designed to not allow a reasonable deployment model. Maybe it will get better in the next version, but until then, I'm sticking with DataAdapters.
There has been a lot of nothing coming out of Microsoft over the last couple of months. I mostly noticed it at the MVP Summit in March, where the level of NDA content (for C# people anyway was non-existent) and I got a lot of 'you should come to Mix' tossed in.
So I am going to Mix '07, and for a taste of the sort of announcement that should be commonplace, check out this post from Mary Jo Foley about a "Dynamic Language Runtime" for .NET. It even includes a quote from an old colleague of mine, John Lam, who knows a thing or two (or a thousand) about dynamic languages and Microsoft.
And I'm pretty certain this won't be the only groundbreaking announcement that comes out.
This coming Saturday (April 28th), I'm going to be doing my Extending the ObjectDataSource talk at the Calgary Code Camp. While this isn't the first time I've spoken in Calgary (I did an MSDN User Group Tour there a couple of years ago), it has certainly been a while. I'm looking forward to participating as well as connecting with some people I haven't seen in a while. If you are in the area, you should seriously think about attending. Code Camps are a lot of fun and the price (free) enhances the value even more. You can find out more about the sessions and register at http://www.calgarycodecamp.com
Microsoft has just released (here) a moderately detailed description of where Team Systems is going over the next 12 months or so. The roadmap also includes the beginnings of the functionality that will be found in the next version of VSTS (code named Rosario). Nothing like a little transparency to get people salivating. :)
Although the publication date was slipped slightly (and there was conflicting information coming from some of the vendors), the training kit for the Distributed Applications PRO certification (70-549
) is now available. Of the three training kits I was involved in, this is the one where I thought the material would be most useful beyond studying to pass the certification test. The concepts and issues associated with distributed applications are commonplace and the book provides a nice consolidation of the latest thoughts on how to address the problems. I am curious about how people find the book, so if you have any feedback, I would love to hear it.
The second annual Toronto Code Camp took place this past Saturday. By all accounts, it was a tremendous success with over 250 people giving their Saturday over to many things technical. I gave a presentation on extending the ObjectDataSource control, and while you should be able to get the slides and demo code from the Toronto Code Camp site shortly, I thought I'd post them here as well, just to get it out as quickly as possible.
Slide Deck - Extending the ObjectDataSource
Demo Code - Extending the ObjectDataSource Demo Code
I just finished attending ObjectSharp's SMART (Software MAnagement Round Table) session on the impact of quality assurance on the development process and had a couple of observations to share.
First off, the biggest takeaway from the session is the need to move quality to the front of the development process. In this way, quality is a lot like security. There is no way to create a really secure application by adding security features at the end of the development cycle. In the same way, there is no magic powder that can be sprinkled on a completed application to greatly improve its quality. The overall quality of an application is found in its architectural choices, whether it was designed to be testable and the approach taken by the development staff with regards to testing.
However, one of the conversations I had with an attendee regarding Visual Studio Team Systems was just as interesting. He had just installed Team Foundation Server and had created a team project using the default Agile template. The team project he created was going to be for a working application. I found this approach interesting, not the least because (by his own admission) there was no "process" for developing software currently in play.
The interesting aspect (for me) was the supposed lack of software development process in his company. I would strongly suggest that there really was a process in place. Even though you might not think a process is in place with your development team, doesn't mean that a process doesn't exist. In any kind of team development environment, processes will form. It's just a question of how formal the process is. So your 'lack of process' (call it an unprocess) is really just a lack of documentation and formalization. Because of its lack of formality, unprocesses frequently operate below the radar of even the people involved.
If you haven't worked with Team Systems before, let me preface my comments by saying that it absolutely introduces structure to the development process. If you plan on using it 'out of the box' with no customization, you will need to use the process described by one of the canned templates. For those who don't currently have a process, the Agile template is the most likely starting point. But the Agile template includes process. There is a workflow for tasks. There is a workflow for defects. And workflow equals process.
I can appreciate the idea behind starting out with the canned templates. Its presence would indicate that it's a process with proven success. And using the product as it arrives is a first, small 'baby step' into the world of development process. The problem is that the first step you're taking isn't a small one. Instead, you have taken a giant step into the world of Agile development. Complete with all of the process that is codified in the Agile template. And Agile has more process than most people think. The result is that the first 'baby' step can be a killer for Team Systems.
If someone new to a development process truly wants to take baby steps with TFS, they should start by thinking about the unprocess which is currently being used in their organization. Spend a day or even a few hours talking to someone who is familiar with development methodologies, to identify the flows that are currently at play. The default template should be customized to follow this unprocess. Then, over time, the structure originally defined by the Agile template can be added back in, if needed.
Does this require a little more effort on your part? Yes. But the steps involved in modifying the template are both well documented and fairly easy to follow. By taking this approach, you truly can learn Team Systems by taking baby steps. And this is a lot less painful than trying to make the leap from unprocess to Agile.
Have you been looking for Ndoc or the cool document generator that was available for C# in VS 2003. They no longer seem to exist, I'm not sure what the whole story is behind the scenes, but I have come across a nice tool that works in their place.
It's called SandCastle. I checked it out and it worked very well, creating some really nice MSDN stlye documentation complete with C#, VB.net and Managed C++ samples. I tried out Eric Woodruffs GUI which was easy to use especially if you've ever used Ndoc.
Give it a try I think you will be impressed with the outcome.