How do I get the computer’s serial number? Consuming Windows Runtime classes in desktop apps, part 5: PowerShell


Continuing our series on getting the computer's serial number in desktop apps in various languages, we look at PowerShell.

I warned you that you're going to be underwhelmed, so prepare to be underwhelmed.

# The following line has been broken up for readability purposes.
# Make sure to glue them together into one long line.
# (The continuation character doesn't work here.)
$addType = [Windows.System.Profile.SystemManufacturers.SmbiosInformation,
            Windows.System.Profile.SystemManufacturers,
            ContentType=WindowsRuntime]

[Windows.System.Profile.SystemManufacturers.SmbiosInformation]::SerialNumber

The first thing we do is add the type to PowerShell, which we do by loading up the type from the Windows Runtime metadata. Specify the type, the parent namespace, and say ContentType = WindowsRuntime.

And that's it. We can now obtain the Serial­Number static property from the Smbios­Information class just like any other type.

Next time, we'll wrap things up with a brief discussion of the Smbios­Information class itself.

Comments (16)

  1. pc says:

    Note that for this particular example you might find it easier to use WMI:

    gwmi win32_bios | fl SerialNumber

    Though I understand that the point of this series is to document how to integrate with WindowsRuntime in a bunch of platforms.

  2. Jedak says:

    I feel gipped. I was promised underwhelming, and I was not underwhelmed. ;)

  3. Lars says:

    I’d like to echo Jedak here. The $addType statement is non-obvious if you aren’t familiar with PowerShell. OTOH, the C# version is immediately readable (and writable) to someone not familiar with the language. (Linux user here)

    1. Wayne says:

      PowerShell is utterly inscrutable; it’s like C#, Bash, and Perl had a really ugly baby. I don’t know why this monstrosity of a language was hoisted on us; it’s filled with more symbols and bizarre semantics than decades of Unix shells.

      1. pc says:

        I think it’s because C#, Bash, and Perl, for all their foibles, are still better than Batch. So their baby must be too, right?

        1. 640k says:

          Using :: as scope separator as seen in the example above, is from c++. Not the best decision.

          1. Alex Cohn says:

            No, :: must be coming from PHP. There, it’s officially titled T_PAAMAYIM_NEKUDOTAYIM

      2. Voo says:

        “it’s filled with more symbols and bizarre semantics than decades of Unix shells”
        I’m not sure if you’re serious or not, but the claim that PowerShell is more bizarre than bash is.. bizarre really.

        The thing is everybody has been writing bash scripts for decades so we just got used to most of its idiosyncrasies, but really that’s it.

        While PowerShell is far from perfect (but then what mainstream language ever is), it’s still much, much nicer than writing bash scripts (the horror of parsing arguments in bash alone..).

        It takes a while to get used to when starting, but the same is true for every new language that’s noticeably different from what you’re used to.

        1. Wayne says:

          You’re right; it isn’t worse than Bash but that is small comfort really.

          The question is, why is Powershell “noticeably different than what I’m used to”? Why not make a language that is comfortable and familiar to anyone who has worked in C#, Java, JavaScript, C, C++? Instead the semantics are hard for beginners and experts to understand. It’s clearly inspired by Linux shells but not enough like them to even make that knowledge transferable.

          1. Voo says:

            PowerShell is actually incredibly similar to c- based languages all things considered.

            But yes there are differences, but those are mostly due to the different use cases.

            C# is a general purpose programming language that ought to scale from thousands lines of code (almost no real world c# programs are smaller than that) to millions. Pretty much nobody uses it interactively despite the ability to do so having existed for years.

            PowerShell on the other hand is used interactively to a large degree. The vast majority of PowerShell scripts is anywhere from 100 characters to a few hundred lines of code at most.

            Two totally different use cases which necessitate very different decisions. That doesn’t make either of them wrong it just means you have to pick the right tool for the right job. And PowerShell is excellent for system administration and build system configuration – from simple things like not having to parse your own arguments (and then document them separately) to complex things like remoting.

    2. AndyCadley says:

      That’s really only because Raymond is assigning the results to a variable, $addType, as a way of avoiding the output from importing a type. Personally I’d pipe that line into Out-Null instead, which makes the intent more obvious.

  4. Danny says:

    “Next time, we’ll wrap things up with a brief discussion of the Smbios­Information class itself”
    No Ada? I’m disappointed, I was looking forward to it after all.

  5. Peter Doubleday says:

    I miss the good old days of INT21H …

    1. John Elliott says:

      You have something against CALL 5?

  6. ChrisCompton says:

    I wasn’t able (yes, as Admin) to run it; error ==
    Unable to find type [Windows.System.Profile.SystemManufacturers.SmbiosInformation
    ,Windows.System.Profile.SystemManufacturers, ContentType=WindowsRuntime].
    At line:1 char:1
    + $addType = [Windows.System.Profile.SystemManufacturers.SmbiosInformat …
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : InvalidOperation: (Windows.System….=WindowsRunti
    me:TypeName) [], RuntimeException
    + FullyQualifiedErrorId : TypeNotFound

    Is it because of a version (win 7), the fact that I ran it from virtual, or something else?

    Thanks @pc for the gwmi command that works (without admin; virtual and not)

    1. Um, Windows 7 doesn’t have Windows Runtime types.

Skip to main content