More bliss and joy in your .NET journeysBlog of an upside-down web developer, Art Skvira
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 be hardcoding relative paths to your controller’s actions in the View,
<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:
?id=1to 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 were awash with various ways of providing data to your Select Lists, to the point where you realised it was a decoy and 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.
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:
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?!
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!