Skip to content
mythz edited this page Mar 17, 2011 · 20 revisions

A call for recommendations / nominations for high quality .NET libraries

We would like to build an awareness of the great libraries in the .NET eco-system and so we're calling on all pro .NET developers to tweet the libraries they love and use everyday using the twitter hash tag #starlibs. We will be keeping an eye on this hashtag for the best entries for analysis to include in this living document.

Why we need this?

We believe due to a history of poor guidance and good marketing, the .NET world is plagued with heavy, bloated, over-architected libraries that have in-efficient implementations, leaky abstractions and poor APIs and designs. Unfortunately in many cases, the most popular software is usually not of the best quality, just the best marketed.

Doing our homework

ServiceStack likes to belive we're immune to marketing hype and generally does not adopt any .NET libraries at face value. Much time is spent researching and analyzing the competitive landscape to ensure it only picks the best components for use in their systems.

In an effort to provide a good source of high-quality .NET libraries we will be maintaining a list of libraries that have attributes and meets criteria we believe makes good software that promotes good software practices and is enjoyable to use. As a general rule, this list only contains re-usable libraries that have minimal dependencies that allow it to be easily pluggable and freely shared amongst different frameworks and IOC's.

Frameworks not included

Frameworks are expressly excluded from this list since the idea is for these components to appeal to the broadest set of .NET developers where the libraries themselves should be framework agnostic and can be effectively used in any framework.


The ServiceStack test for good software

1. Must be Open Source

With so many high-quality OSS software to choose from, we rarely find it is ever a good idea to have your systems bind to closed source proprietary software - which as there commercially motivated, are usually the worst perpetrators of mis information and poor guidance. OSS has many traits that make it usually the best choice: constantly improving, frequent releases, code quality visible to everyone, broader and more active user-base, etc.

2. Must be well tested

Testing first or was tested after - we don't care, good software is always well tested to ensure it has minimal number of bugs/regressions and is verified that it works as expected.

3. Must be lightweight, self-contained and portable

Smaller libraries usually avoid feature paralysis and are generally designed to solve their particular problem-set more elegantly than their bloated counter parts. Small, self-contained libraries are generally less opaque and invasive, have a shorter learning curve, are more re-usable, easier to upgrade and suffer less dependency hell. In all cases there must be a link available to the latest, self-contained release that users can download from and start using.

We don't believe you should need to read a comprehensive manual or subscribe to a religion just to use a library, and with intuitive, well-designed self-desribing APIs we don't think you have to. So it bears repeating: Heavy weight libraries aren't recommended here and need not apply.

4. Must be code-first and unhibitted by designers/wizards

This may also be a style preference but our experience tells us the most succinct and enjoyable APIs to use and easiest to test are modelled directly in the programming language, unhibitted by GUI designers. If you prefer Drag N' Drop designers that's fine too, this just isn't the list for you.

5. Must be recommended

To keep the selection process as transparent as possible, each component must be recommended, and the most recommended components will be listed first in their respective category. A lot of value can actually be inferred by who the library is recommended by, and readers will be better able to make up their own mind by researching the recommenders GitHub or twitter profile.

6. Must be in C# or F#

This is more a style preference since you can effectively write bad code in any language. But this requirement is based on our experience that in general good developers do not code in VB.NET :). Having it in C# / F# also stands the best chance for the library to be more portable across frameworks and build-able with the cross-platform MONO toolchain.

7. Must be supported

Some organization or somebody should be maintain ownership of the software and is able to receive and act on bug reports. We don't mind if the only support available is commercial, as long as its supported.

8. Must have sensible defaults and can work without mandatory App.config sections

Software that is dependent on heavy configuration, has more moving parts that makes it harder to configure correctly which in turn makes it more complex to maintain. Complex configurations also inhibit the ability to test the software in isolation and is therefore excluded.

Beautiful Code

In general the above rules help to achieve and promote beautiful code, that is:

A programmer knows he has achieved perfection not when there is nothing left to add, 
but when there is nothing left to take away.

-- Antoine St Exupery


The List - Grouped by Library Category

Note: this is an opinionated list of libraries resulting from our many years development experience based upon the guiding principles above. It's likely a few libraries recommended wont make the cut, what some may consider to the perfect mix of configurability we may consider to be over architected. As a general rule, the further away the library deviates from the beautiful code definition above, the less likely it is to make it, sorry.

ORMs

Simple.Data led by @markrendle - 150+ tests, 142KB

A new and very active ORM for .NET taking advantage of the dynamic features in .NET 4.0 to provide a dynamic and intuitive API letting you access virtually every SQL Server in existence today. With SQLite and MongoDB providers nearly finished this is one to watch in the future.

** Recommended By: ** @demisbellot

NoSQL Clients

ServiceStack.Redis led by @demisbellot - 556 tests, 292KB, benchmarks

A comprehensive C# client for the excellet Redis NoSQL database. Offers both a low-level raw byte access and high-level strong-typed API.

** Recommended By: ** @demisbellot

TODO: Add RavenDB client. @RobAshton?

IOC's

Funq IOC led by @kzu - ? tests, 54KB, benchmarks

A high performance DI framework by eliminating all runtime reflection through the use of lambdas and generic functions as factories.

** Recommended By: ** @demisbellot

Munq IOC - 54 tests, 21KB, benchmarks

A fork of Funq offering some added features tailored for use in Web Hosts

Testing and Mocking Frameworks

moq led by @kzu - ? tests, 496KB

Moq is the only mocking library for .NET developed from scratch to take full advantage of .NET 3.5 (i.e. Linq expression trees) and C# 3.0 features (i.e. lambda expressions) that make it the most productive, type-safe and refactoring-friendly mocking library available.

** Recommended By: ** @demisbellot

FakeItEasy led by @patrik_hagne - 873 tests, 479KB

The easy mocking framework for .Net.

** Recommended By: ** @TheCodeJunkie

Serializers

protobuf-net by @marcgravell - 427 tests, 137KB, benchmarks

Likely the fastest, full-featured binary serializer to grace .NET shores. protobuf-net is a very efficient implementation of Google's Protocol Buffers.

** Recommended By: ** @demisbellot

ServiceStack.Text by @demisbellot - 218 tests, 98KB, benchmarks

ServiceStack's string text processing library containing the fastest and most compact JSON, JSV and CSV Text Serializers for .NET

** Recommended By: ** @demisbellot

Template Engines

Razor Engine ? tests, 208KB

A very elegant, wrist-friendly syntax providing a succinct DSL-like templating language to mix C# source code and HTML markup naturally

** Recommended By: ** @demisbellot

TODO: Add spark view engine. @RobertTheGrey?


Recommend a software library here!

The best way to recommend a library for inclusion here is to email me directly at demis.bellot@gmail.com please along with your submission include:

  • The name of, category and 1 sentence describing the library
  • The project maintainer (preferably links to GitHub and Twitter)
  • The total number of tests
  • The total size in kb a minimal working configuration including dependencies
  • Your Twitter or GitHub username (to list as a recommendation)

Fill out what you can, at a minimum we will record your recommendation against the library.



  1. Getting Started
    1. Create your first webservice
    2. Your first webservice explained
    3. ServiceStack's new API Design
    4. Designing a REST-ful service with ServiceStack
    5. Example Projects Overview
  2. Reference
    1. Order of Operations
    2. The IoC container
    3. Metadata page
    4. Rest, SOAP & default endpoints
    5. SOAP support
    6. Routing
    7. Service return types
    8. Customize HTTP Responses
    9. Plugins
    10. Validation
    11. Error Handling
    12. Security
    13. Debugging
  3. Clients
    1. Overview
    2. C# client
    3. Silverlight client
    4. JavaScript client
    5. Dart Client
    6. MQ Clients
  4. Formats
    1. Overview
    2. JSON/JSV and XML
    3. ServiceStack's new HTML5 Report Format
    4. ServiceStack's new CSV Format
    5. MessagePack Format
    6. ProtoBuf Format
  5. View Engines 4. Razor & Markdown Razor
    1. Markdown Razor
  6. Hosts
    1. IIS
    2. Self-hosting
    3. Messaging
    4. Mono
  7. Security
    1. Authentication/authorization
    2. Sessions
    3. Restricting Services
  8. Advanced
    1. Configuration options
    2. Access HTTP specific features in services
    3. Logging
    4. Serialization/deserialization
    5. Request/response filters
    6. Filter attributes
    7. Concurrency Model
    8. Built-in caching options
    9. Built-in profiling
    10. Form Hijacking Prevention
    11. Auto-Mapping
    12. HTTP Utils
    13. Virtual File System
    14. Config API
    15. Physical Project Structure
    16. Modularizing Services
    17. MVC Integration
  9. Plugins 3. Request logger 4. Swagger API
  10. Tests
    1. Testing
    2. HowTo write unit/integration tests
  11. Other Languages
    1. FSharp
    2. VB.NET
  12. Use Cases
    1. Single Page Apps
    2. Azure
    3. Logging
    4. Bundling and Minification
    5. NHibernate
  13. Performance
    1. Real world performance
  14. How To
    1. Sending stream to ServiceStack
    2. Setting UserAgent in ServiceStack JsonServiceClient
    3. ServiceStack adding to allowed file extensions
    4. Default web service page how to
  15. Future
    1. Roadmap

Clone this wiki locally