In my last post, I gave you instructions for setting up a local symbol store in order to start to build up a “debugging environment.” What I didn’t tell you was why you were doing that. In this video blog entry, I’m going to explain and demonstrate why we loaded the Windows symbol files into the symbol store, and why you should put your own application’s symbol files into your symbol store. More...
I spend more hours debugging than developing. I know that I shouldn’t. It’s a bad habit, but it happens. Still, the most important thing in debugging is making sure that your development environment is set up to also be used as a debugging environment. One of the most important factors in successful debugging is knowing how your application is executing and what methods or functions are being called, not only in your application, but also in the operating system. To do that, I always create a local symbol store where I keep the operating symbol files. In this post, I’ll walk you through the process of creating your own symbol store. More...
Continuous integration is a concept that most in the industry are familiar with, but what about continuous delivery? Continuous integration, if you’re not aware, is the process of automating the building of your software project such that every time a change set is committed to the project’s version control repository, a dedicated build server will automatically build the software to ensure that there are no errors in the checked-in source code. Continuous delivery is an extension of continuous integration. During continuous delivery, the source code is built, but the end result is a packaged software project that can be released to QA (and possibly end users) with every check-in. More...
In my last post, I introduced you to the Managed Extensibility Framework for creating composable applications made out of parts. In this post, I’m going to start exploring the new Workflow Foundation technology that was re-introduced with .NET 4.0. Over the next few days, I’ll explore different aspects of Workflow Foundation and look at how it can be used to create customizable and extensible applications. But in this post, we’re going to start with the basics: hosting the workflow designer. More...
In a previous post, I discussed the trends towards building extensible applications. In that post, I highlighted four technologies that I felt were significant towards building extensible applications. In this post, I’ll look at the first of those technologies: the Managed Extensibility Framework, also known as MEF.
MEF is a new component-based application framework that was integrated into .NET 4.0. MEF itself was actually built by Microsoft as an open source project on CodePlex, but the intent was always to build it into the .NET 4.0 Framework and use it for some of Microsoft’s products. For example, Visual Studio 2010 uses MEF as its extensibility framework that developers can use to build custom components that integrate with Visual Studio. There’s a growing market of free and commercial extensions that in a matter of weeks since the release of Visual Studio 2010 have made the product so much better. More...
“I’m a developer, not a designer. I’m great at writing business logic. I’m best when kept developing the core server-side functionality. I live in the world of database and application tiers.” Those are all of the excuses that I have made for myself in the past as to why I didn’t want to do user interface work. Sure, I could build simple Windows Forms or MFC applications, but they never looked that great. Then WPF came along and changed my perspective. More...
.NET 4.0 is out and while it’s still early and everyone is evaluating whether to upgrade, it’s extremely clear what the message is for applications built on the .NET 4.0 platform: extensibility. .NET 4.0 will fundamentally change the standard architectures and patterns that we’ve seen with the previous .NET releases because of new enhancements and evolutions for the .NET 4.0 platform. Architectures for .NET 4.0 products will need to be fluid rather than fixed. Products built with the .NET 4.0 platform need to have appropriate mechanisms in place to support customization and extensibility by third-party or customer developers in order to add new functionality to applications or customize standard functionality. This will no doubt make testing, deploying, and maintaining .NET 4.0 applications more difficult in the long term. But the added value and increased opportunities for products are worth the cost. More...
A team here in Phoenix came to me with an interesting problem back on Friday. The Silverlight user interface that they were developing had a text box for a search query and a button that the user would click to perform the search. Understandably, the customer wanted the search button to be a default button such that pressing Enter in the text box would cause the search button to be clicked. Unfortunately, out of the box there’s no way to associate a button to a text box to implement that kind of behavior. More...