Lautan Coding

If your following defensive programming principles, a good function should always check its inputs to protect itself from receiving bad data. If you are writing an API library that will be used by other upstream applications or via a publicly available resource, then you need to ensure that the parameters that are passed to its API don’t contain illegal arguments. If there is a bug in production then ideally I would like an exception to be raised and the error to be logged somewhere . For example, the following two functions don’t contain any defensive measures: class Program { static void Main(string[] args) { CreateUser(null, null); SetAlarmTime(1234567); } static void CreateUser(string firstName, string lastName) { // will this function work when nulls are passed in? } static void SetAlarmTime(int hours) { // will this function work if hours is greater than 24? } } As a reader of the above code, you can’t tel

A while ago I needed to move a ClickOnce installation to a new URL based on an update I was performing. Now, anyone who is familiar with ClickOnce knows you can migrate an application to a new URL inside Visual Studio by setting up the new "Update Location" in the settings dialog below: In the past, I have bookmarked and followed Robin's guide on how to move a ClickOnce deployment using this standard method. Robin's blog is a one-stop shop for any technical information regarding ClickOnce. However, guess what? It turns out this method does not work if you want to change the CPU type of the application (which is what I wanted to do) or if your certificate has already expired. I wanted to change my application from AnyCPU to x86. Apparently there is nothing you can do about this because the process architecture setting is part of the ClickOnce deployment manifest. Basically I was stuck!! And then I found this stack overflow post about uninstalling a click o

Despite all our best efforts, problems can and do happen in production. If you are practicing CI/CD and continually pushing new code to a server, bugs can sometimes creep in. When that happens you want to be able to inspect, debug and even step-through the code to identify and fix the problem. However, depending on the type of problems they might be hard to reproduce on a dev box. Some problems only occur when you get real live data flowing through the system. For example, if the problem is to do with incoming TCP/IP connections from a specific set of IoT devices, this can be hard to reproduce in dev. Of course, it's considered bad form to debug the code live on the production server. If you are connecting up to an application in debug mode, you're effectively stopping all clients communicating with the server while you step through the code. Not good form! And let's not mention leaving a break-point on and then going for lunch! In this scenario, what you real