More bliss and joy in your .NET journeys
Blog of an upside-down web developer, Art SkviraDo you ever wish you could just quickly run some C# code, without all the heavy lifting, like creating a new project, setting it up etc? Or worse yet, starting to experiment with some temporary code by modifying an existing solution, and then forgetting to remove your code, and lo and behold, the next thing you know it’s deployed to production?!
Wouldn’t it be nice to be able to play around with any C# code, as if from a command line, but with all the goodies like highlighting and code completion? How awesome it’d be to see all the properties on the objects you’re working with and their actual values, without having to rely on some vague description from MSDN? Think of this as iPython or dev tools Javascript console, but for C#.
That would let you try different ways to solve problems, running code straight away, line by line, without having to restart your project and step into whichever function you’d be modifying instead.
If your Web, Console/Windows or WPF app ever needs to talk to databases, other APIs or maybe encrypt/decrypt information it receives from other apps or the user, it needs to access sensitive authentication credentials – such as user names and passwords for database connection strings, API keys, private encryption keys etc.
Where should you store that sensitive info and how would you supply it for your app? The first obvious approach is to store those values in a config file of sorts or a local database. Why not? It’s easy, secrets can be read & used by your app quickly and reliably, it seems.
Well, there are several major issues with that approach:
Whether you’re just starting to look into web development after learning some C#, or whether you’re a seasoned Windows developer making forays into web dev, it’s very common to stumble into this massive confusion: it seems like Microsoft deliberately tried to complicate things by creating heaps of technologies and acronyms for them. Let’s have a look, just off the top of my head, we have got the following tech available to us:
When you work for long enough on a given project, you kind of get comfortable with the tools and things eventually start to feel familiar. So it’s only natural to start feeling like you’re missing out and there might be newer and greater things out there, some exciting new languages, tools or techniques.
In this article, I’d like to show you some online tools that I found super helpful in my development work.
Exceptions can happen anywhere. Some are thrown by your code, deliberately. Others are thrown by .NET or 3rd party libraries. You know where some exceptions may get thrown, and there are heaps more you didn’t even know existed.
Most likely you already know how try ... catch ... finally block works (check out this MS
doco if you want to brush up on that), and while you understand it all at the high level, you
may still be wondering whether you should:
To make an informed judgment, you need to understand the main types of exceptions. This understanding will help you decide when to catch and how to handle individual kind of exception in a given situation.
In today’s world of interconnected apps & services, you may often need to call another API to get or modify information.
In this article I’d like to show you how to do the following:
Let’s get on with it!
More often than not your application needs to have access to various sensitive information, such as logins & passwords of various sorts (database, network resources etc), API keys, encryption keys and alike.
In one of my earlier articles, I demonstrated how that information can be stored in an encrypted way in the application config file – see How to store login details securely in the application config file. This approach, however, is not fool-proof. In fact, it’s quite easy to decrypt the information stored in such a way, provided the attacker has access to the executable with the decryption key.
In this article, I would like to show you a much more secure way of storing and accessing sensitive information – such as usernames and passwords, encryption keys, API keys etc. This method will come particularly handy if you already rely on AWS for some of your application needs.
Looking for a Microsoft Azure-specific solution to store & read your passwords? Check out this article: “How to securely store and retrieve sensitive info in .NET Core apps with Azure Key Vault”
Web and app development is exciting – you probably tried that and got hooked, and who wouldn’t? Write some code and bam! – see the result immediately. Feels amazing, we all know that.
Naturally, a lot of aspiring devs wonder: wait, can I actually do what I love AND get paid for doing it? Can I become “a real developer” —- one that actually stands a chance of getting an interview & landing a job? Or maybe I need to take an expensive bootcamp or a course to just get started? Even worse, maybe I have to get a CS or Engineering degree to be even considered for a dev role?
This may feel like a massive hurdle, and even more so if your formal education isn’t specifically technical. But is there really just one way? Should you even bother trying to get a foot in the door with no formal credentials?
Handling of URLs and URL parameters in ASP.NET Core is done via Routing Middleware. That’s what Microsoft wants you to believe: Routes in ASP.NET Core provide capabilities of directing incoming requests to route handlers (controllers).
What MS is not telling you, is that Routing also provides copious amounts of reasons to hate it. If you ever said to yourself anything like “OK cool, so I’ll just add a new route for this endpoint, and in no time will go back to the actual task at hand” and then THREE hours down the track when nothing works and your manager is, like, “Have you done it yet?”, you really starting questioning whether this whole web developer career thing is going to work out for you.
As a developer, more often than not you have to deal with other people’s code. And (hopefully only sometimes) you want to throw it all away and rewrite if from scratch. Those of us that are saner (or perhaps just with more battle scars) just roll up our sleeves and get into refactoring. And perhaps you know how awesome it feels to separate someone’s mess of a code into a neatly structured ensemble of classes and corresponding methods, especially when you realise that mess was written by your very self.