So many things we developers create are only possible because someone released their work as open source. Their effort allows us to focus on our features – not only in our side projects, but also at our (paid) work. We can use their open source projects for free and create great things, often without the smallest sign of gratitude.
For a long time your workflow customization inside Azure DevOps was limited to choosing one of the pre-defined process templates. All other forms of customization you could do with the on-premises installation of TFS where not possible in Azure DevOps (or Visual Studio Team Services for those who are more familiar with the old name).
This limitation is now history and you can modify your workflow as much as you like. However, without a backup solution for your work items this task can end in a terrible mess. Before you change anything, at least connect with Visual Studio to your work items and export everything to an Excel sheet.
We recently run into a strange problem when we tried sign a message using a private and public key pair. Everything worked as expected on the developer machine, yet in the test environment the same code only throws this exception:
System.Security.Cryptography.CryptographicException: Keyset does not exist
Last week I attended the great workshop "SOA Done Right" by Daniel Marbach and Adam Ralph (organised by the .Net User Group Bern). They did an incredible job to explain SOA, services and how designing for loosely coupled systems differ from an entity-first approach. I learned a lot in the workshop and still need a few days more time to get a deeper understanding of those concepts.
Consistency is an important part of data storage. That is why READ COMMITTED is the default transaction isolation level in SQL Server. This level prevents you from retrieving values that modified inside a transaction but not committed. However, what is great for consistency is a pain for debugging.
As I tried to make some changes in an older project, I ended up with this error message whenever I tried to start the web application:
The default behaviour for views in ASP.Net MVC up to version 5 is that they are compiled when the first user requests them in IIS. When the view isn't that complicated, the user only experiences a minimal delay before the web page is displayed in the browser. That is true as long as the view compiles. If not, your users will get a page like this one:
This dialog is familiar to all developers who use Visual Studio:
Would it not be great if we as developer of a site could warn our users when their passwords are part of a data breach? There is a simple API we can use thanks to Troy Hunt’s "Have I been pwned?" site.
With nearly every application and website demanding an account, most developers will sooner or later have to store passwords. It is incredible how bad that can be implemented and how dire the consequences can be for the users. Take a quick look at the long list of sites taking part in "Have I been pwned?" and you can see how big the problem is.