I am not sure if this is something that I am doing but I am seeing some weird issues with interpolated strings. Here is an example
Trace.WriteLine($"Raising event {e.EventName} for document {e.DocumentId}", "Info");
In above case e.EventName = DOCUMENT_CREATE and e.DocumentId = 111679
so the result should be like following
Raising event DOCUMENT_CREATE for document 111679
but it is printing like
Raising event DOCUMENT_CREATE� for document 111679
Same is the case in some other places where I am using string interpolation. What could be causing it?
Another piece of info, client have installed .net 4.6.1 RC. Is there a bug in .net 4.6.1 RC?
Well it was related to string interpolation but not entirely. We process our assemblies through SmartAssembly, and smart assembly messed up the interpolated strings by changing the encoding. SmartAssembly doesn't do that for non interpolated strings.
Related
I don't understand why this will not compile when typed out in a .cshtml/Razor page:
#($"{"\""}") <-- this does not work
#($"{"'"}") <-- this also does not work
#($"{"a"}") <-- this DOES work
The error states:
RZ1000: Unterminated string literal. Strings that start with a quotation mark (") must be terminated before the end of the line. However, strings that start with # and a quotation mark (#") can span multiple lines.
CS1002: ; expected
CS1513: } expected
It appears that non-quote characters work fine, but a double-quote or single-quote character breaks Razor's ability to parse the interpolated string, even when the quote character is escaped.
All the examples work fine in a plain .cs file:
public sealed class Test
{
public string x = $"{"\""}";
public string y = $"{"'"}";
public string z = $"{"a"}";
}
What gives?
My environment is as follows:
.NET SDK: v7.0.102
.NET Runtime: v7.0.2
C#: v11 (preview)
Visual Studio Community 2022 (64-bit): v17.4.4
It's a bug, known by the .NET guys as far back as 2015 at least.
The dotnet engineers on the dotnet/aspnetcore github page felt the work required to fix it outweighed the benefits, however:
Jun 3, 2015
After investigating this issue further turns out the requirements to complete this are pretty high (need to understand C# close to entirety at the Tokenizer level). Will revisit this later.
2 months later...
Aug 14, 2015
Moving to backlog because we feel these cases are not common in MVC views, and have trivial workarounds (e.g. use string.Format() instead of string interpolation).
https://github.com/dotnet/aspnetcore/issues/4976
I've googled this for a couple of hours and couldn't find anything.
So, I've got a certificate which has "ОАО" (russian letters) in its Simple Name for Subject.
I get this value using this code:
var x509 = new X509Certificate2(certificateBytes);
var subjectName = x509.GetNameInfo(X509NameType.SimpleName, forIssuer: false);
On Windows, this code returns 'ОАО' and this gets saved into MS SQL.
But on Linux in Docker container this code returns escaped unicode characters, but in caps.
Here they are:
\U041E\U0410\U041E
Instead of:
\u041E\u0410\u041E
And this caps is getting saved instead of 'ОАО'. So when I do nothing, it's \U1234 and it's written as-is in database: literally \U1234. But when I perform .ToLower()-transformation, this code transforms to \u1234 and is recognized as 'ОАО'.
So I've come up with a hack but I'm not sure it's the right thing to do. Anyway, that does save my text as 'ОАО' in database:
var subjectName = Regex.Unescape(x509.GetNameInfo(X509NameType.SimpleName, forIssuer: false).ToLowerInvariant());
What do you think? Is this a bug? Why does this method behave this way? Why it 'capses' unicode escape /u-character?
Is this a correct way to solve the problem?
Can I encounter a situation in which I'll find some unicode case-sensitive characters in which case I can lose the characters or they are case insensitive?
Is this a bug?
Yes it was a bug and has been fixed in .NET 6 RC2 (which is yet to be released, but is the next release of .NET 6 previews).
The Linux implementation of this with OpenSSL was inadvertently escaping non-ASCII text.
Hi fellow programmers and nerds!
When creating regular expressions Visual Studio, the IDE will highlight the string if it's preceded by a verbatim identifier (for example, #"Some string). This looks something like this:
(Notice the way the string is highlighted). Most of you will have seen this by now, I'm sure.
My problem: I am using a package acquired from NuGet which deals with regular expressions, and they have a function which takes in a regular expression string, however their function doesn't have the syntax highlighting.
As you can see, this just makes reading the Regex string just a pain. I mean, it's not all-too-important, but it would make a difference if we can just have that visually-helpful highlighting to reduce the time and effort one's brain uses trying to decipher the expression, especially in a case like mine where there will be quite a quantity of these expressions.
The question
So what I'm wanting to know is, is there a way to make a function highlight the string this way*, or is it just something that's hardwired into the IDE for the specific case of the Regex c-tor? Is there some sort of annotation which can be tacked onto the function to achieve this with minimal effort, or would it be necessary to use some sort of extension?
*I have wrapped the call to AddStyle() into one of my own functions anyway, and the string will be passed as a parameter, so if any modifications need to be made to achieve the syntax-highlight, they can be made to my function. Therefore the fact that the AddStyle() function is from an external library should be irrelevant.
If it's a lot of work then it's not worth my time, somebody else is welcome to develop an extension to solve this, but if there is a way...
Important distinction
Please bear in mind I am talking about Visual Studio, NOT Visual Studio Code.
Also, if there is a way to pull the original expression string from the Regex, I might do it that way, since performance isn't a huge concern here as this is a once-on-startup thing, however I would prefer not to do it that way. I don't actually need the Regex object.
According to https://devblogs.microsoft.com/dotnet/visual-studio-2019-net-productivity/#regex-language-support and https://www.meziantou.net/visual-studio-tips-and-tricks-regex-editing.htm you can mark the string with a special comment to get syntax highlighting:
// language=regex
var str = #"[A-Z]\d+;
or
MyMethod(/* language=regex */ #"[A-Z]\d+);
(the comment may contain more than just this language=regex part)
The first linked blog talks about a preview, but this feature is also present in the final product.
.NET 7 introduces the new [StringSyntax(...)] attribute, which is used in .NET 7 on more than 350 string, string[], and ReadOnlySpan<char> parameters, properties, and fields to highlight to an interested tool what kind of syntax is expected to be passed or set.
https://devblogs.microsoft.com/dotnet/regular-expression-improvements-in-dotnet-7/?WT_mc_id=dotnet-35129-website&hmsr=joyk.com&utm_source=joyk.com&utm_medium=referral
So for a method argument you should just use:
void MyMethod([StringSyntax(StringSyntaxAttribute.Regex)] string regex);
Here is a video demonstrating the feature: https://youtu.be/Y2YOaqSAJAQ
This question already has answers here:
Replace Line Breaks in a String C#
(20 answers)
Closed 5 years ago.
I'm getting a string from an external native library function which uses "\n" for line separation. I simply want to write this to disk using the appropiate line ending format on the system I'm running my .Net application, which will be usually windows. So "Environment.NewLine" results correctly in "\r\n".
I'm simply write the string to a textfile via
MyString = NativeLib.GetStringEitherLForCRLF();
File.WriteAllText(MyFile, MyString); // will not change LF format
This doesn't changes lineendings, which seems to be intented that way. However, I'm wondering while the same string in C using fwrite in asciimode would probably change the lineendings as I remember.
Since conversion would be an easy task I'm just curios, how the "correct" or best-practice way in .Net should be. Is there a standard function, which would automatically convert the lineendings according to the current environment settings ?
I know how to replace characters in strings, that is not the basic question. The exact question is:
Does there exist a .Net standard library function that will do line ending conversions already depending on OS and Environment settings or which maybe has to be used with a certain parameter to ensure this?
Like e.g.:
File.WriteAllText(MyFile, MyString, Lineencoding.CRLF); // which does not exist
or
File.WriteAllText(MyFile, MyString.ConvertLineendings(Line.CRLF)); // which also does not
But there maybe an option I've missed but it doesn't look like that.
I do not want to write unnecessary boilerplate code to such a trivial task.
The problem is also described in Normalize newlines in C# just to show that I can be more complex than most people think. I'm not completely sure whether the proposed regex solution will work in 100% of all cases.
If you really get the input as a string (as opposed to a file or something), then create a StringReader over it. On the reader, do .ReadLine() in a loop and write each line to your file (e.g. with a StreamWriter).
Trying: T obj = JsonSerializer.DeserializeFromString<T>(jsonData);
on a string that has several \n's throughout it. JayRock's library successfully deserializes this like: T obj = (T)JsonConvert.Import(typeof(T), jsonData);
Is this a bug, or do I need to manually strip out newlines?
The problem I ran into wasn't the \n's, but instead was the lack of public properties on my DTO's.
RE: Can ServiceStack.Text deserialize JSON to a custom generic type?
The debugger preview popup shows actual linebreaks as \n so that the preview remains single line. The text visualizer shows linebreaks correctly.
This implies to me that the JSON itself is broken, because newlines should be encoded with \n.
Linebreaks in strings are illegal in Javascript, and thus also in JSON.
If this doesn't happen to the the issue: the nuget version was published 1st Oct, but there's a commit in github dated 3rd Oct with comment "fix whitespace issues hopefully once and for all". Worth trying.