Project Resources

Developer Visual Studio 2010 Configuration Settings

  • For All Projects:
    • Application: Target Framework = .NET Framework 4 Client Profile
    • Build: Treat warnings as errors = All
    • Build: (x) Output XML documentation file (*Lowercase ".xml")
    • Signing: (x) Sign the assembly (*Use NColony.snk from an existing project)
    • Code Analysis: (x) Enable Code Analysis on Build
    • Code Analysis: Rule Set = Microsoft All Rules
    • Edit "Assembly.cs" and add assembly: CLSCompliant(true)
  • Contracts Project Settings Note: Events in Code Contract interfaces will never be used, so you need to set "#pragma warning disable 0067" prior to the event(s) and "#pragma warning restore 0067" after to explicitly ignore the warning.

SoapBox Core

This project already provides many of the features NColony will set out to include and uses the LGPL open source license.
Q: Why not simply contribute to that project? A: Well, there are a few concerns:
  • There is a "Contributor Agreement" that must be signed and talks about a company "SoapBox Automation Inc."
  • The source code is hosted on what appears to be a private subversion server rather than using popular and free open source communities
  • The "contact us" goes to a profile of the project's founder with a form (resume-ish)
Many, if not all, of the concerns might mean nothing, but they represent risk when deciding to build a project's entire foundation on top of them.

Regardless, this project will leverage and build upon many of the lessons learned in that project's source code:

After an initial attempt to incorporate many of the ideas of this project, we may very well decide to use the project directly and make any necessary contributions directly as well.

Note: Scott (the founder of SoapBox Core) also did a good article on CodeProject:

User Experience/Interface Design Patterns

MEF as an Inversion of Control Container

Event Management

Jeremy Likness

Jeremy gets his own section due to his blogging contributions around MEF, M-V-VM, Prism & Unity, WPF, and Silverlight along with a number of other topics.

Code Contracts


Project Links

  • MEF is built-in to .NET 4, but much of the concepts are new and best documented by the project's site and its contributors.
  • This project leverages .NET 4 Code Contracts. However, enhanced tooling for Visual Studio is provided as a separate download at DevLabs Code Contracts Site
  • Composite Application Guidance for WPF & Silverlight: Note: This project will be used as guidance. Although the framework for Unity & Prism including EventAggregator are provided as solutions for this guidance, this project will seek to use built-in constructs of .NET4 to achieve the same solutions where appropriate. If the need arises to use these libraries, we will do so.
  • The TFS project structure and branching strategy was derived from the TFS 2008 Branching Guidance. However, we will make every effort to migrate our structure to be in-line with the TFS 2010 Branching Guidance. Note: It's interesting that the VSTS Rangers decided to use separate CodePlex sites for each of their releases, which makes it difficult to centrally monitor the project's updates. Perhaps this was for the very simple reason of having only 1 primary download button? Hmm...


Q: Why not bind directly to .NET SyndicationFeed for the RSS Reader?

Put simply, the Microsoft Syndication framework has no interfaces! As a rule, NColony project aims to specify communication contracts explicitly between assemblies using interfaces. This is a tried-and-true approach to building flexible and decoupled applications and works extremely well with IoC/DI patterns. As an aside, SyndicationFeed does implement the empty interface IExtensibleSyndicationObject, which will allow developers to write extension methods for SyndicationFeed (e.g. new feed formatters, perhaps loading using LINQ-to-XML's XDocument, etc.).

As an architectural decision, we also wanted to control event notifications through the "INotify" interfaces and the newcomer to the core Framework ObservableCollection previously only available through the WPF and then Silverlight frameworks. This is where exceptions already creep in, because we are using ObservableCollection that also does not supply proper interfaces. A development spike was performed to assess how easily ObservableCollection could be abstracted through the use of Generics and Generic constraints (e.g. ISyndicationFeed<TFeedItems> where TFeedItems : ICollection<ISyndicationFeedItem>, INotifyCollectionChanged). But, ultimately the generic had to cascade through the entire hierarchy of classes to the client that ultimately defined the type and the first pass revealed there might be potential issues with MEF type discovery (exports/imports) with this approach.

Last edited Mar 10, 2010 at 11:47 PM by ericis, version 7


No comments yet.