Using Visual Studio Code for .NET Framework Projects in C#

As Visual Studio Code is the only completely free member of Visual Studio family now that Visual Studio Express is gone (and no, Community edition doesn’t count as a proper replacement), I wanted to have some of my projects debuggable from within it. While .NET Core works out of box, it takes a bit of effort to setup a full .NET Framework project.

First step is, of course, hunt on Stack Overflow. If you are lucky you might find a guide how to do it that actually works perfectly once you do a few modifications to your project. However, depending on your project, you might not need to go that far.

To start, destination computer will require something that can build your projects. Since installing Visual Studio makes the whole exercise a bit pointless, go and download Build Tools for Visual Studio 2019.

To your Visual Studio Code workspace add familiar .vscode directory and add tasks.json that will build your project. Based on a few of my .NET Framework projects, I found the following common denominator to do wonders (of course, change name of solution and exact path to your source and binaries):

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "build",
      "dependsOn": [ "clean" ],
      "type": "process",
      "windows": {
        "command": "C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Community\\MSBuild\\Current\\Bin\\amd64\\msbuild.exe",
        "args": [
          "-p:Configuration=Debug;DebugType=portable;PlatformTarget=x64",
          "^^Solution.sln^^"
        ]
      },
      "options": { "cwd": "${workspaceFolder}/^^Source^^/" },
      "group": "build"
    },
    {
      "label": "clean",
      "type": "shell",
      "windows": {
        "command": "DEL",
        "args": [ "^^.\\Binaries\\*^^" ]
      }
    }
  ]
}

Here you can already see the trick - we’re adding parameters as argument to MSBuild instead of modifying the project file. I found that most projects (definitely all I tried) are only missing portable debug type and x64 as a platform target (I am still sucker for Any CPU). If it doesn’t work for you, go and check the original article to see if something else is missing.

And the last step is placing launch.json into .vscode directory (again, adjust names):

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": ".NET Framework Launch",
      "type": "clr",
      "request": "launch",
      "preLaunchTask": "build",
      "program": "^^Program.exe^^",
      "args": [],
      "cwd": "${workspaceFolder}/^^Binaries^^/",
      "stopAtEntry": false
    }
  ]
}

This should be sufficient to get you debugging in a pinch.

Using InnoSetup to Convert LF to CRLF For Read-Only Files

My application setup was tasked with installing README.txt file. As Windows versions before 10 have trouble dealing with LF characters, I needed a way to convert line endings to CRLF.

I thought that was easy, I just needed to call AfterInstall:

Source: "..\README.md"; DestDir: "{app}"; DestName: "ReadMe.txt"; Attribs: readonly; AfterInstall: AdjustTextFile;

and then call a simple function:

[code]
procedure AdjustTextFile();
var
  path : String;
  data : String;
begin
  path := ExpandConstant(CurrentFileName)
  LoadStringFromFile(path, data);
  StringChangeEx(data, #10, #13#10, True);
  SaveStringToFile(path, data, False);
end;

However, this didn’t work. While code seemingly worked without an issue, it wouldn’t save to read-only file. Yep, our read-only flag was an issue.

While this meant I had to change my InnoSetup project to install file without read-only attribute set, nothing prevented me setting attribute (after I wrote corrected line endings) using a bit of interop magic:

[code]
function SetFileAttributes(lpFileName: string; dwFileAttributes: LongInt): Boolean;
  external 'SetFileAttributesA@kernel32.dll stdcall';

procedure AdjustTextFile();
var
  path : String;
  data : String;
begin
  path := ExpandConstant(CurrentFileName)
  LoadStringFromFile(path, data);
  StringChangeEx(data, #10, #13#10, True);
  SaveStringToFile(path, data, False);
  SetFileAttributes(path, 1);
end;

Why You Should Update GPS Firmware

Assuming you survived the great GPS rollover, you might wonder if updating your GPS firmware makes any sense at all. It’s obvious you might want new maps. But firmware? Why do you need a new one if everything works just fine.

Real answer is that you probably need not bother. Again, assuming everything works fine, there is no navigation reason for firmware upgrade. Navigation will work equally well whether you have fresh firmware or one that’s a few years old.

However, if you care about time keeping, you will definitely need to update your GPS once in a while. And it’s not because of rollover - that issue is sorted now with the new 13-bit week counter and it’s up to your grandchildren to bother with that. Nope, it’s darn leap seconds.

Leap seconds were created to account for uneven rotation of this big rock we call Earth. As such they are currently beyond our capability to calculate in advance. Once in a while astronomers look upon the skies and decide if leap second is needed. One cannot know in advance when this will happen.

AS GPS time has no concept of a leap second, firmware is what adjusts GPS time to UTC and then later to time zones we all deal with. Guess what, if you have old firmware, your GPS will adjust wrongly and thus something you believe to be a correct time will be off by a second or two (or 27 if you were really lazy).

I know it’s not a breaking deal for a vast majority of population but I simply find it rather unnerving that you would intentionally make your GPS show the wrong time.

Update darn firmware to avoid having your existence out of sync with rest of the world. :)

Installing QT Creator on Ubuntu

Those wanting to play with QT will probably end up installing QT Creator package. While, strictly speaking, you can make QT applications also without it, a lot of things get much simpler if you use it - most noticeable example being GUI design.

After download, installation is really simple:

chmod +x ~/Downloads/qt-unified-linux-x64-3.0.6-online.run
sudo ~/Downloads/qt-unified-linux-x64-3.0.6-online.run

However, I wouldn’t write this post if it was so easy.

Indeed, in Ubuntu, this will seemingly install everything until you try to make a project in QT Creator. There you’ll be stopped with “No valid kits found.” message. Cause of this is missing QT version selection as None will be only option on a clean system. To get offered more, a few additional packages are required:

sudo apt-get install --yes qt5-default qtdeclarative5-dev libgl1-mesa-dev

Once these packages are installed, you’ll be able to modify your Desktop kit definition and select correct version. Finally, you can finish creating the project and get onto coding.

Roll Over Baby

Some people were scared of year 2000 bugs. Some people dread NTP rollover in 2036. Some are scared of Unix epoch rollover in 2038. And some are swearing at their GPS because of 2019 rollover.

Realistically, if your GPS was manufactured in this century, chances are that you won’t even notice anything happened. No user action is needed nor expected. If you have old GPS that hasn’t received update in a while - congratulations - you have yourself a brick.

You see, due to a quirk of design, original GPS message format has a 10-bit week number. That gives you 1024 weeks or about 20 years before it needs to roll back to 0. As GPS needs correct time not only for display but also for determining actual position, if clock is off by 20 years or so, navigation is going to be almost as bad as using Apple Maps.

On a bright side, every GPS I ever owned (going back to original Garmin eTrex) is actually quite capable of dealing with this rollover without breaking a sweat - even with their original firmware. This is not a first rodeo for any decent manufacturer and thus, baring some unexpected bugs, a normal user can be oblivious to this problem.

If you need to deal with old industrial equipment that was installed under Roman emperor and last had its firmware upgraded in middle ages, you might want to heed warnings and check anything that’s really critical. But my guess all such users were aware of this for a long time now.

PS: Since newer GPS devices already have support for 13-bit week format giving you about 150 years between rollovers, I doubt anybody will be worried for next 10-bit rollover in 2038. Anyhow, for that year, we have a bigger fish to fry.

PS: Actually, on most of GPS devices only consequence of non-update firmware is just a wrong date.