I first wrote this back in 2012 as a set of commonly useful abstractions for building applications on the cloud. It’s evolved over time but an awful lot of things have changed and grown in the last 5 years and although many of the core patterns and abstractions are still useful it’s become hindered by it’s own weight when put into a more recent context. When I wrote it all sorts of things that are effectively “off the shelf” now just didn’t exist. And of course, I hope, I’ve learned and grown as a developer and architect since then.
I’m also increasingly wanting to take advantage of new developments in the .NET space such as .NET Standard and ASP.Net Core and the AccidentalFish.ApplicationSupport framework is very much a .NET 4.x rooted framework.
All that being the case, and being mindful that a reasonable number of people are using this framework in production software, my intention is to place the current version (6.0.0) of the framework into maintenance mode and start afresh with a simplified framework aimed squarely at support .NET Standard and taking advantage of recent developments. That leaves the way open for future updates to the existing framework but lets me move forward with some major changes.
My goals for this major reworking include:
- .NET Standard support to enable use in as full a range as possible of .NET runtimes (Core, Framework, Xamarin etc.)
- Increased modularity of packages so you can use just what you need
- A removal of the configuration framework and replacement by an abstracted bridge to external configuration sources
- A removal of the logging abstraction framework and adoption of the abstraction layer provided by Microsoft in the Microsoft.Extensions.Logging.Abstractions package.
- A pulling apart of the dependency injection abstraction framework.
Before I release it I’ll be reworking a significantly sized product of my own (Simple Status Page) over to it which should mean it hits the open source world in reasonable shape.
The code will be on GitHub just as soon as I can figure out what to call it!
If you want to discuss this then the best thing to do is to get on touch with me on Twitter at @azuretrenches.
Last night I published a minor update to this framework to GitHub and NuGet that adds new timer capabilities via the new ITimerFactory interface.
An interval timer is available that runs an action, then pauses for the specified on completion, and runs the task again until cancelled (either by the action itself or a cancellation token). A regular metronomic timer is available that runs an action n seconds irrespective of task duration. Importantly in the latter case if the action takes longer than the duration of the timer to complete it will be cancelled to prevent compounding overlapping action issues (excessive CPU usage, out of memory etc.).
I’ve also added an IBackoffFactory interface that allows the backoff policies to be created with custom backoff timings. The backoff policies continue to be directly injectable with their default timings.
I hope these additions are useful. Feedback is, as ever, welcome.
This week I’ve published a couple of updates to this framework taking it to v3.1.0.
Release notes for v3.0.0 are here and for v3.1.0 here.
There are breaking changes moving to the v3.x series as I’ve completely overhauled the logging framework to allow for the introduction of robust logging providers deeply into the framework including a new NuGet package for Serilog. There is a sample showing how to use this package and the new logging framework.
In addition I’ve upgraded the queueing system with some new features.
Firstly there is brand new support for large message queues – as in queues with message sizes in the megabytes or gigabytes. This is surfaced through the ILargeMessageQueueFactory and ILargeMessageQueue interface and combines a standard queue with a blob repository. The ILargeMessageQueue interface is derived from the standard IAsynchronousQueue and so can be used interchangeably and transparently with existing queue consumers.
Finally the queues now provide access to message properties where the underlying queue supports this feature – for example Azure Service Bus queues, topics and subscriptions.
I’m planning to add support for DNX and Entity Framework 7 in the near future (weeks, not months).
As ever if you have any issues or feedback then you can get in touch here or over on GitHub.
I’ve just pushed to Nuget the latest version of this framework. Full release notes are available here. The main addition is the support for IoC containers other than Unity – I’ve added support for Ninject and Autofac with this release however I’ve also improved the component host with a default restart handler and made a set of bug fixes.
I’ve also been working on tutorial / getting started documentation and you can find the first part of this here.
As ever I’d love to hear any feedback you might have either here or over on the GitHub Issues page.
This is now available in both GitHub and NuGet. There have been a large number of changes mostly to make the naming consistent throughout the framework and also documentation has been added to all public interfaces in the AccidentalFish.ApplicationSupport.Core assembly / package.
Release notes are available, the API reference, and documentation site updated.
Any issues please let me know here or on GitHub.
As part of my documentation push I’m also dealing with some unresolved naming issues and inconsistencies I’ve noticed since releasing v1.0.0.
As addressing some of this means breaking changes, and following the semver rules, I’ll be releasing this as v2.0.0 of the framework in due course.
I’m tracking the changes in a release note as I make them and you can already see that here if you want a view of what is coming.
A quick post with a few bits of news regarding my lightweight application framework.
Yesterday I pushed out a new version of the packages that contain an updated logger that will work alongside my Owin middleware for HTTP logging and correlation ID attachment.
If you use that middleware package, and an appropriate filter (Web API or MVC) in a project using the logger then everything should just work.
I’ve not been strict enough over the versioning of this framework and I’m going to tighten this up by adopting the Semver format and guidelines. I am aware of a few, minor, upcoming breaking changes as I’ve realised I’ve got some naming inconsistencies in the interfaces (particularly around the use of async) – at least by adopting Semver it will be clear when I make those changes.
The long promised documentation is now underway – something of a minor miracle as I’m always distracted by Visual Studio! I’m hosting it on GitHub Pages, go check it out. It’s early days but I’m hoping to make fairly short work of getting started guides so at least there’s a clear way into the framework.
I’m writing the documentation using Markdown and that’s getting translated into HTML on GitHub Pages via Jekyll. I’ve not used Jekyll before but it’s pretty simple to get going with and coupled with Markdown seems to be a neat solution to creating verbose documentation. I’ll be producing API reference documentation using C#s XML comments and Sandcastle.
I’ve recently pushed out some new open source for HTTP logging / tracing and alongside that support for adding correlation IDs to http calls and tracking them across MVC and Web API applications.
It’s fully documented and can be found in GitHub and on NuGet. The logger is independent of storage mechanism however I’ve currently only created a repository for Azure. I’ll probably add a SQL repository shortly.
The NuGet packages are entirely free standing other than the minimal Microsoft dependencies required.
I’m currently working on adding correlation ID support to the logging framework contained within the wider AccidentalFish.ApplicationSupport framework and I expect that to roll out early next week.
Alongside this I’m having a bit of a documentation push for all my open source. Other than Markdown and Sandcastle I’d be very interested in hearing how others have approached creating large amounts of technical documentation in the Microsoft space.
As ever feedback and issue reports are very welcome.
As per my previous post I’m spending some time on my application framework – I’m aware of this getting used, by myself and others, in a variety of projects and some of the flaws in the code as it stands now are starting to hurt. Since I first put it together the Azure libraries have also come on a long way and this has led to some friction.
That being the case I’m taking this oppurtunity to revisit the framework with a number of objectives:
- Reduce the number of dependencies. Even the core assembly had accumulated around 10 NuGet dependencies including Azure storage, Entity Framework, Unity, AWS and SendGrid.
- Removal of the Enterprise Library Transient Fault framework.
- Support for dependency injectors other than Unity.
- Switch to NewtonSoft Json for serialization.
- Documentation and samples.
- Move to the “new” way of restoring packages.
This does mean a bunch of breaking changes but I think they’re worth making to achieve the above.
I’ve got a compiling first stab at v1.0.0 in GitHub. I’ll be testing this in an upcoming project and dropping the packages into the NuGet prerelease channel.
I just wanted to give a little bit of warning to anyone using these that an upcoming version of these packages is going to be somewhat restructured.
Over time they’ve become a bit monolithic and adding the NuGet package to a solution can result in all manner of dependency NuGet packages being added even if you’re not using those parts of the framework. And if you follow me on Twitter you’ll know I do so hate DLL hell!
To resolve this I’m going to pull them out into multiple NuGet packages. I’m not quite sure what the final shape will be yet but the best indication is probably given by the latest work I’m doing here. I’ve just started adding some wrapped cache support (Redis) and rather than just bundle it into the .Azure package I’ve added the core interface to the .Core assembly and have created a new assembly .Cache. So you can imagine that in a reworked NuGet world that might be 3 NuGet packages:
My instinct is I’ll actually end up with 6 or 7 NuGet packages as follows:
I’m not planning on significant C# level API changes so once you’ve got the packages you need things should continue to work as is.
If you’re using this NuGet package and have alternative suggestions then let me know.