Wow!  Wow, wow, wow!

I love code analysis tools.  FXCop was a dream come true.  While many developers cringe when they think about that tool, I tend to get a little excited.  FXCop was a great code analysis tool that helped me learn a lot about development best practices.  There are many little nuances to development and FXCop caught them all.  When Visual Studio 2005 Team Suite was release and FXCop was included under the name "Code Analysis", I was ecstatic to say the least.  This great little add on helped me learn all about globalization and naming conventions.  It also saved me from a memory leak or two.

Well today was another glorious day.  Microsoft has announced the release of a new developer tool called "Source Analysis".  This new tool is similar in a lot of ways to FXCop (or Code Analysis), however there are some important differences.  FXCop only performs analysis on compiled libraries - dlls or exes.  Source Analysis will analyze source code directly.  This means that while FXCop is focused primarily on design, the new tool will focus on layout, readability, and documentation. 

The ultimate goal of Source Analysis is to help you produce elegant, consistent code.  Any team member or developer will regard it as highly readable.  Out of the box, this new tool comes with about 200 predefined best practice rules and is fully compatible with Visual Studio 2005 and 2008.  The rule base includes:

After installation, Source Analysis integrates into the Visual Studio IDE and can also be integrated into MSBuild commands.  You can get your own copy of this great tool from MSDN free of charge!

Microsoft has finally released the much anticipated version 4.0 of the Enterprise Library.  Two of the biggest changes in this release are support for Visual Studio 2008 and the integration of the Unity dependency injection container, also dubbed the Unity Application Block.  You can download the new version from Microsoft Download Center, free of charge!

If you are a developer and are unfamiliar with the enterprise library, head over to the Enterprise Library home page and check it out.  Here is an excerpt from their site:

The patterns & practices Enterprise Library is a collection of reusable software components (application blocks) designed to assist software developers with common enterprise development challenges (such as logging, validation, data access, exception handling, and many others). Application blocks are a type of guidance; they are provided as source code plus documentation that can be used "as is," extended, or modified by developers to use on complex, enterprise-level line-of-business development projects.

As submitted to http://acanac.org/blogs/geek/

In my last post, I talked a little about how I overclocked my video card and gave a brief overview on the steps to do that.  In this post, I will attempt to explain the frustration I have endured trying to take that to a new level for all of the hardcore modders out there.  While testing my mods, especially the overclocks, it is important to keep an eye on system temperatures.  After all, if something in the PC gets too hot, it's probably done.  I often use 3rd party monitoring tools, like nVidia Monitor for things of that nature, however there are some pain points that one has to endure when using these tools.  For example, I have to alt-tab out of my game to check the temp while playing.  That's just a pain.  I've tired some other software, but I find that nothing has what I really want in it.  So, I set out to write my own.  I just happen to be a Microsoft Certified Application Developer.  Woot.  = )

The specific reason that I chose to write my own was that I have a Logitech G15 gaming keyboard that has the LCD on the front of it.  I wanted to display various pieces of system information there.  Things like GPU temperature, CPU temperature, hard drive temperature, system temperature, driver versions, and anything else that seemed useful while modding.  Something that can do this may exist, but the developer in me was just itching to do it.  I figured it couldn't be too hard.

I'm a C# guy, I can do most of the others, but C# is my comfort zone.  I tackled this project from a multitude of angles.  WMI looked like the best way to get at the information I wanted.  The obvious answer was the Win32_TemperatureProbe class.  It only took me two weeks to figure out that this class is not implemented yet - it's just there for future use.  I hit a bunch of other road blocks on my way to that discovery.  First and foremost, I had the pleasure of meeting the new User Access Control (UAC) in Vista.  Before I could even see what data WMI would return to me, I kept getting access denied messages.  Access system data, even if it doesn't actually exist, requires elevated privileges.  This MSDN post helped me understand how to tackle that problem.

As I mentioned before, that was just the start.  It seems that hardware manufacturers are inconsistent with what data they will allow you to access and how they make it available.  WMI does not appear to be the answer.  Many have APIs that you can tap into, but I had no luck with that at all.  nVidia offers a temperature API in their nVidia Control Panel library, but I was unable to get it to return any data.  No errors, but no information either. 

Don't let my complaining deter you, WMI does return a lot of useful information outside of the temperature.  Here is a sample of some of the stuff I can get from it:

NVIDIA GeForce 7800 GT
Ram:  256MB
Status:  Ok
Driver:  7.15.11.6932

I haven't given up entirely, but I have put it aside for the time being.  When I get some more ambition, I will tackle the temperature pieces again.  If I am successful, I'll make the application and source code available for download to anyone who is interested.  I'll keep you posted.

It's happened again.  I loaded up a solution in Visual Studio 2005 Professional Team Suite, only to find that I can't see the solution, only the project.  That means that I cannot add another project to the solution, nor can I change the properties of the solution.  This happened to me a long time ago and when it happened again, I couldn't remember how to fix it.  I was stumped.  So, I did what any self-decided geek would do - I started hunting through the options in search of a fix.

I went through tons of property windows and option screens.  I hunted far and wide.  I read through the help files.  I was totally stumped.  I had decided that I must have just missed it, and rather than going through it again, I turned to the Blue Fairy - Google.  After a few minutes I had found the answer on this site.  I was right, I had just missed it.  It was good to know that I am not alone though.

Seems as though it's not really that tough to fix. I've summarized the steps in the list below:

1. Open Visual Studio
2. Click on 'Tools'
3. Click on 'Options'
4. Select 'Projects and Solutions' on the left-hand side
5. Place a checkmark in the box next to 'Always show solution'

That's it.  It's just that simple.  It takes more time to figure out than it actually takes to complete.  With any luck, you are reading this and saving yourself from some serious frustration.  My thanks goes out to Raimond Brookman for saving me from further time and frustration.  I'm posting this info just to help the propagation efforts.  There is so much useless information on the internet, it's often hard to find the relevant and useful stuff.  Now you don't have any good reasons to not get back to work!  Happy coding!

As submitted to http://acanac.org/blogs/geek/

In my line of work, I would be classified as a hybrid to what Microsoft calls a Systems Architect and an Application Admin.  One of my jobs is to provide insight and input on solution architectures that our organization is planning to build.  As easy as this may seem to many of you, the process can be quite draining.  We have application architects on staff who are brilliant at what they do.  They design applications using patterns and practices that have been laid out by Microsoft.  They use the latest and greatest technologies and techniques to ensure that our applications are top notch and ahead of the curve.  There's only one problem.  They sometimes forget that all of our applications are hosted on a shared, n-tiered infrastructure.

When I first started in this area I was relatively naive.  It made sense to me that the shared piece was irrelevant.  Obviously if the applications are well architected, then they will function just fine in our infrastructure, right?  Wrong.  Even though our shared infrastructure is well designed and maintained, not every solution is going to be a good fit for it.  For starters, the infrastructure is of a 4-tier nature.  We have a web farm presentation tier, a server cluster application tier, and a completely separated database cluster data tier.  If the application uses a 3-tier design then the application service layer, where the business logic is processed, is executed in the presentation tier.  I can tell you first hand, that's not good.

You see, web servers and web farms are built to be scaled horizontally.  Whenever the load is too great on the presentation tier, we add more web servers to the farm.  We don't add more ram, or processing power, we simply add more servers to handle more connections.  However, when the application tier reaches capacity, we increase the ram and cpu power.  If necessary, we add another server to the cluster, creating the appearance of more ram and cpu power.  Due to the nature of the scalability of each farm,  we have created an optimal cost situation by isolating components of the application to servers that are designed to scale just for that component.

Don't get me wrong, I am not saying the 4-tier is the be all end all.  It's not for everyone.  It works for us, because we have an enterprise class deployment.  I am also a big fan of the 3-tier deployment, my only point is that you can't mix the two.  What happens is that an application eventually starts using more resources than the web server can provide.  We add another server and it doesn't help.  Why?  Easy, it's because web front ends are not supposed to do much, so we scale them horizontally.  Scaling them vertically wouldn't be cost effective. 

If you work in a .Net development shop as an architect, please try to remember that there are other areas of architecture that need to be consulted for each and every new solution.  Application Architecture, System Architecture, Security Architecture and Application Hosting (Administration).  You will be a lot better off and your solutions will implement with ease.

For some more information on the subject, check out the following Microsoft Patterns and Practices sites:

• Tiered Distribution
• Deployment Plan
• Deployment Patterns
• Enterprise Solutions Patterns Using .Net