I have an old and heavy windows application where DateTime.TryParse(string value, out result) is used extensively.
The below code runs smoothly on Windows 7 and Windows 10.
// Below is done when the application starts
System.Threading.Thread.CurrentThread.CurrentCulture = new CultureInfo("en-AU");
var success = DateTime.TryParse("20 02", out result);
// Above is just an example of one of the ways we have been using it. Here success is true and results are -> 20/02/2020 12:00:00 AM
But above statement returns false when executed on Windows Server 2012 R2 Standard.
Appears like Win Server 2012 has broken the
DateTime.TryParse. Interestingly if I use .netFramework 3.5 then it works in all OS. But we are on framework v4.6.2 (VS-2019).
Is this a bug in Microsoft OS or .netFramework 4.6? Is there any existing workaround for this without making any changes in code, maybe a .net framework patch, etc. Honestly, it will be difficult for me to make any changes in code related to this as its usage is more than 1.5k in the application.
Thanks in advance !!!
Maybe not the answer, but can you try this on your Windows Server 2012 R2.
foreach (var ci in CultureInfo.GetCultures(System.Globalization.CultureTypes.AllCultures).OrderBy(ci => ci.Name))
{
Console.WriteLine("{0} ({1})", ci.Name, ci.EnglishName);
}
are you culture part of that list?
Read this: https://learn.microsoft.com/en-gb/openspecs/windows_protocols/ms-lcid/a9eac961-e77d-41a6-90a5-ce1a8b0cdb9c
Or do this: https://learn.microsoft.com/en-us/archive/blogs/shawnste/locale-builder-v2-0-for-windows-8-1server-2012-r2-released
Related
I recently started having a problem with CultureInfo in my web application.
The code in question:
public static CultureInfo ConvertToCultureInfo(this string input)
{
try
{
return new CultureInfo(input);
}
catch (Exception)
{
return new CultureInfo("en-US");
}
}
When a user whose locale is 'en-AT' is accessing my website the request for this cultureinfo works on my local but is failing on my Windows Server 2012 box (and falling back to en-US, which is incorrect).
We tracked it down to an issue with the MS-LCID version 10.1 but this is allegedly only available for Windows Server 2016.
However, this occurs to me as kind of silly - why can't we just download a package that updates the existing LCID to support the newer locales? It's still the same list of dateformats and Windows Server 2012 is still supported. I can't find any resources on updating this and was hoping someone here knew a bit about this and could point me in the right direction.
Right now my best lead is to additionally test for custom CultureInfos and supply my own formats, but this seems like overkill when there exists the LCID, it's just somewhat out of date.
it is a web page (Asp.Net MVC), multi-language including english, latvian, lithuvian, russian, polonia.
For selecting a date we choose the jQuery-Ui-datepicker including extra localization files for each language. (Date is given as string: "DateTime".ToString("d", new CultureInfo("lv")) )
All runs fine with all languages at my development computer (Win10, DotNet 4.5, Visual Studio 2012).
Running the web application at the server (Windows Server 2012 R2) other languages without problems. But the latvian language leads to problems.
I added trace code around the CultureInfo for Latvian 'lv'.
There is an difference between the CultureInfo.DateTimeFormat.ShortDatePattern between development notebook and web Server.
CultureInfo.DateTimeFormat.ShortDatePattern
- my computer: 'dd.MM.yyyy'
- web server : 'dd.MM.yyyy.'
the fastest solution would be: trim final point at datetime format.
(the javascript seems to work without the 'final point')
Is it a Framework Bug ?
which system needs a fix ? the server or my computer (inclusing javascript datepicker localization source)
How to solve it in a nice way (so it doesnt seems hacky)
thanks,
Mathias
While c# is not my primary programming language, I'm maintaining such a program for a couple of years now. This program connects to a device on a serial port and works from Windows XP up to 8.1. One specific "feature" is that it uses .NET Framework 2.0.
With some users upgrading to Windows 10 we've got complains that the program cannot detect/open the COM port of the device. We have confirmed this on our own test systems with clean Win10 installation.
It turns out that the function SerialPort.GetPortNames() returns incorrect port names and adds 'strange' characters after the port name.
For example:
COM3吀
COM3䡢
COM3゠
Etc. When I refresh the list, every time another character (or two) shows up after the number.
The test code is super straightforward:
string[] portNames = System.IO.Ports.SerialPort.GetPortNames();
log("Available ports:");
foreach (string PortAvailable in portNames)
{
log(PortAvailable);
}
Where the log function mearly adds a line to a standard TextBox on the form:
txtLog.Text += Msg + Environment.NewLine;
This works in every other Windows version.
I've checked the registry and all looks fine there also.
Does anybody has an idea about this?
I'm suspecting that .NET Framework 2.0 is not 100% compatible anymore, although you can enable it in the Windows features and it seems that the program itself runs fine (besides my serial port problem). I'm a bit scared to upgrade to a newer .NET, let alone that we've VisualStudio 2008 for c# (max=.NET 3.5). Note that the program still needs to run on Windows XP also (POS version is still maintained by Microsoft).
ADDED:
I've "upgraded" a test program to .NET 3.5, and still having exactly the same issue.
Next step is to install a new VisualStudio (it appears that it is free nowadays?? Should I check for privacy settings in Studio also? ;-).
ADDED 2:
Installed VisualStudio 2015 and made multiple builds with different .NET framework versions. v2.0 and 3.5 still adding the strange character. But in v4.0 and up this issue seems te be solved! Now to get the original program compiled and working for the newer Framework.
But I find this issue really strange and would expect that this would hit more .NET functions and more programs.
I've seen the strange characters too. My solution is using Regular Expressions to filter out the number portion of the comm port name.
Dim ports As New Devices.Ports
For Each s As String In ports.SerialPortNames
s = Regex.Replace(s, "\D*(\d+)\D*", "$1")
Debug.WriteLine(s)
Next
I've had this exact same problem with USB CDC serial devices, handled by the new rewritten Windows 10 usbser.sys driver.
The garbage characters are often digits, so removing non-digits isn't a reliable way to work around it. For my solution, look at my last post on this thread here:
https://social.msdn.microsoft.com/Forums/vstudio/en-US/a78b4668-ebb6-46aa-9985-ec41667abdde/ioportsserialportgetportnames-registrykeygetvalue-corruption-with-usbsersys-driver-on-windows?forum=netfxbcl
..there is code there that'll go through the registry, find usbser ports, and return their unmangled names. Beware that it doesn't return all serial ports, just ones provided by that driver. The code works on Windows XP through to 10.
The underlying problem is that the usbser.sys driver creates a registry entry, and on .NET (at least up to 3.5) the GetPortNames() function tries to read those registry keys and gets corrupted data. I've reported this to Microsoft, both via that forum (assuming they read it) and using the built-in Windows 10 beta error reporting tool. Maybe one day there will be a fix.
As you say the program works after enabling the windows feature:
.NET 2.0,3.0,3.5 isn't enabled by default on Windows 8/8.1/10. The files aren't stored on the install media/wim.
It can be enabled with the DISM command from windows update or a local source.
DISM /Online /Enable-Feature /FeatureName:NetFx3 /All
check this out: http://forums.radioreference.com/uniden-tech-support/317887-windows-10-uniden-usb-driver-5.html
For a work around to fix the Win 10 serial port not working caused by strange characters after the port name.
Go in to the Registry with regedit.exe.
Navigate to "HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALC OMM"
Make note of the comm port name.
Append a "0" or any character to the comm port name.
Change the comm port name back to what it was in step 3.
It worked for me.
Baldur
string[] ports = SerialPort.GetPortNames();
for (int i = 0; i<ports.Length;i++)
{
string mystr = ports[i];
if (((mystr[mystr.Length-1]) >= 0x30) & ((mystr[mystr.Length-1]) <= 0x39))
{
}
else
{
mystr = mystr.Remove(mystr.Length-1);
}
ports[i] = mystr;
}
We are seeing bizarre behavior with .NET 4.5 and System.DateTime. The behavior of ToLocalTime() when applied to DateTime objects with Kind=Utc seems different on Server 2008R2 machines with .NET 4.5 compared with .NET 4.0. Even more bizarre, the problem does not manifest on developer PCs with .NET 4.5 installed.
Does anyone have an explanation for this behavior? I can't turn up any bug reports on Microsoft sites. We can use a more complicated approach to convert times that works, but it's hard to ensure no one ever uses .ToLocalTime() in the future.
Developer PC - Windows 7, VS2012, .NET 4.5 installed during VS2012 install:
unixEpoch 621355968000000000 Utc
asLocal1 635121441023588986 Local
asLocal2 635121441023588986 Unspecified
Production Server 1 - Server 2008R2, .NET 4.0
unixEpoch 621355968000000000 Utc
asLocal1 635121441023588986 Local
asLocal2 635121441023588986 Unspecified
Production Server 2 - Server 2008R2, .NET 4.5 installed as standalone package
unixEpoch 621355968000000000 Utc
asLocal1 ***635121405023588986*** Local
asLocal2 635121441023588986 Unspecified
Other than having .NET 4.5 installed, production servers 1 and 2 are identical. The problem manifests when run in several different local timezones around the globe.
Sample code that demonstrates the problem:
using System;
using NUnit.Framework;
namespace DateTimeToLocal
{
[TestFixture]
public class DateTimeFixture
{
private const long unixTimeInNanos = 1376561702358898611;
[Test]
public void Demonstrate()
{
DateTime unixEpoch = new DateTime(1970, 01, 01, 0, 0, 0, DateTimeKind.Utc);
DateTime utc = unixEpoch.AddTicks(unixTimeInNanos / 100);
// Method 1 - doesn't work on 2008R2 with .NET 4.5
DateTime asLocal1 = utc.ToLocalTime();
// Method 2 - works across all .NET 4.0 and .NET 4.5
TimeZoneInfo localTz = TimeZoneInfo.FindSystemTimeZoneById(TimeZoneInfo.Local.StandardName);
DateTime asLocal2 = TimeZoneInfo.ConvertTimeFromUtc(utc, localTz);
Console.WriteLine("unixEpoch {0} {1}", unixEpoch.Ticks,unixEpoch.Kind);
Console.WriteLine("asLocal1 {0} {1}", asLocal1.Ticks, asLocal1.Kind);
Console.WriteLine("asLocal2 {0} {1}", asLocal2.Ticks, asLocal2.Kind);
Assert.AreEqual(asLocal1, asLocal2);
}
public static void Main(string[] args)
{
var t = new DateTimeFixture();
t.Demonstrate();
}
}
}
This problem goes away when the following hotfix is applied to the server running 2008R2: http://support.microsoft.com/kb/2863058/en-us
It appears that under the hood, DateTime.ToLocalTime() uses a lookup technique that fails unless the timezone database update contained in that hotfix has been applied.
This was extremely hard to track down, and I've not seen ANY other web forum mentioning the link between that database update and something as fundamental as utc.ToLocalTime() failing for dates in August 2013, no where near a recent boundary that changed due to legislation, etc. in the Eastern U.S. Still wondering how exactly this is not being seen more places?
We have a server running a 6 day job that just reset, because Windows Update Agent (WUA) automatically rebooted the machine to install updates.
I would like to alter my C# app to warn the user if this setting is on in the future, so we don't end up suffering from random reboots, which forces a restart of said 6-day job, wasting 4 days of CPU time.
Does any know if it is possible to check within WUA that "Important Updates" is set to "Install updates automatically (recommended)", within C#?
There is an API for the Windows Update Agent (WUA), its general use is described at:
Install Windows Update Using C#
Here is the C# code:
// See http://techforum4u.com/entry.php/11-Install-Windows-Update-Using-C
var auc = new WUApiLib.AutomaticUpdatesClass();
if (auc.Settings.NotificationLevel ==
AutomaticUpdatesNotificationLevel.aunlScheduledInstallation)
{
Console.Write("{0}Warning W20120307-1107. Windows Update Agent (WUA) is capable of rebooting the PC automatically. Recommend switching this off for the duration of this 6-day batch process.\n", NPrefix());
}
After adding c:\WINDOWS\system32\wuapi.dll, if you get a compile error, see Interop type cannot be embedded.
Note that this approach will only work on Windows 7, add a try/catch around it to prevent a crash on Windows XP. See the forums for how to get it working on XP (you have to reference WUA version 1, WUA for Windows 7 is version 2).