The Wiert Corner – irregular stream of stuff

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

  • My work

  • 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,331 other followers

Archive for the ‘.NET’ Category

C# – All About Span: Exploring a New .NET Mainstay

Posted by jpluimers on 2017/12/28

Interesting new .NET feature already available for .NET 4.5, but much faster in future .NET versions: [WayBackC# – All About Span: Exploring a New .NET Mainstay

Documentation (only quoted first paragraph):

Span<T> is a new type we are adding to the platform to represent contiguous regions of arbitrary memory, with performance characteristics on par with T[]. Its APIs are similar to the array, but unlike arrays, it can point to either managed or native memory, or to memory allocated on the stack.

Further on in that document are the Design specifications.

Via:

–jeroen

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

c# – Why does Try-Catch require curly braces – Stack Overflow

Posted by jpluimers on 2017/12/27

From my SO Question Archive:

Just curious: Why is the syntax for try catch in C# (Java also?) hard coded for multiple statements? Why doesn’t the language allow:

int i;
string s = DateTime.Now.Seconds % 2 == 1 ? "1" : "not 1";
try
   i = int.Parse(s);
catch
   i = 0;

The example is for trivial purposes only. I know there’s int.TryParse.

[WayBackc# – Why does Try-Catch require curly braces – Stack Overflow.

I asked this question partially because of my Delphi background where there are two try statements (one for finally and one for except a.k.a. catch) neither having the braces problem as try/finally/except all are block boundaries.

The most interesting bit was the [WayBackanswer by [WayBack] Eric Lippert (ex C# compiler team, now at Facebook after an intermediate position at Coverty) referring to his [WayBackWhy are braces required in try-catch-finally? | Fabulous adventures in coding  blog entry.

The answer and blog entry come down to preventing ambiguity.

His answer reveals that a compound try/catch/finally statement is converted by two try statements like this:

try
{
  try
  {
      XYZ();
  }
  catch(whatever)
  {
     DEF();
  }
}
finally
{
  ABC();
}

This emphasises that catch and finally are conceptually indeed two different things which statistics show.

I need to dig up the numbers (I remember researching this for Java and Delphi code a very long time ago – think Delphi 7 era – and C# code a long time ago – think C# 2 era), but this comment should still hold:

My observation in most code I’ve seen is that the combination of catch and finally is hardly (i.e. far less than 1%) used in the same statement (or in other languages in nested statements), because they serve two very different purposes. That’s why I prefer not to mix them, and if I do, use the nested construction to both emphasize the difference in purpose, and execution order. Learning new things every day: How often is your occasionally percentage wise? – Jeroen Wiert Pluimers Dec 23 ’12 at 19:34

–jeroen

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

Head scratching with a TargetParameterCountException | Software on a String

Posted by jpluimers on 2017/12/26

Ever introduced an extra parameter on a method, tracked all its usages and made the compiler happy by providing a corresponding extra argument in all the calls of that method? Sure you have…

Things like that need a reminder: the joy of reflection and lambdas…

Very good train of thought (and solving!) at [WayBackHead scratching with a TargetParameterCountException | Software on a String

By [WayBackMarjan Venema – Google+

–jeroen

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

WinHTTP Cipher restrictions to TLSv1.2 does not work on Windows7, Server 2008 R2 and Server 2012…

Posted by jpluimers on 2017/12/18

This will bite me some time for sure, so for my link archive: [WayBack] TRestClient and Cipher restrictions to TLSv1.2 does not work on Windows7 and Server2008R2 … and how it can be solved… – Günther Schoch – Google+

References:

For at least some Windows 7 and Server 2008 R2 systems, that update (KB3140245) doesn’t automatically turns up in the Windows Update list.

To make matters worse, the page cannot be archived in either the WayBack machine or Archive.is (I tried multiple times with empty results).

Luckily, there is a copy at [WayBack] KB3140245 DefaultSecureProtocols – Security.NL.

After installing the update, you have to ensure you set the DefaultSecureProtocols registry value to the bitmap value that indicates with SSL/TLS versions you want to support:

The DefaultSecureProtocols registry entry can be added in the following path:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp

On x64-based computers, DefaultSecureProtocols must also be added to the Wow6432Node path:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp

The registry value is a DWORD bitmap. The value to use is determined by adding the values corresponding to the protocols desired.

DefaultSecureProtocols Value Protocol enabled
0x00000008 Enable SSL 2.0 by default
0x00000020 Enable SSL 3.0 by default
0x00000080 Enable TLS 1.0 by default
0x00000200 Enable TLS 1.1 by default
0x00000800 Enable TLS 1.2 by default

For example:

The administrator wants to override the default values for WINHTTP_OPTION_SECURE_PROTOCOLS to specify TLS 1.1 and TLS 1.2.

Take the value for TLS 1.1 (0x00000200) and the value for TLS 1.2 (0x00000800) then add them together in calculator (in programmer mode), the resulting registry value would be 0x00000A00.

–jeroen

Posted in .NET, Delphi, Development, Power User, Software Development, Windows, Windows 7, Windows Server 2008 R2 | 2 Comments »

What is thread safety anyway?

Posted by jpluimers on 2017/12/13

A nice article [Archive.is] What is thread safety anyway? with a kind reference to the Deadlock Empire translation from C# to Delphi that I made.

In any language, multi-threading is hard, so I really love the quote below:

[WayBack] Multithreading can be hard to do right. The most common point of failure is assuming some code is thread safe when it actually is not... – Dalija Prasnikar – Google+

It reminded me of an old one:

A programmer had a problem. He thought to himself, “I know, I’ll solve it with threads!”. has Now problems. two he

–jeroen

Posted in .NET, C#, Delphi, Development, Fun, Multi-Threading / Concurrency, Quotes, Software Development, T-Shirt quotes | Leave a Comment »

 
%d bloggers like this: