Incorrect date formatting when VB program opened via C#

Question

What's going on:

I maintain a few small .NET applications for a local business. We've got one pair of apps that work in tandem: a "client manager" (C# / .NET 4.? / winforms) and a "label printer" (VB / .NET 2.0 / winforms).

I recently added a "Print Labels" button to the client manager. This opens the label printer & pre-populates the client's name from the client manager. Woohoo!

Unfortunately, only when the label printer is opened this way, dates print out in "dd/MM/yyyy" format, instead of "MM/dd/yyyy".

What I know:

• Date is entered via a DateTime winforms input in the label printer that defaults to "Today".
• We see the formatting bug whether the default date is left or is manually changed.
• We don't send the date over from the client manager.
• We use ".ToShortDateString" in the label printer app.
• This never happened when opening the label printer by double-clicking the shortcut/EXE.
• This only happens on our Windows 7 Panasonic Toughbook.
• The date is wrong whether I print to our Dymo label printer or to PDF. (Thanks, @jdweng!)
• Per the Task Manager, the label printer runs as the only local user no matter how I load it. (Thanks, @Polyfun!)
• The label printer's CurrentCulture and CurrentUICulture are both en-US, no matter how I load it. (Thanks, @Jimi!)
• The user profile uses M/d/yyyy via "Control Panel > Region". (Thanks, @Hans Passant!)

Relevant Code

Here's the C# code I'm using in the client manager to open the label printer app (comments added for clarity):

 private void btnLabels_Click(object sender, EventArgs e)
 {
    // Set via a hybrid string/file input in the app's "Options" menu.
    string labelAppLocation = Properties.Settings.Default.LabelAppLocation;

    if (String.IsNullOrEmpty(labelAppLocation))
    {
      MessageBox.Show("We're not sure where your label printer app is located! Set this in \"Options >> Manage Lists >> Files\" and try again.");
    }
    else
    {
      Process p = new Process();
      ProcessStartInfo psi = new ProcessStartInfo();
      psi.FileName = labelAppLocation;

      // This class has some formatting helpers for the 
      // client's name and other demographics we'd like to send later. 
      LabelArgs newLabelArgs = new LabelArgs();
      newLabelArgs.Name = this.clientName.Text;
      psi.Arguments = newLabelArgs.ToString();

      p.StartInfo = psi;
      p.Start();
    }
  }

And here's the VB code in the label printer where the date value gets added to the label:

Private Sub DrawItemLabel(ByVal e As System.Drawing.Printing.PrintPageEventArgs)
     Dim g As Graphics = e.Graphics
     'Custom font handler
     Dim fonts As New ItemLabelFonts 

     '...set fonts, set other line items...

     ' `myDate` comes directly from a DateTime input's `.Value`.
     Dim strMidLine As String = myDate.ToShortDateString & "   " & myClientID & "   " & myCounty
     fonts.MiddleFont = ChooseMaxFontForWidth(strMidLine, fonts.MiddleFont, maxWidth, g)

      '...do some math for spacing before drawing the label...

       g.DrawString(myClientName, fonts.BottomFont, Brushes.Black, 0, bottomTop)
  End Sub

What I think:

• Maybe Process#Start() is losing the current culture and falling back to a dd/MM/yyyy default somewhere? (Confirmed not from user's "Region" settings)
• Maybe .NET 4.x & .NET 2.0 aren't playing nicely?
• Maybe the label printer behaves differently when passed arguments and I need to add a user profile or region through those? There's no logic in the form's Load hook to account for this.

What I've tried:

• Checking the DateTime input's settings for a region fallback.
• Changing my user's regional settings to see if I can "reset" the formatting.
• Duplicating the behavior in Windows 10 & Windows XP (with no luck!)
• Turning it off & back on again.
• Poring over MSDN.

Why could opening an app via new Process().Start(); change its date formatting?

Answer 1

Success! I retargeted the label printer app from .NET 2.0 to .NET 4.0 (matching the client manager app), cleared out new warnings, and rebuilt the app. Running the v4.0 version of the label printer fixes the issue with no obvious side effects.

I should have done this sooner - I expected going from 2.0 to 4.0 to be a big task, but there were no build errors and the only warnings were implicit conversions. None of these affected Date variables, so I'm still unclear why the 2.0 version acted so strangely, but I'm glad to put this bug to bed. I don't intend to write any new .NET 2.0 projects anytime soon!

Answer 2

I think we're missing something for the Region/Date/Timezone format - somewhere hidden.

I've got a Powershell script to set the date to Australian. Here is the code and XML: https://github.com/averkinderen/Azure/blob/master/101-ServerBuild/AURegion.xml

#Set Windows regional format (date/time etc.) to Australia - this applies to all users

# Set Locale, language etc.
& $env:SystemRoot\System32\control.exe "intl.cpl,,/f:`"C:\temp\AURegion.xml`""

# Set Timezone
& tzutil /s "AUS Eastern Standard Time"

# Set languages/culture
Set-Culture en-AU 

$currentlist = Get-WinUserLanguageList
Write-Host "new lang" $currentlist.LanguageTag

Then I searched for an USA version and I found it here: https://poorerleno.blogspot.com/2018/07/remote-patching-1.html?_sm_au_=i7VM8snvHjkLnPvjBJ3vvK7RJCBJt

#Set Windows regional format (date/time etc.) to American - this applies to all users

if (!(test-path c:\temp)) {
New-Item c:\temp -ItemType Directory
} 

[xml]$XmlDocument = invoke-webrequest -Uri https://raw.githubusercontent.com/poorleno1/systemlocale/master/USRegion.xml -UseBasicParsing | Select-Object -ExpandProperty content

$XmlDocument.Save("c:\temp\USRegion.xml")

# Set Locale, language etc.
& $env:SystemRoot\System32\control.exe "intl.cpl,,/f:`"C:\temp\USRegion.xml`""

# Set Timezone
& tzutil /s "Central European Standard Time"

# Set languages/culture
Set-Culture en-US

$currentlist = Get-WinUserLanguageList
Write-Host "new lang" $currentlist.LanguageTag