Nimble Gecko

Visual Studio is chock-full of various debugging functions, windows and panels. And they are pretty good at what they can do. However, this abundance of tools and options often leads to a cognitive overload – how the hell are you supposed to know which one to use when?

There is one particular function, however, that has proven to be most useful when finding and fixing bugs, or doing any sort of prototyping or testing of new ideas. If I had to name my favourite tool in the VS debugging chest, it would be the QuickWatch window.

Let’s see how it can help you save lots of time and guesswork when debugging and developing apps.

Often you need to put links in your ASP.NET MVC Core Views that take users to other controllers in your web app – like navigating to a details page for a particular record in the table. Or when building a primary, secondary or tertiary navigation. Or logging users in or out. Heck, you need links everywhere!

A very obvious (but wrong!) way is to hardcode relative paths to your controller’s actions in the View, like <a href="/product/details/1">View product details</a>. It’s super easy, right? What can possibly go wrong? Actually, a lot of things. Just the tip of the iceberg:

• to pass parameters, you’ll need to do string concatenation/formatting in Razor or Javascript
• if you move or rename your controller or its methods, effectively changing the URL, your links will break
• if your URL schema changes say from using named ids like ?id=1 to positional ids, like /products/1, you’ll need to update all your hardcoded URLs.

As you can see, hardcoding is a big pain in the rear. But what can you do instead? Fear not, there’s a solution that addresses all the above problems and more!

It can be extremely infuriating to stumble over something so seemingly simple as the Select List control, and having to spend time trying to make it work, instead of focusing on what really matters in the given moment – be it learning a new tech or developing your web app.

ASP.NET Core MVC made is somewhat easier to deal with select lists. Previously in .NET Framework, you had quite a few ways of supplying data to your Select Lists, to the point where it just got ridiculous and it seemed like the bloody thing just wanted to kill you.

Now a lot of ambiguity seems to have been removed, and Tag Helpers for MVC and Razor Pages are much easier to use. Let’s have a look at how you can set default option for Select List control in ASP.NET Core MVC or Razor Pages.

When working on your ASP.NET MVC application, you often need to include some of your app’s data as Javascript objects. You may need this for some interactive behaviour, graphs/charts, or simply to “hydrate” the UI with the relevant information, such as username etc.

There’s certainly a big push to move away from rendering JSON data in MVC Views. Instead, it’s recommended to use Ajax calls that fetch JSON data from backend APIs. This helps to separate concerns in your application, making it more maintainable and easier to support, test and debug.

However, sometimes it’s OK to put JSON data directly in MVC Views:

• performance–it saves you another network call
• prototyping–test your idea before you spend a lot of time on adding another endpoint to your backend API
• size of the data–if it’s just a small object, you may not want to create a separate endpoint just for that thing
• legacy–the app you’re working on is ancient, soon-to-be-retired, so there’s really no point putting lipstick on the pig

With these caveats in mind, let’s see how you can easily put some JSON into your ASP.NET MVC views.

Let’s face it – often you just need to get down and dirty, quickly sketch up some code to see if your idea of a bugfix or a feature is going to work.

Sometimes you can whip up some C# code using C# Interactive window in Visual Studio, or an online C# REPL (see this article for more info on that).

But a lot of times you DO need to make changes to your existing project(s), just because of all the other stuff, like DB access, authentication, other APIs responses, routing, dependency injection etc. that is needed to test your brand spanking new idea.

Also, you don’t want to accidentally break already working code and want to be able to roll your changes back quickly if it doesn’t work and you need to pull the plug on it.

Do 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:

• catch exceptions immediately when calling a function?
• or maybe catch them somewhere in between, after business logic/data access and before UI logic?
• or should you let exceptions bubble up to the very top of your application?
• should you let them crash your app or catch and just ignore them?
• maybe there’s a way to recover from exceptions, but how can you do it?

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.