Fixing the Windows SDK is not installed correctly WCF Service Configuration Editor Error

I have seen a lot of posts about the error "Windows SDK is not installed correctly" when trying to open the WCF Service Configuration Editor in Visual Studio 2008.

To fix it... open the Windows SDK Configuration Tool from the start menu.


(Click image for larger view)

Then...
1. select the latest version installed
2. select the VS versions you want the SDK applied to.
3. click make current.

(Click image for larger view)

Enterprise Library 4.0 for Visual Studio 2008 released!

Microsoft's patterns and practices team has released Enterprise Library 4.0 for Visual Studio 2008.

Enterprise Library 4.0 – May 2008 contains the following application blocks:
Caching Application Block. Developers can use this application block to incorporate a cache in their applications. Pluggable cache providers are supported.
Cryptography Application Block. Developers can use this application block to incorporate hashing and symmetric encryption in their applications.
Data Access Application Block. Developers can use this application block to incorporate standard database functionality in their applications.
Exception Handling Application Block. Developers and policy makers can use this application block to create a consistent strategy for processing exceptions that occur throughout the architectural layers of enterprise applications.
Logging Application Block. Developers can use this application block to include standard logging functionality in their applications.
Policy Injection Application Block. Developers can use this application block to implement interception policies that can be used to streamline the implementation of common features, such as logging, caching, exception handling, and validation, across a system.
Security Application Block. Developers can use this application block to incorporate authorization and security caching functionality in their applications.
Unity Application Block. Developers can use this application block as a lightweight and extensible dependency injection container with support for constructor, property, and method call injection.
Validation Application Block. Developers can use this application block to create validation rules for business objects that can be used across different layers of their applications.
Enterprise Library also includes a set of core functions, including configuration, instrumentation, and object creation. These functions are used by all other application blocks.

From the help download:
Enterprise Library 4.0 – May 2008 is a new release of the Microsoft patterns and practices Enterprise Library. Enterprise Library consists of a collection of application blocks and a set of core features such as object generation and configuration mechanisms. All of these are reusable software components designed to assist developers with common enterprise development challenges. This release of the Enterprise Library includes one new application block, the Unity Application Block, which implements a framework that provides object generation and dependency injection capabilities, plus other new features and enhancements.

Benefits of Enterprise Library
Application blocks help address the common problems that developers face from one project to the next. Their design encapsulates the Microsoft recommended best practices for .NET applications; developers can add them to .NET applications quickly and easily. For example, the Data Access Application Block provides access to the most frequently used features of ADO.NET, exposing them through easily used classes. In some cases, application blocks also add related functionality not directly supported by the underlying class libraries.

Goals for Enterprise Library
Enterprise Library is a collection of application blocks and services intended for use by developers who build complex, enterprise-level applications. These applications are typically deployed widely and have interdependencies with other application and systems. In addition, they generally have strict security, reliability, and performance requirements.

The goals of Enterprise Library are the following:
Consistency. All Enterprise Library application blocks feature consistent design patterns and implementation approaches.
Extensibility. All application blocks include defined extensibility points that allow developers to customize the behavior of the application blocks by adding their own code.
Ease of use. Enterprise Library offers numerous usability improvements, including a graphical configuration tool, a simpler installation procedure, and clearer and more complete documentation and samples.
Integration. Enterprise Library application blocks are designed to work well together and are tested to make sure that they do. It is also possible to use the application blocks individually.
This section contains the following topics that will help you to understand this release of Enterprise Library and how you use it alongside earlier versions or migrate your applications to this version.

Get it here.

Living for Hope in Fear of the F Bomb

I remember years ago at one of the local consulting gigs I was on they held a weekly developer meeting. At the time, I was there temporarily in transition to another gig. The senior developers that worked for the company conducted random code reviews of the consultant's work. At the time there were about 5 company developers and probably about 7 or 8 consultants. We were working on multiple projects.

The first meeting I attended they started to list off the things they found wrong in the code. On about the 5th item, I asked if they were going to tell where that code was located so we could figure out who had been making the mistakes.

They said it was against their management style to embarrass people. No matter how hard I tried to convince them that if I didn't know I made a mistake, I would not be able to stop doing it, they refused to tell what code they were referring too. Every week they listed the same mistakes over and over again.

The F Bomb I am referring to is Failure. Most environments I have been in, failure is always reported as a perceived success. I find it so hard to comprehend never failing, because then you never get to the really important lessons learned. Sure every project has some degree of lessons learned, but a perceived success will not bring to light the lessons learned that are needed to bring about a success the next time.

The following is from page 42 of the book Emergent Design:

Giving Up Hope Of course, one reason we have not changed the way we do things is because most of us have assumed the problem is not the process, but ourselves. In other words, we have believed that the reason the waterfall process does not succeed very often is that we are not doing it right. Software developers have often been thought of as arrogant. I disagree; I think most are very self-questioning and tend to lack confidence. This can sometimes come off as arrogance, but in general, self-assured people don't have to brag. Lacking any defined standards, software developers have traditionally had no way to determine, for themselves, if they were really good at their jobs. Without any notion of what makes a good developer, we live and die by our latest success or failure. This lack of a set of standards is part of what has kept us from becoming the profession we should be, in my opinion. So, because we tend to worry that the failures in our projects stem from our own faults, we do not suspect that the problem might be the methodology itself. Einstein said it: "Insanity is doing the same thing over and over again and expecting a different result." I think we have been a little bit nuts. Well, maybe not nuts. Maybe just hopeful. Think back to your high school mythology class and the story of Pandora's Box. Pandora, the myth goes, opened a box and unwittingly released all the evils of the world. The last thing that emerged from the box was hope. When I was a kid, upon hearing this tale, I thought "Awwwwww. Well, at least we have hope!" No, no. That is not the point. Instead, the point is that hope is evil. As long as we hope that this time we will get the requirements right, and stable, then we will keep doing things the way we always have. If we hold out the hope that this time we will be able to write code without bugs, then we'll keep writing it as we always have. The hope that this time we will be on time, be on budget, just be better will keep us from changing what we do. We give out T-shirts at our courses with cartoons and pithy phrases on them, and by far my favorite shirt says: "I feel so much better since I gave up hope."

I had left and returned for round two at the company I mentioned above. They were desperately trying to deliver a project that was months overdue and tons over budget. I pitched in and helped out. After a few months of 70 - 75 hour weeks, we delivered.

I came in the next week to an invitation to an all day celebration party. The project was about 9 months late, it was budgeted for 1 million dollars, and the company spent 1.75 million developing it and got paid nothing towards the $750,000 lost. In truth, I came in expecting half of the company team's cubes to be empty, or at least getting to help them carry their belongings out the door. Needless to say the company shrunk from about 160 to about 30 people over the next year as it repeated the same process over and over and over again.

… and so began an insanity I had "hoped" I would see die with the dot-com boom crash. Years later, I have accumulated many more of the same types of stories in my story tool belt. Next week I will add a few more… people seem to love to hope...

Service-Oriented Architectures and Software Product Lines

SEI has published a new report titled "Proceedings of the First Workshop on Service-Oriented Architectures and Product Lines". It discusses the commonalities and the differences with service-oriented architecture (SOA) and software product line (SPL) approaches.

Overview from SEI site:
This report contains the proceedings of the First Workshop on Service-Oriented Architectures and Product Lines (SOAPL) 2007 that was held on September 10th, 2007 in Kyoto, Japan as part of the 2007 Software Product Line Conference (SPLC 2007). This report includes an overview of the workshop, four invited presentations, details of the workshop's outcomes, and the workshop position papers.

Table of Contents from the Paper
Abstract vii
1 Introduction 1
1.1 About This Report 1
2 Workshop Organization and Format 3
2.1 Workshop Organization 3
2.1.1 Organizers 3
2.1.2 Facilitator 3
2.1.3 Participants 3
2.2 Workshop Format 4
3 Workshop Papers and Presentations 5
3.1 Papers 5
3.2 Presentations 5
3.2.1 Methods for SOA and Product Line Development 5
3.2.2 Managing Service Features and Variability 7
3.2.3 Application Examples 8
4 Additional Discussion Topics 13
4.1 What Are the Possible SOA-PL Connections? 13
4.2 Dynamic Aspects—What Are the Issues? 14
4.3 What Is a Reusable Service? 14
4.4 What Are the Architectural Aspects of SPLs Versus SOA? 15
4.5 What Is the Scope of a System in the Context of Services? 16
5 Workshop Outcomes 17
References 19
Appendix A: Software Product Lines and Service-Oriented Architecture: A Systematic Comparison of Two Concepts A-1
Appendix B: A Taxonomy of Variability in Web Service Flows B-1
Appendix C: Comparison of Service and Software Product Family Modeling C-1
Appendix D: Identifying and Specifying Reusable Services of Service Centric Systems Through Product Line Technology D-1
Appendix E: Product Lines that Supply Other Product Lines: A Service-Oriented Approach E-1

Get the paper here
There are also presentations from the authors of the papers available here