The Uri constructor seems to be doing a lot of additional work when handling file: URIs, sometimes unfortunately to one's disadvantage. For example, file:///a%A4b is interpreted as file:///a%A4b/a%A4b via AbsoluteUri (and file://%2Fa%A4b/a%A4b in ToString() for some reason), and so is apparently every file URI that does not start with a drive letter and contains non-ASCII (even percent-encoded) characters.
Is it possible to disable this behaviour of file: URIs? It seems it has to be done globally, since I tried using different parameters in the constructor and it didn't work as well. I am fine with disabling any sort of special handling of file: URIs, since even (valid to my knowledge) URIs like file:a throw an exception due to that.
The issue seems to only crop up only in .NET Core up to 3.1. In .NET Framework or .NET 5, new Uri("file:///a%A4b") works as expected. Is there a way to get around this issue without upgrading or switching to .NET Framework?
This is a known issue in .NET Core prior to .NET 5. You will need to update to .NET 5.
Relevant links:
https://github.com/dotnet/runtime/issues/1031
https://github.com/dotnet/runtime/pull/36429
https://github.com/dotnet/docs/issues/19965
Related
DateTimeFormatInfo.GetShortestDayName(DayOfWeek) is supposed to return names like Su, Mo, etc. as shown in the output of the example on the Microsoft documentation.
Instead, I get only one letter: S, M, etc.
Code to reproduce: (I'm using WPF .Net 6)
DateTimeFormatInfo en_us = CultureInfo.GetCultureInfo("en-US").DateTimeFormat;
string s = en_us.GetShortestDayName(DayOfWeek.Tuesday);
This is not useful to me since Tuesday and Thursday for example, have the same identifier. What could cause this issue, so that I can fix it and get the expected Su, Mo, etc. ?
You could add the following setting to your (.csproj) project file to not use the ICU globalization APIs that were introduced in .NET 5:
<ItemGroup>
<RuntimeHostConfigurationOption Include="System.Globalization.UseNls" Value="true" />
</ItemGroup>
This is likely "by design" as outcome of switching from Windows-specific way of getting globalization information to publicly available data.
Following article Breaking change: Globalization APIs use ICU libraries on Windows explain the change (but indeed does not go into specifics like "if short names are changed"):
Starting in .NET 5, if an app is running on Windows 10 May 2019 Update or later, .NET libraries use ICU globalization APIs, by default.
And the ICU site lists abbreviations as one of the components (highlighting is mine):
Formatting: Format numbers, dates, times and currency amounts according the conventions of a chosen locale. This includes translating month and day names into the selected language, choosing appropriate abbreviations, ordering fields correctly, etc. This data also comes from the Common Locale Data Repository.
This appears to be a change from .NET 4.7.2 to .NET Core 6 (possibly all versions of .NET Core - I can't confirm right now).
In .NET 4.7.2 I get two-character results; in .NET 6 I get one-character results.
I also don't see any documentation online that indicates that the change was an intentional breaking change.
I would submit a bug ticket to either update the documentation (and admit that it was a breaking change) or revert the behavior.
A workaround would be to take the first two characters of GetAbbreviatedDayName.
I am working with a project in .Net 2.0, this must stay in .Net 2.0 I have no way around this as this is what the customer wants.
I am trying to create a string that is going to url encode this
HttpUtility.UrlEncode(key);
However, I get the message
HttpUtility does not contain a definition for UrlEncode
Looking at MSDN here https://msdn.microsoft.com/en-us/library/system.web.httputility.urlencode(v=vs.80).aspx I see that this should be easily possible.
I have my using statement bringing in System.Web and it is in my references too.
Any ideas on what I need to do?
If you are having trouble with system.web use the alternate method as shown in this blog. Html-and-Uri-String-Encoding-without-SystemWeb
I am looking at upgraded from NServiceBus 2.6 --> 3 and watching the upgrade video, Andreas says you need to use the EndpointName attribute.
That is fine, however, what if you have several different environments that use different InputQueue names? I have input queues as:
MyInputQueue_Dev
MyInputQueue_Stage
MyInputQueue_Prod
I need a way to handle this since my messages are environment specific.
You can either specify it using the /endpointName:xyz if you're using the host. Or pass in your own func of string.
http://andreasohlund.net/2012/01/27/convention-over-configuration-in-nservicebus-3-0/
That said having the different environments only separated by a convention is usually a bad idea
http://www.udidahan.com/2010/06/05/server-naming-and-configuration-conflicts/
I'm looking for some function that will decode a good amount of HTML entities.
Reason is I am working on some code to take HTML content and turning it into plain text, the issue that I have is a lot of entities do not get converted using HttpUtility.HtmlDecode.
Some examples of entities I'm concerned about are , &, ©.
This is for .net 3.5.
Then maybe you will need the HttpUtility.HtmlDecode?.
It should work, you just need to add a reference to System.Web.
At least this was the way in .Net Framework < 4.
For example the following code:
MessageBox.Show(HttpUtility.HtmlDecode("&©"));
Worked and the output was as expected (ampersand and copyright symbol).
Are you sure the problem is within HtmlDecode and not something else?
UPDATE: Another class capable of doing the job, WebUtility (again HtmlDecode method) came in the newer versions of .Net. However, there seem to be some problems with it. See the HttpUtility vs. WebUtility question.
Use WebUtility.HtmlDecode included in .Net 4
For example, if I run in a console app:
Console.WriteLine(WebUtility.HtmlDecode(" , &, ©"));
I get , &, c
We use .NET Web Services--both non-WCF and WCF, though the overwhelming majority is non-WCF, for legacy reasons--pretty heavily, and as I was testing something in Fiddler, I noticed that the response body size was pretty large. Then I noticed that the request headers didn't have any Accept-Encoding headers.
After doing some digging, it appears that the default value for the property HttpWebClientProtocol.EnableDecompression (from the class of which all wsdl.exe-originated WS stubs derive) changed between .NET BCL versions 2.0 and 3.0. I'm curious as to the reason (which may be WCF-related), and further as to whether there are any other [pretty] fundamental changes that are pretty quiet when you simply link against a different library.
Take a look at this connect link. The first comment from Microsoft states the following:
Please also note that as part of the
fixed we changed the default value of
EnableDecompression to be false by
default. We were concerned that having
it on by default would break existing
customers that had implemented
decompression on top of ASP.NET Web
Services in v1.1.
It looks like the change was a result of a bug that they needed to fix.