More bliss and joy in your .NET journeys
Blog of an upside-down web developer, Art SkviraIt 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.
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:
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:
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”