Keith's profileKeith Hill's BlogPhotosBlogListsMore  |  Tools Help |
|
October 30 PowerShell - Find-PInvoke.ps1I had a need to find all PInvokes in an assembly. At first I thought about searching the source code since I had it but ran into various problems:
[Updated: 11-02-2009] I decided to go with the "reflection only load" approach to extract the PInvoke (DllImport) information. The script file has been updated to reflect (pun intended) this new and better approach. In fact, more data is gathered for each PInvoke including all of the values for the associated DllImportAttribute. Now to see if I can get this included in the next version of PSCX. It seems that the reflection only load is sensitive to assembly load failures. Once an assembly fails to load you pretty much have to start a new PowerShell session to try again. I'll keep looking into this. For what appears to be a really neat capability (ReflectionOnlyLoad) it has some unfortunate short-comings. Here is some sample output when run on the PSCX snapin dlls. PS> gci C:\Users\Keith\Pscx\Trunk\Src\Pscx\bin\Debug\Pscx*.dll | .\Find-PInvoke | DllImport: advapi32.dll Assembly MethodName TypeName DllImport: Fusion.dll Assembly MethodName TypeName DllImport: kernel32.dll Assembly MethodName TypeName October 29 PowerShell 2.0 – Accessing Different ProfilesJust ran across a new feature of PowerShell 2.0 that is convenient. Need the path to the various profile scripts on a system? Try this: PS> $profile.psextended | Format-List AllUsersAllHosts : C:\Windows\System32\WindowsPowerShell\v1.0\profile.ps1 To access individually you can use $profile.AllUsersAllHosts. psmdtag:variable Profile October 21 Windows PowerShell 2.0 String LocalizationOne of the lesser known features in PowerShell 2.0 is that it supports string localization and pretty simply I might add. Now for most developers and admins script localization probably isn’t going to be something you’ll worry about. However if you are providing PowerShell based solutions to an international audience this feature will come in very handy in terms of broadening your reach. I believe the driving force behind this feature’s inclusion in PowerShell is that a critical component of Windows 7 – the Windows Troubleshooting Platform and associated troubleshooting packs – use PowerShell scripts extensively. Obviously Windows is localized to the extreme so it stands to reason that the troubleshooting scripts, which can interact with the end user via text prompts, were required to be localized. Enough context. Let’s look at how localization works in PowerShell 2.0. First, the feature in PowerShell is referred to as “Data Sections” and is covered by the help topics:
Let’s start by creating our string table file. This is created as a .psd1 (data) file. In this case, we will call it messages.psd1 and its contents are simply: # Contents of .\messages.psd1 This is a bit odd looking for a “data” file but the gist is that the ConvertFrom-StringData cmdlet returns a ordinary hashtable. The string that ConvertFrom-StringData operates on has to be in a special format which is essentially one key/value pair per line where the key and value are separated by an “=”. The “key” is how you will reference the “value” (actual localized string) from your script. FWIW you could just have the psd1 file return a hashtable directly but then you have to quote each value. So the format above is a bit cleaner and more like a traditional string table file. Now at this point you could and might be tempted to do something like this in your script: $msgs = .\messages.psd1 But there is one tiny little problem - .psd1 files are not executable like .ps1 or .psm1 files are. Hey, that’s probably why they are called “data” files. :-) Obviously PowerShell must provide a way to load these files and that mechanism is the Import-LocalizedData cmdlet. It takes the path to a .psd1 file, loads it and then assigns the resulting hashtable to a variable name provided to the cmdlet. Let’s see an example of this: # Contents of test.ps1 The output of this script is: PS> .\test.ps1 You may be thinking that this seems like a pretty simple task, not worthy of requiring a dedicated cmdlet. However there is one very important piece of “non-trivial” functionality that the Import-LocalizedData cmdlet provides and that is it searches through various culture specific sub directories looking for a matching .psd1 file for the user’s culture. For those familiar with .NET development this is very similar to how the .NET binder looks through application’s base sub dirs for the appropriate satellite assembly for the user’s culture. Let’s see an example of how this works. First, let’s create a German version of our string resources and put the file in a sub dir titled de-DE. The name of this sub dir is important. The name reflects the <language>-<region> that the localized strings target. Here are the contents of .\de-DE\messages.psd1: # Contents of .\de-DE\messages.psd1 At this point our dir structure looks like this: .\test.ps1 Now I need to introduce a somewhat orthogonal but very handy function called Using-Culture that the PowerShell team blogged a long time ago. I have updated it for PowerShell 2.0 and I use it to effectively simulate running PowerShell scripts in different cultures. function Using-Culture ([System.Globalization.CultureInfo]$culture =(throw "USAGE: Using-Culture -Culture culture -Script {scriptblock}"), Now let’s try running out test.ps1 script under the German language/region: PS> Using-Culture de-DE { .\test.ps1 } Now that’s what I’m talking about! Script localization without requiring an advanced degree. Now, you might ask – what happens when somebody run’s in a culture that I have not localized for? Let’s see: PS> Using-Culture fr-FR { .\test.ps1 } When I listed the dir contents above I mentioned that the top-level messages.psd1 was the “fallback”. Essentially if PowerShell can’t find the specified data file for the current culture it will “fallback” to the top-level data file or .\messages.psd1 in this case (which is English). This may very well be a feature you never use but if you desire to reach a broad audience with your PowerShell 2.0 modules, consider pulling out your strings into a data file even if you only provide a data file for your native language. This gives others a much better chance of localizing your module into other languages for you! It’s Official - Windows 7 and Windows PowerShell 2.0 for Everyone!Congratulations to the Windows and Windows PowerShell teams for two very excellent releases. I’ve been using Windows 7 daily since January’s beta release and PowerShell 2.0 drops for even longer. Both products are destined to be smash hits in my humble opinion. I’m very excited about the new capabilities of PowerShell 2.0 and the fact that it’s a built-in and required component of Windows 7 means that the time when we can count on PowerShell “just being there” is getting closer. October 16 Windows PowerShell 2.0 Virtual Launch PartyI’m relaying this invite from Hal & Jonathan – hosts of the PowerScripting Podcast. Windows isn’t just about the GUI. Starting with Windows 7, you have built-in access to PowerShell version 2, an object-oriented scripting language and command shell. Please join PowerScripting Podcast hosts Jonathan Walz and PowerShell MVP Hal Rottenberg as they interview Distinguished Engineer Jeffrey Snover on launch day! Jeffrey is the chief architect responsible for PowerShell at Microsoft, and he’ll be covering what’s new with the tool and why every system administrator on the planet needs to be using it. If you’ve never attended PowerScripting Live, you are missing out on a great time. The show will be streamed live via Ustream, and viewers can chat with each other, as well as submit questions for the guest.
October 12 Windows PowerShell 2.0 and Windows Troubleshooting Platform PresentationTonight I gave a presentation on the new features in Windows PowerShell 2.0. I also demo how to create a Windows Troubleshooting Platform that is new in Windows 7. WTP uses PowerShell scripts to do the heavy lifting of detecting and resolving root causes i.e. problems that need fixing. I gave this presentation at the Northern Colorado.NET Special Interest Group. As promised, here are the presentation materials: slide deck and Start-Demo samples. |
|
|
