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

Smart Client Software Factory ( SCSF ) for Visual Studio 2008 Available

The Smart Client Software Factory ( SCSF ) for Visual Studio 2008 is now available on the Microsoft downloads site.

Overview from Download Site:
The Smart Client Software Factory provides an integrated set of guidance that assists architects and developers in creating composite smart client applications. The software factory includes: QuickStarts, reference implementations, how-to topics, patterns, and Visual Studio .NET extensions. This release is for Visual Studio 2008.

Get the Smart Client Software Factory – April 2008 for Visual Studio 2008 here.
Get the Smart Client Software Factory – April 2008 Documentation for Visual Studio 2008 here.

Silverlight 2 End-to-End Data Centric Application

Brad Abrams has put together a really nice post on Silverlight 2. He calls it, End-to-End Data Centric Application with Silverlight 2.

His goals, list at the beginning of his blog, are to show-

Explain the Silverlight Project Format
How to do rich layout and animation
Uses line of business controls for Silverlight such as DataGrid
Has a Linq based data layer on the server on the server
Exposes business logic over that data via a WCF web service
Consume the service on the client in Silverlight and databind to the DataGrid
Store result locally to minimize round trips to the server across instantiations with IsolatedStorage
Re-theme the UI to make it look more cool.
Do it all in code that you could easily write on stage in about 30-45 mins
Have Fun!

Definitely worth checking out, do so here.

Microsoft Operations Framework (MOF) 4.0 Released

Brief Description from MSDN Site
MOF 4.0 is practical guidance for IT organizations contained in a set of 23 documents. With this release, MOF now reflects a single, comprehensive IT service lifecycle—it helps IT professionals connect service management principles to everyday IT tasks and activities and ensures alignment between IT and the business.

Overview from MSDN Site
Microsoft Operations Framework (MOF) 4.0 has been designed to help overburdened IT professionals quickly access useful, relevant content. It contains practical guidance—not just theory—and its streamlined approach makes it possible to use either the entire framework or one process from a particular service management function (SMF).

The guidance in MOF encompasses all of the activities, workflow, and processes involved in managing an IT service: its conception, development, operation, maintenance, and—ultimately—its retirement. MOF organizes these activities and processes into service management functions, which are grouped together in phases that reflect the IT service lifecycle. Each SMF is anchored within a lifecycle phase and contains a unique set of goals and outcomes that support the objectives of that phase. An IT service’s readiness to move from one phase to the next is confirmed by management reviews, which ensure that established goals are achieved and that IT’s goals are aligned with those of the organization.

MOF guidance is contained in 23 documents:

The MOF 4.0 Overview describes all of the MOF content and its goals. It is the ideal starting place for someone new to the framework or an executive looking for the big picture.

Four MOF phase overviews have been written primarily for IT managers and directors seeking a better grasp of IT service strategy. The overviews provide an introduction for the phase, describe the service management functions contained within, and detail the management reviews performed during the phase.

Sixteen SMFs contain specific activities and workflows designed primarily for the IT professionals who will be implementing the activities.

A glossary gives definitions of terms used frequently in MOF.

A spreadsheet maps earlier versions of MOF to version 4.0.

Get it here.

Models for Evaluating and Improving Architecture Competence

SEI has released a new paper titled Models for Evaluating and Improving Architecture Competence.

Overview from the SEI Download Page
Software architecture competence is the ability of an individual or organization to acquire, use, and sustain the skills and knowledge necessary to carry out software architecture-centric practices. Previous work in architecture has concentrated on its technical aspects: methods and tools for creating, analyzing, and using architecture. However, a different perspective recognizes that these activities are carried out by people working in organizations, and those people and organizations can use assistance towards consistently producing high-quality architectures.
This report lays out the basic concepts of software architecture competence and describes four models for explaining, measuring, and improving the architecture competence of an individual or a software-producing organization.

The models are based on
(1) the duties, skills, and knowledge required of a software architect or architecture organization
(2) human performance technology, an engineering approach applied to improving the competence of individuals
(3) organizational coordination, the study of how people and units in an organization share information
(4) organizational learning, an approach to how organizations acquire, internalize, and utilize knowledge to improve their performance.

The report also shows how the four models can be synergistically applied to produce an evaluation instrument to measure an organization’s architecture competence.

Below is the Table of Contents:

1 Introduction 1
1.1 Terminology and Definitions 2
1.2 Models of Competence 7
1.3 Organization of This Report 9
2 The Duties, Skills, and Knowledge (DSK) Model 11
2.1 What Are an Architect’s Duties, Skills, and Knowledge? 12
2.2 Advantages and Challenges of the Approach 13
2.3 Processing the Raw Data 15
2.4 Duties 16
2.5 Skills 17
2.6 Knowledge 18
2.7 Using the DSK Model to Assess and Improve the Architecture Competence of Individuals 21
2.8 Duties, Skills, and Knowledge for a Software Architecture Organization 22
3 The Human Performance Technology Model 25
3.1 Using the Human Performance Technology Model to Measure and Improve Architecture Competence 27
4 The Organizational Coordination Model 29
4.1 Dependency 29
4.2 The Coordination Capability of an Organization 30
4.3 Measuring the Coordination Activities 31
4.4 Relating Organizational Capability to Dependencies 32
5 The Organizational Learning Model 33
5.1 The Components of the Organizational Learning Framework 34
5.2 Using the Organizational Learning Framework to Measure and Improve Architecture Competence 35
6 Considering the Models Together 37
6.1 How the Models Together Support Evaluation 37
6.2 Principles Embodied by the Models 38
6.3 Coverage Provided by the Models 39
7 Building an Assessment Instrument 43
7.1 Assessment Outcomes 43
7.2 The Foundations and Structure of the Instrument 44
7.3 Sample Questions 45
7.4 Reflections on the Instrument Questions 47
8 Summary 49
8.1 Next Steps 49
8.2 Conclusion 51
Appendix A: Survey of Practicing Architects 53
Appendix B: Complete List of Duties, Skills, and Knowledge 61
Bibliography 69

Get it here.