VB.NET equivalent to C# $@ String
What is the VB.NET equivalent to using the $@ syntax on a string?
public void OnGet()
{
var query = $@"
Today is {DateTime.Today}
and it is a {DateTime.Today.DayOfWeek}
";
}
I tried searching for what the $@ is called, but none of the results were related.
Since I don't know what that key combination is called, I don't know how to search it.
As shown below, the suggested solutions are not working. This project is built on the .NET Framework 4.8.1, if that matters.
Update
The original question provided a simple example to explain what I was trying to do. It had nothing to do with any real code; just an example. One of the comments was that I needed to use a $ on my string. I took a screenshot from an actual project to show where I had already tried that method and failed. Hence, the screenshot does not match the example code.
Another Update
This is to address everyone who is telling me that VB.NET doesn't need the $ when writing multi-line strings:
I want to take whatever SQL I can get to work in SQL Server and paste it in without adding quotes and plusses to every line like I am able to do in C#.
Though there is an accepted answer, I still have not found a way to mimic the way C# can have text pasted in VB.NET.
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:
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).