DEV Community

Cover image for Umbraco Fest UK 2018 - Day 1: Hackathon
Jamie
Jamie

Posted on

Umbraco Fest UK 2018 - Day 1: Hackathon

Disclaimer: This will be a pseudo-live blog post, as the day progresses.

14:26

I'm having a little trouble with the following block, and it's leaving me scratching my head. First, the block of Powershell:

$source = "https://dist.nuget.org/win-x86-commandline/latest/nuget.exe"
if ((test-path $nuget) -and ((ls $nuget).CreationTime -lt [DateTime]::Now.AddDays(-$cache)))
{
  Remove-File $nuget
}
if (-not (test-path $nuget))
{
  Write-Host "Download NuGet..."
  Invoke-WebRequest $source -OutFile $nuget
}

There's nothing inherently wrong with the above block of code. Except that the downloaded binary (which according to the listing on nuget is v4.7.1 of the x86 binary), isn't compatible with my Windows 10 VM's architecture:

Program 'nuget.exe' failed to run: The specified executable is not a valid application for this OS platform

Which I'm guessing is happening because I'm using an Azure VM to build and test my Powershell code.

Interesting.

13:20

I completely forgot to start this, this morning. Here's what I'm working on:

The build scripts use a bunch of partially hard-coded path separators (most devs who use Windows will know this as the \ character - if you're using a culture based on the Latin character set). Stuff like this:

$filepath = "$($uenv.SolutionRoot)\src\SolutionInfo.cs"

What's wrong with that?

Good question. Essentially, different cultures can use different separators characters. For instance, some Japanese systems use the Yen character (i.e ¥) as a path separator.

My "fix" for the above code block would be to use something like:

$filepath = [System.IO.Path]::Combine($uenv.SolutionRoot, "src, "SolutionInfo.cs")

I can do this for two reasons:

  1. The build scripts are all written in Powershell
  2. Powershell is built on .NET and will allow us to pull .NET APIs in

The other added bonus for this, is for if when Umbraco is converted to .NET Core, they won't have to worry about different file path separators across different OSs

i.e. Unix based and Unix-like OSs use / whereas Windows uses \ (except where I've said, above)

Top comments (0)