You are right to feel a pressure to do something. I meet developers like this all the time, whose skills are slipping away. If this is your last job before you retire, and the company and the work will last that long, you don't have to do anything. But if not, then you should. Because when the work stops, where will you be?
You feel, I expect, as though you are standing with your hand on a doorknob, but not opening the door and going through it, which makes you feel bad. But you know what? Your peers are just standing in the corner and haven't even found the door yet! And you don't have to burst through it right now. You can start by opening it and looking. Just look at all the shiny new tech that's been released lately that you could choose to learn about.
There are new .NET versions released all the time. You don't need to catch up on everything that's been released since you stopped keeping up; just learn the very latest stuff. Free videos and tutorials are all over the web, and if that feels a little too unstructured for you, there are proper courses you can buy. For example PluralSight (disclaimer: for whom I write, but not courses I expect you will want to take) has a $29/mo subscription with all the courses you can watch. There are offline readers to let you put courses on a phone or tablet and watch during your commute or in the evening instead of whatever you do now. One way of "looking through the door" is to make a list of tech and some resources you could learn it from, as well as what it's good for. This will help bring the huge universe of Stuff I Should Have Learned down to a more reasonable level.
Then, if you decide to learn a technology, set yourself a very specific small goal. For example, if that xml-processing stuff you're writing now is for a Windows app, "I will learn enough WPF to be able to open a file, read the contents, and put them on the screen." If it's Web, then enough MVC (Whatever the latest level is) to do the same thing. If you work with databases, add a clause in there about doing a simple statement (a select maybe) against a database. Then launch into your learning process evaluating things against getting you to that goal. A long article that's full of history and shiny screenshots to persuade you why to use a technology is not as helpful as one with code and the like to show you how to do what you want.
Once you've written a "hello world" app in the new tech, take a long hard look at your current job. You can't deploy stuff to customers with the newest versions, but is there a task you do all the time that would be quicker if you wrote a small utility? Maybe some powershell? Maybe a little WPF app? Look for something useful like that, and still in your free time, evenings and weekends, write it. When it's done, start using it. After about a week, go tell your boss what you did. Something like this:
You know how Xing the Y takes half a day a week and nobody likes to do it? Over the last few weekends I wrote a utility to automate it. I had to use the latest [WPF, MVC, Visual Studio, whatever] because it has this ABC feature that really made this simple to do. I learned how to do it and wrote the tool and now it's only taking me half an hour to X the Y. I know I wrote the code on my own time, but I'd like to give it to the company so that everyone can use it. Is that ok? How do I do that?
(Chances are your employment agreement says the company owns this thing anyway, so it's kind of an empty gesture to volunteer to give it to them, but your boss is likely to enjoy hearing it.)
Ideally, seeing this benefit from new tech would wake your boss up a little and get you a chance to keep learning new stuff. But that's not always how this goes. If they don't come along on your journey, that's fine. Set yourself another goal and another until you feel like you can apply somewhere else. Don't worry about getting hired to do something you can't do. That's the new employer's job to worry about. You just worry about getting good enough to get hired.