If you're looking for help with C#, .NET, Azure, Architecture, or would simply value an independent opinion then please get in touch here or over on Twitter.
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:
AccidentalFish.ApplicationSupport.Core
AccidentalFish.ApplicationSupport.Azure
AccidentalFish.ApplicationSupport.RedisCache
My instinct is I’ll actually end up with 6 or 7 NuGet packages as follows:
AccidentalFish.ApplicationSupport.Core
AccidentalFish.ApplicationSupport.AzureStorage
AccidentalFish.ApplicationSupport.AzureServiceBus
AccidentalFish.ApplicationSupport.EntityFramework
AccidentalFish.ApplicationSupport.RedisCache
AccidentalFish.ApplicationSupport.SendGridEmail
AccidentalFish.ApplicationSupport.SesEmail
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.
