Robert Hurlbut's Blog

Rick Samona has a webcast on MSDN TV discussing how developers can write secure code using the new enhancements in Visual Studio 2005. Take about 15-20 minutes of your time to learn (or refresh) the latest techniques.

I and several others in my area have been going through David Pallmann's Programming Indigo book on our own to understand how it all works as well as try to get answers in the tough spots. My friend Aaron Weiker had an idea a couple of months ago to start looking at Indigo in our Boston Code Brew group. Starting next week, we will officially begin an intense study of David's book. What that will mean is we'll have our laptops set up, we'll build services to communicate to other services we create, and we'll see how it all works and have some fun learning new stuff.

Is anyone else doing something similar in your own local area?

Richard Turner (Product Manager in Microsoft's Web Services Strategy team), has published the first of a series of papers that provides guidance on how to best use Microsoft Web service and distributed systems technologies in order to build distributed, service-oriented systems using today's platform.

The first paper, “Developing Distributed Services Today”, can be now found on MSDN, at this link, with more on the way very soon. [found via Paul Fallon]

This looks like a very good start and is recommended reading. This first article represents a high-level overview of the various distributed service options from Microsoft today, with a few key recommendations. Keep an eye on Richard's blog for the remaining articles in the series.

Paul Fallon posts some good news (and excellent description) about Enterprise Services in .NET 2.0. Systems.Transactions already features Transaction promotion and delegation using the concept of PSPE (Promotable Single Phase Enlistment), in particular with SQL Server 2005 which is the only current database RM (resource manager) that supports this. The good news is that Enterprise Services will also have this feature. That's great, especially if you already have existing ES code you want to recompile and  move forward. Go read Paul's post for more information.

On a slightly related note, I noticed recently through Reflector that Systems.Transactions references System.EnterpriseServices in its assembly (Systems.Transactions.dll). I know that S.T uses managed calls to MSDTC when a transaction has been promoted to a full distributed transaction, but I wonder if ES is still in the mix somehow as a ServicedComponent wrapper?

Take a look at this great article on unit testing by my friend Andrew Stopford and Jay Flowers:

   Unit Testing with NUnit, MbUnit and VSTS

With clear-cut information like this, there is no reason NOT to do unit testing.

For a slightly different change of pace for me, I will be speaking at the New England Visual Basic Professionals User Group meeting at the Microsoft offices in Waltham, MA on August 4, 2005. My topic will be Visual Basic 2005 Language Changes.  What's coming in the next version of Visual Basic.

I normally use and prefer C#, but I also typically find half of my contracts deal with VB.NET in some form or another. It's been interesting to see some of the language changes that are coming down the line in .NET 2.0.

Concurrency is a topic I have been interested in over the last year, but especially over the last six months with one of my consulting projects and research for my own planned writing on the topic. Vance Morrison, from the Microsoft CLR team, wrote a great article for August, 2005 edition of MSDN Magazine that I feel should be required reading for every developer.

[By way of Dana Epp]

Tonight Michael Howard ... told the world about a new book that he, David LeBlanc and John Viega have finished writing called "The 19 Deadly Sins of Software Security".

The book is carved up into 19 chapters, or Sins, and each is only 10-15pp long. The Sins are:

1. Buffer Overflows
2. Format String problems
3. SQL injection
4. Command injection
5. Failure to handle errors
6. Cross-site scripting
7. Failing to protect network traffic
8. Use of "magic" URLs and hidden forms
9. Improper use of SSL
10. Use of weak password-based systems
11. Failing to store and protect data
12. Information leakage
13. Improper file access
14. Integer range errors
15. Trusting network address information
16. Signal race conditions
17. Unauthenticated key exchange
18. Failing to use cryptographically strong random numbers
19. Poor usability

This looks to be very good, and I look forward to getting this. If you are wise (i.e. want to be proactive in developing secure code), you will too!