Michael Howard, co-author of Writing Secure Code*, has an excellent blog post on how static code analysis tools are only one weapon in your arsenal when writing secure code. I would highly recommend reading it. A quick summary… Unless you understand the threats, know how to architect secure applications, know how to write secure code, know how to test for security vulnerabilities, and then backstop it all with a static analysis tool, you’re doomed to write insecure code.


* Fantastic book. Everyone developing software, whether on the Microsoft platform or not, should read this book.

The INETA Community Launch Event is coming to Calgary on Wednesday, February 8, 2006 from 11am to 2pm at the Metropolitan Centre! The event is being co-hosted by the Calgary .NET User Group and the Alberta .NET User Group. This 3-hour session will feature two action-packed presentations.

Representing the Calgary .NET User Group, Daniel Carbajal and I will be presenting Building Cutting-Edge Web Solutions with Visual Studio 2005 and ASP.NET 2.0.

Jason Wingfield and Greg Lancaster of the AB.NET UG will be presenting Smart Client Application Development & Deployment.

You can sign up here. (After joining the user group, click on Events… CommLaunch… Add Attendee…) Hope to see you at the event!

Lutz Roeder just released Reflector 4.2. (For those of you who haven’t heard me blither about Reflector I’ll say it again… Reflector is one of the best .NET utilities available. It gets installed shortly after Visual Studio after I build a dev box.) Lutz lists off the list of fixes as “Web Proxy support, String search, Fonts, Generics fixes.” (No, I’m not paraphrasing. This is the complete change log.) You can get the latest by launching Reflector and then selecting Help… Check for Updates. You can also grab it from here.


WARNING!!! If you use any cool Reflector add-ins*, such as Diff, FileDisassembler, or SQL2005Browser, you’ll have to wait until the respective authors re-compile for Reflector 4.2 because they will fail to load. (Breaking changes were made to Reflector’s object model in Reflector 4.2.) Unfortunately you can’t roll back a Reflector upgrade unless you squirreled the old installer away somewhere (which of course I didn’t because I’ve been upgrading via Help… Check for Updates). Oh well. Some folks, such as Herve Chapalain, author of Reflector.CodeSearch, already have a version of their add-in that is compatible with Reflector 4.2.


* Lutz maintains a list of Reflector add-ins here. Reflector SDK for building add-ins can be found here.


UPDATE: Diff v0.75 was just recompiled to work with Reflector 4.2.

Enterprise Library for .NET Framework 2.0 just hit the download servers. It has gone through a major update for .NET 2.0. This isn’t a simple re-compile. For instance, Enterprise Library is a heavy user of configuration and had its own configuration mechanism. .NET 2.0 ships System.Configuration, which the new release leverages. So if you’re developing enterprise applications using .NET 2.0, this new release is a must-have.

The January 2006 CTP for the WinFX Runtime has just arrived and with it, a Go-Live license for both Windows Communication Foundation (aka WCF or Indigo) and Windows Workflow Foundation (aka WF). (Windows Presentation Foundation, aka WPF or Avalon, also ships in the WinFX CTP, but the bits are identical to the December 2005 CTP. Details here. No Go-Live for WPF yet.)

Community websites for the technologies have launched, which promise to be similar to ASP.NET and WindowsForms.net:

* The Windows Presentation Foundation website is currently a GoDaddy holding page, but the domain name is registered to Microsoft. So putting two and two together, expect to see a site launched in the coming months.
 
You can download the CTP and associated readme, SDK, and VS 2005 designers from these links:

If you’re ever troubleshooting an IIS-related problem, Microsoft offers a variety of free tools to help in your troubleshooting efforts. Previously you had to download the tools separately, but Microsoft just released the entire bundle as a single convenient download:

 



 

Also available for IA64 and AMD64.

 

Tools included in the bundle:

 


  • Authentication and Access Control Diagnostics 1.0
  • SSL Diagnostics 1.1
  • SMTP Diagnostics 1.0
  • Log Parser 2.2
  • Trace Diagnostics 1.0
  • WFetch 1.4
  • Debug Diagnostics 1.0
  • We’ve all had it happen. You’re running out of space on your precious C-drive and you start to madly uninstall unneeded programs. Sometimes you even resort to uninstalling programs from C:\Program Files just so you can move them to D:\Program Files. (Chris Sells mentioned doing this dance recently, which is why I’m writing this blog entry.) STOP THE INSANITY. You can save a ton of time by following these simple steps:



    1. Download Junction from sysinternals.com.
    2. On another hard drive, create a D:\Program Files or whatever you want to call the directory. The name doesn’t matter.
    3. Move C:\Program Files\AppThatIWantToMove to D:\Program Files\AppThatIWantToMove. Note that once you’ve done this, the program will no longer work properly (yet) because everything in your registry that makes file extensions, COM objects, etc. work is still pointing to the application at C:\Program Files\AppThatIWantToMove.
    4. Run the following command: junction “C:\Program Files\AppThatIWantToMove” “D:\Program Files\AppThatIWantToMove”

    5. Launch explorer and go to “C:\Program Files\AppThatIWantToMove”. The app appears to be on your C-drive again, but its actually stored on D-drive. Your application works just like it did before, but you’ve freed up space on your C-drive and you didn’t have to go through the uninstall/reinstall dance.

    What you’ve actually done is to create a junction that says, “Windows, when someone asks for something stored in C:\Program Files\AppThatIWantToMove, everything is actually stored over there on D:\Program Files\AppThatIWantToMove.) This is completely different from the shortcuts that you’re used to. If you create a shortcut on your Desktop to a directory such as C:\Foo\Bar, when you navigate the shortcut and then up one folder, you end up at C:\Foo, not back on your Desktop. If you were to create a junction, navigate the juction, and then up one folder, you would end up back on your Desktop. It’s as if the folder actually does exist on your Desktop, but is stored elsewhere.

     

    I use the same technique for keeping my Virtual PC images on an external hard drive, but making them appear to be in My Documents. (I find this handy because when I need to take a VPC on the road without my external HD, I simply delete the junction, copy the contents of the folder locally, and I’m in business.)

     

    Note that the only thing special about Junction is that it allows you to create junctions (aka symlinks). This feature is built into Windows/NTFS, but just not exposed to the end-user. You can even delete the sysinternals.com Junction application after you’ve moved your application.

     

    If you ever feel the burning need to move the application back to your C-drive, you can just reverse the process:


    1. Delete the junction using: junction -d “C:\Program Files\AppThatIWantToMove”

    2. Move D:\Program Files\AppThatIWantToMove back to C:\Program Files\AppThatIWantToMove.
    3. Everything is back to the way it was, including your C-Drive being overly full again.

    The Calgary .NET User Group will be hosting Joel Semuniuk, Regional Director, MVP, and VSTS Blackbelt* on Wednesday, January 25, 2006 from 5 to 8pm where he will be talking about… drum roll please… VSTS. (Bet you guessed that, didn’t you?) The event is generously being sponsored by Allstream. Pre-registration is required and available on the Calgary .NET User Group website. Hope to see you there!


    * OK, I made the last one up, but seriously, Joel is the most knowledgeable VSTS guy around outside Redmond.

    Rico Mariani, performance guru extraordinaire, turns out to be an amateur lyracist too. For all those geeks out there, here is Rico’s version of Bonnie Tyler’s Holding Out For A [Coding] Hero. (You can listen to a clip of the original version here, compliments of Amazon.) Enjoy!

    Back to talking about performance and .NET. Let me give you an example from my own experience regarding skepticism about whether you can write highly performant applications using managed code. The thought is that if it ain’t C++, it can’t be fast. (The same skepticism applies to Java, too.) I can attest first-hand that it is possible to write highly performant applications using .NET. For example, I was brought in to assist with the development of a server application that was written in C++ and having perf problems. The performance goal was 2000 concurrent clients on reasonable hardware. The alpha version in C++ was able to handle 200 concurrent clients and fell over (read the server crashed with out of memory errors) at 500. The team had spent approximately 3 months working on the C++ codebase writing it and trying to bring it up to par. They had never written server software before and had made a few honest mistakes such as firing up a thread per client (which resulted in running out of memory as stack space was allocated for each thread) and writing to the database while a remote connection was held open. (The problem with holding the connection open was that the clients were just dropping off information and didn’t require an ACK. So you’re holding open a TCP socket for an extra 50-100 ms during the synchronous database write and then closing it rather than freeing it up immediately.)


    The team believed that you could only write a highly performant server in C++. So they weren’t too keen when I suggested using C# and .NET. With the assistance of another developer, we created in two days a skunkworks prototype in C# that serviced clients using a thread pool and dropping the results into a queue (implemented with MSMQ) so that we didn’t have to roundtrip to the database on every connection. (The results were lazy-loaded into the database by a queue listener.) This allowed us to free up sockets quickly. The results… On the same hardware that was falling over at 500 clients with the C++ version, we did approximately 10,000 clients with little to no perf tuning. (We used the same client load generator in both cases for a fair comparison.)


    Why did we use C#? It wasn’t our intent to subvert their development standards. We just wanted to show that this alternate architecture could scale and the most expedient way to implement it was using .NET. When we showed them the managed version, their jaws dropped. When I suggested that we could spend a few weeks (literally!) writing the same thing in C++, the immediate question was “Why bother?” They had spent more time tracking down memory leaks and bad pointer arithmetic in their C++ codebase than we had spent implementing ours. We more than exceeded their performance goals and could implement new features faster. They didn’t look back and implemented a highly scalable server written ground-up in C# and .NET.


    Next time, we’ll look at the performance characteristics of different aspects of managed code…