- Resolution Randomizer
-
I have always found it is hard to make meaningful New Year's Resolutions. Lucky for me, I ran across this cool Silverlight Application that helps you find a truly meaningful resolution... if you don't like the one you get, just click "Randomize" and try again!
Try your own http://resolutionrandomizer.pop.us/ecard.aspx... I'd love to hear what you get!
- Silverlight 2 DataGrid December 2008 Release
-
We are very happy to get out a bug-fix release of the Silverlight 2 DataGrid. It should be very easy to simply drop this into your project and the get the benefits of a bunch of bug fixes..
This updated DataGrid contains almost 30 fixes to the top issues that we heard, including:
- Rows containing focus no longer disappear when the ItemsSource changes
- ComboBox and other controls opening a popup now work as expected
- DataGrid Selection is preserved when sorting
- Buttons outside the DataGrid work as expected when they are clicked while the DataGrid is in editing mode
- Improved FrozenColumn behavior
- Improved cell currency
- SelectedItem is updated before the CurrentCellChanged event is raised
- Many more...
For the full list of fixes check out this post by Brian Braeckel one of our DataGrid developers.
You can find full install instructions and more information on Scott Morrison's blog.
- Let Silverlight Power Your Netflix Experience!
-
As I am sure you have heard, Netflix is moving over to using Silverlight for their very cool streaming video service. This is already the default experience on the mac, but if you are a PC user you need to opt in to this experience for now as they are doing a staged rolled out.
http://www.netflix.com/silverlightoptin
- Framework Design Guidelines: An appeal for consistency
-
Continuing in our weekly blog post series that highlights a few of the new 
additions to the Framework Design Guidelines 2nd edition.. This content is found in the Names of Classes, Structs, and Interfaces section of Chapter 3: Naming Guidelines. Even in the .NET Framework we don’t always apply the design guidelines consistently – and, as Phil found out, we often pay the price for it.
DO ensure that the names differ only by the “I” prefix on the interface name when you are defining a class–interface pair where the class is a standard implementation of the interface.
The following example illustrates this guideline for the interface IComponent and its standard implementation, the class Component:
public interface IComponent { … }
public class Component : IComponent { … }
PHIL HAACK
One place where the framework violates this convention is the class HttpSessionState, which you would suspect implements IHttpSessionState, but you’d be wrong, as I was.
This inconsistency nearly bit us when we were developing our HttpContextBase abstraction of HttpContext, because it seemed we could expose the Session property as the IHttpSessionState interface, which turned out to not be the case.
- Framework Design Guidelines: Naming New Versions of Existing APIs
-
Continuing in our weekly blog post series that highlights a few of the new 
additions to the Framework Design Guidelines 2nd edition.. This content is found in the Naming New Versions of Existing APIs of Chapter 3: Naming Guidelines. Incrementally evolving an existing, popular API is very hard. My main take away personally from this guidelines (and Kit’s annotation) is to work hard to get it right the first time!
DO use the “64” suffix when introducing versions of APIs that operate on a 64-bit integer (a long integer) instead of a 32-bit integer. You only need to take this approach when the existing 32-bit API exists; don’t do it for brand new APIs with only a 64-bit version.
For example, various APIs on System.Diagnostics.Process return Int32 values representing memory sizes, such as PagedMemorySize or PeakWorkingSet. To appropriately support these APIs on 64-bit systems, APIs have been added that have the same name but a “64” suffix.
public class Process {
// old APIs
public int PeakWorkingSet { get; }
public int PagedMemorySize { get; }
// …
// new APIs
public long PeakWorkingSet64 { get; }
public long PagedMemorySize64 { get; }
}
KIT GEORGE
Note that this guideline applies only to retrofitting APIs that have already shipped. When designing a brand new API, use the most appropriate type and name for the API that will work on all platforms, and avoid using both “32” and “64” suffixes. Consider using overloading.
- Framework Design Guidelines: Avoiding Abstractions
-
Continuing in our weekly blog post series that highlights a few of the new ![image[5]_thumb[2]_thumb[2]_thumb_thumb](http://blogs.msdn.com/blogfiles/brada/WindowsLiveWriter/FrameworkDesignGuidelinesAvoidingAbstrac_10AAB/image%5B5%5D_thumb%5B2%5D_thumb%5B2%5D_thumb_thumb_thumb.png)
additions to the Framework Design Guidelines 2nd edition..
This content is found in the Principle of Self-Documenting Object Models section of Chapter 2: Framework Design Fundamentals. I love the war-stories that our annotators provide here.
AVOID many abstractions in mainline scenario APIs.
KRZYSZTOF CWALINA
Abstractions are almost always necessary, but too many abstractions indicate over-engineered systems. Framework designers should be careful to design for customers, not for their own intellectual pleasure.
JEFF PROSISE
A design with too many abstractions can impact performance, too. I once worked with a customer who re-engineered its product to incorporate a heavily OO design. They modeled everything as a class and ended up with some ridiculously deeply nested object hierarchies. Part of the intent of the redesign was to improve performance, but the “improved” software ran four times slower than the original!
VANCE MORRISON
Anyone who has had the “pleasure” of debugging through the C++ STL libraries knows that abstraction is a double-edged sword. Too much abstraction and code gets very difficult to understand, because you have to remember what all the abstract names really mean in your scenario. Going overboard with generics or inheritance are common symptoms that you may have over generalized.
CHRIS SELLS
It’s often said that any problem in computer science can be solved by adding a layer of abstraction. Unfortunately, problems of developer education are often caused by them.
- dnrTV Does MEF!
-
Glenn Block recently did a great screen cast on the Managed Extensibility Framework.
Show #130 | 11/26/2008
Glenn Block on MEF, the Managed Extensibility Framework
Glenn Block shows you how to use MEF to allow a plugin architecture in your .NET applications. The framework is extensible enough to allow any type to be imported and exported as managed plugins, which are called parts.
- MEF Preview 3 Shipped!
-
I am pretty excited to see MEF preview 3 ship on codeplex today! Please check out Glenn's post for all the details... This is a release where we really focused on getting in your feedback... We are 100% MSPL, we are shipping our own unit tests, we have made several design changes based on feedback around defaults, ExportProvider, etc. One thing I love about taking on a big customer such as Visual Studio, is you get good, real world feedback up front. In this CTP, we really focused on performance and performance best practices. Whether you use MEF directly or just use Visual Studio, you will appreciate this work!
So grab the bits and let us know what you think!
- Framework Design Guidelines: Supporting Experimentation
-
Continuing in our weekly blog post series that highlights a few of the new ![image[5]_thumb[2]_thumb[2]](http://blogs.msdn.com/blogfiles/brada/WindowsLiveWriter/FrameworkDesignGuidelinesSupportingExper_1084E/image%5B5%5D_thumb%5B2%5D_thumb%5B2%5D_thumb.png)
additions to the Framework Design Guidelines 2nd edition.. This content is found in the Framework Design Principles section of Chapter 2: Framework Design Fundamentals. I love the history and real world color Chris brings to this guideline with his annotation.
Some APIs lend themselves to experimentation and some do not. To be easy to experiment with, an API must do the following:
Allow easy identification of the right set of types and members for common programming tasks. A namespace intended to hold common scenario APIs that contains 500 types, out of which only a handful are actually important in common scenarios, is not easy to experiment with. The same applies to mainline scenario types with many members that are intended only for very advanced scenarios.
CHRIS ANDERSON
In the early days of Windows Presentation Foundation (WPF) project we ran into this exact issue. We had a common base type named Visual from which almost all of our elements derived. The problem was that it introduced members that directly conflicted with the object model of the more derived elements, specifically around children. Visual had a single hierarchy of child visuals for rendering, but our elements wanted to introduce domain-specific children (like a TabControl only accepting TabPages). Our solution was to create a VisualOperations class that had static members that worked on a Visual instead of complicating the object model of every element.
- Framework Design Guidelines: Scenario Driven Framework Design
-
Ccontinuing in our weekly blog post series that highlights a few of the new ![image[5]_thumb[2]_thumb[2]_thumb](http://blogs.msdn.com/blogfiles/brada/WindowsLiveWriter/FrameworkDesignGuidelinesScenarioDrivenF_10568/image%5B5%5D_thumb%5B2%5D_thumb%5B2%5D_thumb_thumb.png)
additions to the Framework Design Guidelines 2nd edition.. This annotation is found in Chapter 2: Framework Design Fundamentals. Joe and Chris nail the core things.
JOE DUFFY
As software developers, we enjoy creating fun and powerful new capabilities, and sharing them with other developers. That’s one of the reasons API design is so enjoyable. But it’s also incredibly difficult to step back and objectively assess whether some new capability that you’re particularly passionate about has utility in the real world. Using scenarios is the best way I know of to identify the need for and ideal usage of new capabilities. Developing scenarios is in fact incredibly hard, for good reason: It requires a unique combination of technical skill and customer understanding. When you’re finished, you could make a series of decisions based only on gut feel and intuition, and perhaps deliver some useful APIs, but the risk that you will make a decision you will later regret is far greater. When in doubt, it’s best to leave a feature out and decide to add it later when a compelling need is better understood.
CHRIS ANDERSON
Each developer has his or her own methodology, and although there isn’t anything fundamentally wrong with using other modeling approaches, the problem generally is the output. Starting by writing the code you want a developer to write is almost always the best approach—think of it as a form of test-driven development. You write the perfect code and then work backwards to figure out the object model that you would want.
- What Does that .NET Namespace Mean: System.* and Microsoft.*
-
I need your feedback... I am chatting with some co-workers about the perception of in the .NET Community of what the System.* and Microsoft.* namespaces mean. So I had the crazy idea of just asking you!
For this exercise, I'd like you to think about a new "feature area" of the .NET Framework... Would you instinctively draw any conclusions about that area based on if the namespace where System.* or Microsoft.*? If that feature area were in the Silverlight subset of .NET, would that change your mind at all?
There are basically three schools of thought among my co-workers -- which one is closer to your perception?
1) They are the same or it really doesn't matter. The root namespace between System.* and Microsoft.* have no meaning... Microsoft appears to be arbitrary about when functionality goes in one or the other.
2) Part of the Framework vs. Addons.
System.* indicates stuff that is logically part of the framework. It is 100% supported, solid-long term design that will not need to churn, safe to bet on, stable, likely will get great tooling support. Designed to be very interoperable and could work anywhere .NET is. This may ship as part of the redist or maybe an out of band (such as ASP.NET MVC, ASP.NET AJAX, etc).
Microsoft.* is the bleeding edge stuff or value-add. It is typically very cool stuff that adds on to the framework and enhances it, but maybe a work in progress... over time you might expect some of those concepts to go into the framework. As an example, the great work patterns and practices does often falls into this bucket.
3.) Part of the core redist vs. addons
System.* means it ships in the core redist. You are not able to ship it with your application. System.* stuff only ships when the redist revs. You would not expect Microsoft to do any out-of-band releases in the System.* namespace for example.
Microsoft.* means it is not part of the core redist. A note: as we move stuff into the core redist you'd expect us to change the namespace from Microsoft.* to System.* meaning you'd have to tweak any calling code *if* you wanted to take advantage of the new version.
So, what do you think? Which one best fits your thoughts this? I'd love any other comments...
- Need Windows Mobile Phone Recommendation
-
I am ready to replace my several year old Verizon XV6700… The 2nd replacement battery is not keeping me through the day any more, it is way too heavy and my colleagues pick on my for using such old technology ;-)
I have a pretty good deal with Verizon, so I’d like to say with them if possible… The killer apps for me today are calendaring and basic email… but I’d love to use the phone as an MP3 player and GPS seems very sexy… I also really like to be able to use my phone as a modem for my laptop…
Do you have a mobile phone you love? What do you think I should get\avoid? Should I try to tough it out until after the holidays?
Thanks!
- Framework Design Guidelines: Testable Frameworks
-
I thought I do a weekly blog post series that highlights a few of the new additions ![image[5]_thumb[2]_thumb[2]_thumb](http://blogs.msdn.com/blogfiles/brada/WindowsLiveWriter/FrameworkDesignGuidelinesTestableFramewo_104CE/image%5B5%5D_thumb%5B2%5D_thumb%5B2%5D_thumb_thumb.png)
to the Framework Design Guidelines 2nd edition.. The first is around writing testable frameworks it is found in Chapter 1: Introduction. Phil brings his real world experience building ASP.NET MVC to the table with this annotation.
PHIL HAACK
I would add one more point to this list, which is that “Well-Designed Frameworks Are Testable.” And by “testable” I don’t just mean that the framework itself can be unit tested, though that is important as well.
One hard lesson we learned from our customers as we released early previews of the ASP.NET MVC framework is that unit test coverage of a framework is not sufficient to calling it “testable.”
While we could easily test our framework, we needed to go further and strive to make sure that applications built using our framework are themselves testable.
This usually falls out naturally by following solid design principles such as Separation of Concerns, Orthogonality, Composition, and DRY (Don’t Repeat Yourself). Most importantly, we put ourselves in our customers’ shoes and built apps using our framework in a test-driven manner. This app building effort improved the design of the Framework immensely.
- Managed Extensibility Framework (MEF) Demo
-
The Managed Extensibility Framework (MEF) is a new feature of .NET 4 (and will work on 3.5 as well) that makes it significantly easier to extend applications and generally support application composition patterns.
What does that really mean? Well, take 6 mins and 5 seconds to watch this excellent demo Scott Guthrie did at his PDC2008 keynote.
Download video directly
Other MEF resources:
- Book Plug: The C# Programming Language (3rd Edition)
-
At PDC2008, we shipped the third edition of the C# Language specification... If you are a language-lawyer type or just like to know exactly how the latest version of the language works, this book is for you!
In this addition, we tried something new, we asked some folks from the community to add some annotations about pit falls, best practices, and history. Please take a look and let us know what you think... Do these sort of things work for you?
