Allowing Paste Linux Files Into a TextBox

If you are playing a lot with Linux, sooner or later you will see that pasting files produced by it will usually yield weird results on Windows as far as line ending goes.

You see, Linux uses Line Feed character (LF, ASCII 10) to signal the end of line. Windows uses a combination of Carriage Return and Line Feed (CRLF, ASCII 13+10). When Windows sees CRLF it will go to the next row. If it sees just LF, it will ignore it and you will see all in the same line unless application is a bit smarter. Unfortunately many are not.

Well, not much you can do about other people applications. However, you can ensure your application supports both CRLF and LF as a line ending. The only trick is to split text being pasted by CRLF, LF, and CR and to recombine it using CRLF (on Windows).

To catch paste, we can simply inherit existing TextBox control and override handling of WM_PASTE message:

internal class TextBoxEx : TextBox {
    protected override void WndProc(ref Message m) {
        if (m.Msg == NativeMethods.WM_PASTE) {
            if (Clipboard.ContainsText()) {
                var lines = Clipboard.GetText().Split(new string[] { "\r\n", "\n", "\r" }, StringSplitOptions.None);
                this.SelectedText = string.Join(Environment.NewLine, lines);
            }
        } else {
            base.WndProc(ref m);
        }
    }


    private static class NativeMethods {
        internal const Int32 WM_PASTE = 0x0302;
    }
}

Whenever you use TextBoxEx instead of TextBox, you will have your multiline paste working whether line ends in CRLF, LF, or even long-forgotten CR.

Visual Studio 2017

After a long wait, Visual Studio 2017 is here.

Even better, if you download it until March 14 (π), you will get 60 days of Xamarin Univerity for free. But wait, that is not all - if you react now, there is a knife set just waiting… :)

First thing you will notice is a new installer. Yes, you could already see it during RC phase, but this one got a bit more options and new, a bit uglier :), interface. You might be temporarily scared a bit when you notice there are no ISO files to download. Fear not - you can still make an offline installer yourself. However, do notice that downloading everything will be around 24 GB (77 GB when installed). You might want to consider limiting yourself to just the workloads you need.

Full list of features you can find in release notes but I can already guess that most of people are interested into C# 7. My personal favorite is actually possibility to declare out variables in-line. Yes, I know that out variables should be used sparingly as quite often people get puzzled by them. However when you do lot of parsing, out variables can actually be the cleanest way to get something out without introducing helper class explosion. Other features in C# 7, local functions, is expressions, value tuples, ref returns…, are following the same line of simplifying the code without introducing extra fluff.

Additionally .NET Core finally got integrated properly into Visual Studio. I am all ok with doing ghetto project creation but there is something to be said about getting the big guns out when necessary. Debugging comfort simply does not compare between the two in my opinion.

Of course, there are some already known issues but I found nothing of real significance. I admit not being to clone SSH repository does sound damning but realistically most of time you are going to do that from command line and not from Visual studio so that doesn’t really count :P. Also, don’t forget to install .NET Framework 3.5 development tools if you have any legacy .NET 2.0 applications - otherwise they will be marked as 4.0.

I personally already moved to Visual Studio 2017 Community Edition but that might have not been a huge step as I dabbled in Release Candidate too. As for you, what are you waiting?

PS: Unfortunately Express editions are still not available but there is a positive confirmation they are coming really soon.

PPS: Xamarin University offer is actually not that impressive - it is pretty much useless as anything interesting requires subscription upgrade.

[2017-09-15: Express 2017 for Windows Desktop (preview) is available!]

[2017-10-16: Express 2017 for Windows Desktop is here - albeit for the last time.]

Cancelling Column Width Change for ListView Control

While I usually appreciate ability of ListView to adjust column widths, there are situations when I want it fixed to certain size.

For this occasion I already had column size fixed:

column.Width = listView.ClientRectangle.Width - SystemInformation.VerticalScrollBarWidth;

One would think that cancelling ColumnWidthChanging would be sufficient, e.g.:

private void listView_ColumnWidthChanging(object sender, ColumnWidthChangingEventArgs e) {
    e.Cancel = true;
}

However, this will not work. Column width will stay fixed while you are moving mouse around only to change once you release the mouse button. To cancel column width, we need to reset the size too:

private void listView_ColumnWidthChanging(object sender, ColumnWidthChangingEventArgs e) {
    e.Cancel = true;
    e.NewWidth = listView.Columns[e.ColumnIndex].Width;
}

A bit more code then I would personally expect, but easy enough.

Go

After sticking with C# and its ugly step-mother Java for a while, I though it was a time to check out a new language. One that seemed interesting was Google’s Go, a simple garbage-collected, strongly-typed, and C-like language supporting Linux and Windows.

Go syntax itself is really friendly and suits me well. There are only a couple of statements around and you should know them from C, semicolon is optional at many places, and in-place variable initialization is a treat. Yes, x := 5 is not really superior to var x = 5; nor it saves you a lot of keystrokes. However, syntactic sugar is what makes or breaks a language in my opinion. And such lazy variable initialization is nice to have.

Cross-compilation is reasonably easy with just a few environment variables (GOARCH and GOOS) that need adjusting. As it is statically linked, you can count on having no additional dependencies whatsoever. One binary is all it takes. Yes, binary is a bit bigger even for the simplest of things but I’m perfectly fine with that if I can avoid .dll hell.

Speaking of compilation, it is annoying. Compiler is simply too aggressive with warnings. Great example is if you initialize variable and you don’t use it later. Damn compiler will complain and refuse to do its work. If you have unused import, the same thing. It will simply stop at any warning. One might say this is the correct behavior and that it will help you to write better code. That hypothetical guy should burn in hell next to guy who created this compiler.

Since proper debugging tools for this language are nonexistent, you are pretty much forced to use generous peppering of printf statements throughout the code together with liberal commenting out so that you can pinpoint the error. And guess what happens as you debug it? Damn compiler refuses to work just because I am no longer needing one variable I used for debugging or because I am importing package use of which is currently commented out.

And those are errors compiler correctly identifies and it could correct itself. Variable not used? Report me a warning because it might be me making a typo but compile the damn program so I can continue to debug. Same for extra package - if you are so smart to report it is unused, remove the damn thing yourself and compile. It is impossible to describe how annoying these warning are during writing and debugging of program. ANNOYING.

Syntax of Go is mostly pleasant with a couple of weird decisions most notable of which is to have variable type after the variable name, as in func x(dummy int). While designers do offer an explanation, to me frankly it seems as changing stuff just to be different. Yes, it might be more correct way of doing things but it goes against muscle memory of every developer on earth. Same goes for decision to use nil instead of null. Why?

Go is not object-oriented language and I am not really sure how I feel about it. A wonders can be done without full OO support, especially when it comes to small tools I was using it for. What I was missing were two features usually connected to OO languages.

First one is syntactic sugar of method calling syntax. I find myStr.TrimSpace() as superior compared to strings.TrimSpace(myStr). While they can both serve the same function, I find former much easier to both write and read. I sort-of expected Go to have something similar to C# extension methods where you essentially just use OO syntax for non-OO concept.

Second is method overloading. Yes, I know Go creators have excuse for this too. Who knows, they might even be technically correct. However, the need to have slightly different name for each method taking similar parameters is annoying. Have they allowed optional parameters maybe I would feel different about it but, as it is implemented now, I find this decision hurting the language.

Lastly among complaints is lack of globalization features throughout the language. It could be at least partially due to the lack of overloading but all globalization features feel as an afterthought and not as the part of language. Good luck localizing this.

As you might have guessed, I don’t find Go a particularly well designed language. I do like some of its features (especially the ease of cross-compiling) but general discomfort during development will keep it as tool of choice only when I want a single binary with minimal impact to the rest of system and not for much else.

Visual Studio in Small

With Visual Studio 15 release getting close, a lot of new features are seeing the light of a day. One feature that doesn’t get deserved attention is the new installer shown to the world on Build 2016 conference.

It is a simple and tiny (in Visual Studio terms) installer. Executable is under 1 MB and it gets all other components from the Internet. On its own it is not a news, but some optimization magic has been happening there so your downloads are reasonably small (again, in Visual Studio terms). I am sure as release day grows closer some things might gain some “fat” but idea is there. I just hope they will still allow you to install it from media too - having Visual Studio download itself multiple times for multiple computers kinda nullifies smaller downloads.

You can give it a test run yourself and see whether it improves your workflow.

POST Cannot Be Redirected

Few days ago I’ve found a bug in a program of mine. As I have feedback built-in in most programs, I decided to use it for once. And failed. All I’ve got was an error message.

A bit of troubleshooting later and I’ve narrowed the problem down. It would work perfectly well over HTTPS but it would fail on HTTP. Also it would fail when redirected from my old domain, whether it was HTTP or HTTPS. And failure was rather unusual error code 418. That was an error I’m often using to signal something wrong with redirects. A bit of a digging later, I’ve noticed I was using POST method for my error reporting (duh!).

You cannot redirect POST requests. And I was doing server-side redirecting (or trying to) from my old domain to a new one and from HTTP to HTTPS.

At the end I’ve changed all my programs to use HTTPS, temporarily disabled redirecting to allow HTTP-only connections, and I’ve had to re-enable same script on my old site so I can get error reports from old versions without update. I knew this last domain move has gone too smooth…

How to Secure Memory?

Sometime you might want to protect your data in memory - the greatest example is when dealing with anything related to passwords. It is simply not smart to keep that data around in a plain-text.

In .NET there are multiple methods you can use for this purpose, starting with SecureString, ProtectedMemory, and my favorite ProtectedData.

Each of these has its advantages and disadvantages and definitely each can find its place in a security toolbox. However, I prefer ProtectedData because it doesn’t require any Win32 API magic to read (as SecureString), nor it has any limitations on block length (as ProtectedMemory). As long as you are ok dealing with byte arrays, you can use it almost as a transparent storage.

Most of the times I end up having something like this (the most basic form):

private static RandomNumberGenerator Rnd = RandomNumberGenerator.Create();
private byte[] RawDataEntropy = new byte[16];
private byte[] RawData = null;

internal byte[] Data {
    get {
        if (this.RawData == null) { return new byte[0]; } //return empty array if no value has been set so far
        return ProtectedData.Unprotect(this.RawData,
                                       this.RawDataEntropy,
                                       DataProtectionScope.CurrentUser);
    }
    set {
        Rnd.GetBytes(this.RawDataEntropy); //new entropy every save
        this.RawData = ProtectedData.Protect(value,
                                             this.RawDataEntropy,
                                             DataProtectionScope.CurrentUser);
    }
}

On each write we let Windows encrypt the data using a random entropy (in addition to its standard encryption) while on every read we simply decrypt the data and return a copy of it. Care should be taken to delete copies lying around, i.e. when you set the property and encrypt data, you should delete the original. Best practice for delete is to use Array.Clear, e.g.:

Array.Clear(value, 0, value.Length);

I will leave it for reader’s exercise why that might be preferred to a simpler value = null.

PS: Note that, as soon as you convert bytes to a string (e.g. to show it to the user), you have signed capitulation as now you have an unencrypted copy of the protected data in memory. Yes, sometime you need to do it, but keep it brief.

File.OpenWrite Is Evil

.NET Framework is full of the small helper methods and I personally find this beneficial in general. They make code easier to read and most of the time they also make errors less likely. They also lend themselves beautifully to the quick troubleshooting one-liners as a nice, temporary, and concise solution. There is almost no greater example for that flexibility than File helper methods.

If you need to read the content of the file, just say

using (var fileStream = File.OpenRead(filename)) {
    //do something
}

Similarly, if you need to write something, equivalent code is

using (var fileStream = File.OpenWrite(filename)) {
    //do something
}

However, there is a trap in the last code chunk as it doesn’t necessarily do what you might expect. Yes, file is opened for writing, but existing content is untouched. To illustrate the issue, save first John in the file and then Mellisa. File content will be, as expected, Mellisa. However, if you save John again, the content will be somewhat unexpected Johnisa.

Once seen as an example, it is obvious computer did exactly what we’ve told it. It opened the file for writing and modified the content starting from the first byte. Nowhere did we tell it to discard the old content.

Proper code for this case would be slightly longer:

using (var fileStream = new FileStream(fileName, **FileMode.Create**, FileAccess.Write)) {
    //do something
}

This will ensure file will be truncated before writing the new content and thus avoid the problem.

Annoying thing about this helper is that, under normal circumstances, it will work most of the time, biting you only when you delete/shorten something. I believe there is a case to argue it should have been designed with FileMode.Create instead of FileMode.Write as a more reasonable behavior. However, as it goes with most of these things, decision has already been made and there is no going back.

Incremental Mercurial Clone

One both advantage and disadvantage of the distributed source control is repository containing the whole history. Upon the first clone, when all data must be downloaded, this can turn into an exercise in futility if you are on a lousy connection. Especially when, in my case, downloading a huge SVN-originating Mercurial repository multi-GB in size. As connection goes down, all work has to be repeated.

Game got boring after a while so I made following script for incremental updates:

@ECHO OFF

SET SOURCE=https://example.org/BigRepo/
SET REPOSITORY=MyBigRepo

IF NOT EXIST "%REPOSITORY%" (
    hg --debug clone %SOURCE% "%REPOSITORY%" --rev 1
)

SET XXX=0
FOR /F %%i IN ('hg tip --cwd "%REPOSITORY%" --template {rev}') DO SET XXX=%%i

:NEXT
SET /A XXX=XXX+1

:REPEAT
ECHO.
ECHO === %XXX% === %DATE% %TIME% ===
ECHO.

hg pull --cwd "%REPOSITORY%" --debug --rev %XXX% --update
SET EXITCODE=%ERRORLEVEL%
ECHO.
IF %EXITCODE% GTR 0 (
    SET FAILED=%EXITCODE%
    hg recover --cwd "%REPOSITORY%" --debug
    SET EXITCODE=%ERRORLEVEL%
    ECHO.
    ECHO ======= FAILED WITH CODE %FAILED% =======
    IF %EXITCODE% GTR 0 (
        ECHO ======= FAILED WITH CODE %EXITCODE% =======
    ) else (
        ECHO === SUCCESS ===
    )
    GOTO REPEAT
) else (
    ECHO.
    ECHO === SUCCESS ===
)

GOTO NEXT

Script first clones just a first revision and then incrementally asks for revisions one at a time. If something goes wrong, recovery is started following by yet another download. Simple and effective.

Forcing Compiled .NET Application to 32-Bit

.NET application compiled with Any CPU as a target and without “Prefer 32-bit” set, will run in 64 bits whenever it can. If application is developed and tested in that manner, this is actually a good thing. Even if you don’t care about a vastly more memory you can use, you should care about the fact Windows Server these days exists only in 64-bit flavor. Yes, with prefer 32-bit checked, your application is going to be capable of running on it. However, on all development machines you will run it in 32 bits and thus find some errors only once your application is running 64-bit on a (headless) server. Every developer should run his code in 64-bit. No excuses.

Saying that, if you stumble across a signed Any CPU .NET application that used to work on 32-bit OS just fine but stopped working with a move to 64 bits, you have a problem. Even if your environment does support 32-bit computing, stubborn code will hit bug again and again. If application was unsigned, you might go the route of editing binary directly. With signed binaries you’ll have to be a bit more sneaky.

One trick is to re-configure .NET loader:

C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\Ldr64.exe SetWow
 loading kernel32...done.
 retrieved GetComPlusPackageInstallStatus entry point
 retrieved SetComPlusPackageInstallStatus entry point
 Setting status to: 0x00000000
 SUCCESS

However, this is a machine-wide setting and requires administrator access.

Another way is cheating the system and creating a loader application with settings you want (e.g. x86). Then load destination assembly and simply start it:

var targetAssembly = Assembly.LoadFrom("AnyCpuApplication.exe");
targetAssembly.EntryPoint.Invoke(null, null);

As “proxy application” is 32-bit, .NET loaded will load assembly into its domain with the same settings and our problem is solved.

Example code is available.