The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 1,470 other followers

Archive for the ‘C#’ Category

from a WSDL import: empty “Reference.cs” – Google Search

Posted by jpluimers on 2019/01/10

A search for empty “Reference.cs” – Google Search seems to indicate this happens with referenced types that – despite turning off that option – from the Visual Studio 2017 IDE sometimes results in an empty Reference.cs.

My solution: import in an empty project, then move the reference to the existing project and add it.

[WayBack] c# – Sometimes adding a WCF Service Reference generates an empty reference.cs – Stack Overflow


Posted in .NET, C#, Development, Software Development, Visual Studio 2015, Visual Studio 2017, Visual Studio and tools | Leave a Comment »

Take C# 8.0 for a spin | .NET Blog

Posted by jpluimers on 2018/12/06

[WayBack] Take C# 8.0 for a spin | .NET Blog: A first-hand look from the .NET engineering teams


download and install Preview 1 of .NET Core 3.0 and Preview 1 of Visual Studio 2019.

or with Visual Studio Code

[WayBack] Bill Wagner on Twitter: “@cecilphillip @MadsTorgersen @VisualStudio @code Yes, install .NET Core 3 preview, add the 8.0 element and it works fine.”

Then play around with:

  • Nullable reference types
  • Ranges and indices
  • Asynchronous streams

Via: [WayBack] Mads Torgersen on Twitter: “I blogged a little walkthrough of the three major C# 8.0 features (nullable reference types, range and index expressions and async streams) shipping in Preview 1 of @VisualStudio 2019 and Preview 1 of .NET Core 3.0. Hope you like it!”


Read the rest of this entry »

Posted in C#, C# 8, Development, Software Development | Leave a Comment »

An In Depth Guide Into a Ridiculously Simple API Using .NET Core

Posted by jpluimers on 2018/11/27

Since I am going to be involved with building some REST API servers and clients in .NET, here are some links to get me up to speed.

Posted in .NET, .NET ORM, ASP.NET, C#, Development, EF Entity Framework, NHibernate, Software Development | Leave a Comment »

Finding your program with an “Access Denied” (Error code 5) after lunch break…

Posted by jpluimers on 2018/10/24

Via: [WayBack] I just returned from lunch break and found my program faulted with an “Access Denied” (Error code 5) error in a call to Mouse.GetCoursorPos and was wond… – Thomas Mueller (dummzeuch) – Google+:

All of [WayBackGetCursorPos, [WayBackGetCursorInfo and [WayBack] GetKeyState can cause an “Access Denied” (Error code 5) when they do not have permission for the current desktop (for instance the logon desktop when a screen-saver has kicked in).

Solution: write a wrapper around it then [WayBack] patch calls going to the original into the patch [WayBack] delphi – Explain errors from GetKeyState / GetCursorPos – Stack Overflow


Posted in .NET, C#, C++, Delphi, Development, Software Development, Windows Development | Leave a Comment »

Delphi XE6 and up regression: “‘9999-12-31 23:59:59,1000’ is not a valid date and time” when passing a SOAP message with 9999-11-31T23:59:59.9999999; QC144171

Posted by jpluimers on 2018/09/06

A valid SOAP message with <urn:timeStamp>9999-11-31T23:59:59.9999999</urn:timeStamp> in a xs:dateTime field return '9999-12-31 23:59:59,1000' is not a valid date and time from a Delphi application with this SOAP response:

<SOAP-ENV:Envelope xmlns:SOAP-ENV="" xmlns:xsd="" xmlns:xsi="" xmlns:SOAP-ENC="">
      <faultstring>'9999-12-31 23:59:59,1000' is not a valid date and time</faultstring>

The reason is this exception:

exception class EConvertError with message ''9999-12-31 23:59:59,1000' is not a valid date and time'.

This is from a .NET based test case passing in timeStamp = DateTime.MaxValuewhich is handled perfectly fine by other SOAP web services tested.

I know about different resolutions of time stamps, but would never expect the 999.9999 milliseconds to be rounded up to 1000 as it is always safer to truncated away from an upper limit.

A test using Soap UI [WayBack] with this parameter finally worked (max 3 digits second fraction):


The true origin of problem is in this method in the Soap.XSBuiltIns unit which has been unchanged since at least Delphi 7:

function TXSBaseTime.GetMilliSecond: Word;
  Result := Round(FractionalSeconds*1000);

The problem exposed itself because as of Delphi XE6 the core of function TXSBaseCustomDateTime.GetAsDateTime piece was changed from

Result := EncodeDateTime(Year, Month, Day, Hour, Minute, Second, 0);


Result := EncodeDateTime(Year, Month, Day, Hour, Minute, Second, Millisecond);

A combination of lack of test cases and understanding XML specifications failed to reveal this bug.

The standards specify (among others):

  • '.' s+ (if present) represents the fractional seconds;
    The above is not limiting the amount of digits, not talking about milliseconds either.
  • All ·minimally conforming· processors ·must· support year values with a minimum of 4 digits (i.e., YYYY) and a minimum fractional second precision of milliseconds or three decimal digits (i.e. s.sss). However, ·minimally conforming· processors ·may· set an application-defined limit on the maximum number of digits they are prepared to support in these two cases, in which case that application-defined maximum number ·must· be clearly documented.
    Delphi not only limits the fractional second precission, it changes the limit over time and does not document the limit. Three strikes…
  • s -- represents a digit used in the time element "second". The two digits in a ss format can have values from 0 to 60. In the formats described in this specification the whole number of seconds ·may· be followed by decimal seconds to an arbitrary level of precision. This is represented in the picture by "ss.sss". A value of 60 or more is allowed only in the case of leap seconds.
    Given buggy the fractional second handling through milliseconds, the leap second handling is ripe for a test case as well.
    Strictly speaking, a value of 60 or more is not sensible unless the month and day could represent March 31, June 30, September 30, or December 31 in UTC. Because the leap second is added or subtracted as the last second of the day in UTC time, the long (or short) minute could occur at other times in local time. In cases where the leap second is used with an inappropriate month and day it, and any fractional seconds, should considered as added or subtracted from the following minute.

The reproduction is quite simple:

Read the rest of this entry »

Posted in .NET, C#, Conference Topics, Conferences, Delphi, Development, Event, SOAP/WebServices, Software Development, XML, XML/XSD | Leave a Comment »

%d bloggers like this: