Skip to main content

Creating libraries and .NET Standard

As part of his fantastic 'What is .NET standard' presentation at DDD12, Adam Ralph provided an amazing amount of detail in such a short amount of time. One of the most valuable points, which is completely obvious when you think about it, is how you should work with .NET standard when creating libraries.

NET standard now comes in a multitude of flavours: currently 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6 and 2.0. When starting out with something new, we (as developers) often want to be as cutting edge as possible and probably haven't read the small print / finer details. So as a result, when creating our first .NET standard library a natural tendency is to create it targeting .NET Standard 2.0. Of course, that makes perfect sense - it's the newest so must be the best? It's definitely true, it is the latest and has the largest .NET framework coverage. BUT, and it is a big but. The library you are building can now only be used by other libraries targeting .NET Standard 2.0 (and newer). If the consumer of your library wants, or must, target .NET standard 1.6 (or older) then they will be unable to use your library due to this version incompatibility.

Therefore when starting a new library targetting .NET standard you should always start with targeting 1.0 and only increase the targeted version when you run into an unsupported framework call. If you are able to create a library that can target .NET standard 1.0 you should be really happy, it has the highest level of compatibility and will make your library's consumers lives much easier.

Like I say, when it's highlighted it makes perfect sense but I'm sure we've all seen that "Target .NET Standard Version" dropdown and wondered "When there's 2.0, why would I ever consider anything 1.x!"

Comments

Popular posts from this blog

Why do my Android Notification only appear in the status bar?

I'm definitely getting back into Android development, I'm remembering that feeling of 'Surely this should be easier than this!'. All I wanted to do was to schedule a local notification which behaved similar to a push notification pop-up. That is, as well as showing the small icon in the status bar I wanted it to pop up on screen to notify the end user. All seems fairly easily, I found this code for how to schedule a notification. That all worked perfectly, apart from the notification would only appear in the status bar. Searching around I found loads of different answers / solutions, mostly all saying the same thing:It only worked if you used 'NotificationCompat.Builder' in place of 'Notification.Builder', orYou had to set the priority to 'NotificationCompat.PRIORITY_HIGH'As usually happens, none of these solutions worked for me until I added in the missing piece of the jigsaw:- '.setDefaults(Notification.DEFAULT_ALL)'. For me this…

IPhone hangs when running from XCode

I've had this happen a couple of times now and the first time was a little worrying that I'd bricked my iPhone. Basically I was running an application on my phone via XCode and when rebuilding an updated version it failed with a "busy" error message. Stopping XCode and unconnecting my phone had no effect, the phone was stuck displaying the loading screen of the application and wouldn't respond to any key commands. To fix you have to hard reboot, holding the power and home button until the phone reboots - doesn't lose any of the data you have on your phone (a concern the first time I did it).

Do "Task Hours" add anything in Scrum (Agile)?

What do task hours add to the overall process in scrum?This was a question that has arisen from all team members in both instances that I've helped teams switch over to scrum. The benefits of artifacts like the comparative story point estimation, the 2 week sprints, stand-ups and the end of sprint demo have been self evident to the team, but as one I think every team member has expressed dismay when it comes to task planning and estimating each task in hours. Left unchecked there is a natural tendency for people to actually begin to dread the start of each sprint purely due to the task planning session.In my current role we've been lucky to investigate this further as a team.The team sat down to discuss the problems it was experiencing with estimating tasks in hours and the following common themes appeared:It is hard: Maybe it shouldn't be, but time estimation is hard! Story points are comparative and abstracted making them easier to determine, but time estimate is gen…