The C# has two things going on. The @ part of the string definition is for verbatim strings. VB.NET already does verbatim strings by default, so you can ignore this.

The other $ part is for string interpolation. VB.NET has had string interpolation since VB.NET 14 (released with Visual Studio 2015, around the .NET 4.6 era).

The .NET 4.8 you’re using came much later and should support these features. However, it’s possible you also have a project that is restricting the langversion property to something older.

Additionally, the code in the image in the question is not doing any interpolation, so you can just remove the $ character from the front of the string definition.

Finally, if it were me, I would change this line to also declare the desired data type for the parameter:

Dim clientIDparam As New SqlParameter("@ClientID", clientID)

to

Dim clientIDparam As New SqlParameter("@ClientID", SqlDbType.Int)
clientIDparam.Value = clientID

Well, what you have should work, but then again, you are posting some screen shots of code that does not require use of the $ anyway!

So, in code, then this should work just fine:

    Dim ID As Integer = 1234

    Dim query As String =
        $"SELECT * FROM tblHotelsA WHERE ID = {ID}
        ORDER BY HotelName"

However, the slew and mess of errors in the screen shot looks to have rather nothing with the current error – this suggests that you already have some open string or some string that is not correctly terminated elsewhere in that page of code (the error suggests a bad CASE statement).

And in near ALL cases, you don’t need nor want nor should you use the $ (string substitution) for SQL statements anyway. In other words, that’s just a formula for flakey SQL and SQL that is subject to SQL injection.

So, these two are really equivalent:

    Dim ID As Integer = 1234

    Dim query As String =
        $"SELECT * FROM tblHotelsA WHERE ID = {ID}
        ORDER BY HotelName"

or

    Dim ID As Integer = 1234


    Dim query2 As String =
        "SELECT * FROM tblHotelsA WHERE ID = " & ID &
        " ORDER BY HotelName"

However, BOTH of the above has ZERO ZERO ZERO to do with wanting to use parameters in SQL, and that is a 100% different goal, different concept, and has rather little to do with SQL parameters.

Now, in some cases, I will allow use of string concentration (using either of the 2 above examples – they are the same things) if the input in question was not from a user, and not from a post back. This is for reasons of security, but also that of writing “more” reliable code.

So, use of “free form” text in code? That’s not limited to SQL strings, but is a goal and use case for any kind of strings you want in code. This as noted often saves a boatload of & (or +) for strings that now are far more readable. As I stated, this is a 100% separate issue from that of string concentrations.
So, in both C# or VB.NET, yes, I use the $ (string substitution) all day long.
However, use of “$” once again has VERY little to do with the ability to have multiple lines of free form text in the code editor (starting with an open quote, and say some lines later ending with a closing quote). Once again, a different goal and different issue, and the two goals should not be confused here (that of free form text in code editor vs. that of string substitutions with $).

However, in the case of SQL? Once again, different issue, and once again, I suggest using strong typed SQL parameters.
You don’t want to use string concatenations (or $) since you still have the messy affair of having to include ‘ (single quotes) around strings, but not for numbers, and then for dates, then you back to having to include the ‘ (quotes). However, if you use SQL parameters, then you NEVER need to include the surrounding quotes – another big win and reason to use SQL parameters.

However, this is where you do NOT care about the $ feature, and you want to use SQL parameters. As I stated, the $ feature, and that of SQL parameters are two VAST different issues and two VAST different goals – not to be confused with each other.

The big bonus, the huge bonus of using SQL parameters is you don’t parameters have to include the ‘ (quotes), and you don’t even have to remember (care) if the value is a string, or number. This alone is a great reason to adopt SQL parameters in your code EVEN when it possible to use string concatenations.

Thus, keeping in mind that:

$ is not required for multiline free form text statements in code.
But you MUST USE HUGE caution here, since depending on your project type, during development, this multi-line text string ability is the result of VS having use of what is called Roslyn compiler extensions. If you are deploying a web site (and not a web site application) then you can often find boatloads of code will work during development, but at deploy time, such code will break left, right and center. And the reason is of course that you now MUST ensure that the Web site and IIS has these compiler extensions – and it will often not have them!!!
Much worse is if you using some hosting plan, then that plan may well support .net, but not have built in support for the Roslyn compiler extensions (that extension is what allows the multi-inline free form text strings in code). And perhaps better stated is you often can’t correctly install the Roslyn extensions to that given web hosting plan (if you have your own web server, then this tends to not be an issue or problem).
Hence, it not “really” the .net version you are using that allows this free text inline feature!!! (but that of having the Rosyln compiler extensions installed). This in effect means you really, but really really really do not want the target web site to do ANY code compiling for you! However, if you not using an “application”, then you don’t have this choice, and the web site (IIS, not VS) will now be compiling your code!!! And if IIS is compiling your code without Rosyln, then you are in big deep trouble.

In fact, EVEN with a web site application, IIS will often attempt to compile code in the folder called app_code. As a result, I NEVER use that folder name anymore for my code, and I create my own folder called MyCode, and place my shared code in that folder (this advice is ONLY in the context of an application – since as noted, when I deploy my web site, I don’t deploy the source code anyway).

Since (I’m guessing) that you using a web site, and allowing IIS to do such code compiling, then you asking for boatloads of trouble, since IIS out of the box and the .net compiler on the web server will NOT have the Rosyln compiler extensions installed by default. And while the publishing wizard will attempt and try to add the additional .exe file (the Rosyln compiler extensions) to the project, you playing a game in which now your publishing to the web site has to allow a extra .exe file to be included – and where I come from, a publishing of a web site does not, will not, and should not include an extra .exe to try and “help” IIS and its compiler to now work correctly!!!

So, do keep in mind that the “free text” extensions to VS and .net is actually the result of a compiler extension. However, if you using a publishing model in which IIS is to now compile your code, then this can become a problem. Of course, this is just one more big reason why I always use an “application” and always use a publish to deploy my webforms web sites.

So, do read the following:

Enabling the .NET Compiler Platform (“Roslyn”) in ASP.NET applications

So, make sure these extensions are setup on the web server if you going to start using and introducing Roslyn features into your code.

And again, the free form (multiple line) text in code is not related to the $ feature in vb.net. To be fair, in c#, the @ sign not only allows the escape character to be ignored, it also tends to allow multiple lines of text in the editor to work better for c# code (but, this FYI does not apply to vb.net code).