error importing showUI -No Style named Current found

Feb 11, 2013 at 4:31 PM
Downloaded 1.3

running "import-module ShowUI" on Win7 x64 gives this:

PS C:\Users\mike_sh> import-module showui
Get-ChildItem : Cannot find path
'C:\Users\mike_sh\Documents\WindowsPowerShell\Modules\showui\StyleSystem\Styles' because it does not
exist.
At C:\Users\mike_sh\Documents\WindowsPowerShell\Modules\showui\StyleSystem\Import-UIStyle.ps1:33 char:33
  • foreach ($style in (Get-ChildItem -Force -Filter *.style -Path $psSc ...
  • ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    • CategoryInfo : ObjectNotFound: (C:\Users\mike_s...leSystem\Styles:String) [Get-ChildItem
      ], ItemNotFoundException
    • FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetChildItemCommand
Use-UiStyle : No Style named Current found
At C:\Users\mike_sh\Documents\WindowsPowerShell\Modules\showui\ShowUI.psm1:229 char:5
  • Use-UiStyle "Current"
  • ~~~~~~~~~~~~~~~~~~~~~
    • CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException
    • FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Import-UIStyle
Mar 11, 2013 at 8:04 PM
In order to get ShowUI to work here (Powershell 3, Win 7, ShowUI 1.3 ), I had to perform the following process (which APPEARS - so far - to have resolved all issues....)
  1. Remove any pre-exisitng (if any) ShowUI directory and contents therein from your PS Modules directory. (we're going to start "clean").
  2. Download a fresh copy of ShowUI from Codeplex (http://showui.codeplex.com/)
  3. Unzip to Powershell Modules directory, as prescribed in install docs
  4. Look at the contents of your unzipped
    %UserProfile%\Documents\WindowsPowerShell\Modules\Showui
    directory and determine if the \Styles directory is a sibling or a descendant of \StyleSystem directory. --IFF-- a sibling, COPY \Styles directory and contents "inside" \StyleSystem (it is now BOTH a sibling AND a descendant -- see notes following)
  5. From Powershell ISE (I used - will also likely work from "normal" Powershell window) issue:
    Import-Module ShowUI -Force
    This will generate the stuff in the \GeneratedAssemblies directory (DLL, etc). It may run a while.
  6. --IFF-- your documents directory is on a local drive, you're done -- ignore everything else following this statement. ELSE: copy the entire \GeneratedAssemblies directory and contents to a local drive (see notes following for other options -- .NET doesn't like to load DLLs from non-local drives...), and edit ShowUI.psm1 (in your \douments directory tree) to change the following the variable $psScriptRoot IN ONLY THE FOLLOWING LINES (do --NOT-- mass change, as there are many references that must be left alone...) to reflect the local drive where you copied |GeneratedAssemblies (I moved to my C drive, so that's what I used here):
Change:
Get-ChildItem $psScriptRoot\GeneratedAssemblies -Force -Recurse -Exclude $exclude -ErrorAction SilentlyContinue |
    Remove-Item -Force -ErrorAction SilentlyContinue
Get-ChildItem $psScriptRoot\GeneratedCode  -Recurse -Force -Exclude $exclude -ErrorAction SilentlyContinue |
    Remove-Item -Force -ErrorAction SilentlyContinue
To:

if ('Clean', 'CleanCore', 'CleanAndDoNothing' -contains $LoadBehavior) {
 Get-ChildItem C:\GeneratedAssemblies -Force -Recurse -Exclude $exclude -ErrorAction SilentlyContinue |
    Remove-Item -Force -ErrorAction SilentlyContinue
Get-ChildItem C:\GeneratedCode  -Recurse -Force -Exclude $exclude -ErrorAction SilentlyContinue |
    Remove-Item -Force -ErrorAction SilentlyContinue
And change:
$CommandsPath = "$psScriptRoot\GeneratedAssemblies\ShowUI.CLR$($psVersionTable.clrVersion).dll"
$CoreOutputPath = "$psScriptRoot\GeneratedAssemblies\ShowUICore.CLR $($psVersionTable.clrVersion).dll"

To:

$CommandsPath = "C:\GeneratedAssemblies\ShowUI.CLR$($psVersionTable.clrVersion).dll"

$CoreOutputPath = "C:\GeneratedAssemblies\ShowUICore.CLR$($psVersionTable.clrVersion).dll"
  1. Now
    Import-Module ShowUI
    (no -Force) should work as expected (it worked here - no guarantees).
Notes:

4 above - generating assemblies WITHOUT copying to a descendant resulted in an error message:

  • CategoryInfo : ObjectNotFound: (\itcfs014\HOME...leSystem\Styles:String)
    because \Styles was NOT a descendant of \StyleSystem in my unzipped version; instead, it was a sibling. I do not know if the reference to \Styles as a sub-directory of SystemStyles is in error, or if the zipped archive has the directory out of place, or if Winzip unzipped incorrectly or what....BUT copying \Styles into \StyleSystem eliminated the error message. If you are NOT getting this error message, this may not be your solution...Note that I COPIED and did NOT MOVE, as I was unsure of the cause of the error, and other references may require the sibling...

6 above. Blogs (including this one:http://labs.blogs.com/its_alive_in_the_lab/2011/05/unblock-net.html ) suggested other solutions that did not work here. If they work for you, they MAY be preferable, although in one case may open up a security exposure. For my DLL, the file dialog box described in the noted blog DID NOT SHOW an "unblock" option, as shown in the blog. Not sure why - may be goverened by a group policy or something? Here, the option is NOT just grayed out ot something - it doesn't exist in the dialog box AT ALL. So that doesn't work here. For the option described here: http://msdn.microsoft.com/en-us/library/dd409252%28VS.100%29.aspx could not be used here (again, group policy??) as the "config" file resides in a subdirectory (of a subdirectory...) of the Windows directory, and we can't edit anything in that chain (well, we can edit, we just can't save....). Also, I am not sure that opening up loading ANY DLL from ANY network available drive is the most secure option (which is likely why it is not the default...), so would not like this option anyway (unlike the UNBLOCK, which IF I could do it here would allow only this DLL - or other trusted and similarly flagged DLLs - to be loaded...

I am not sure that the above changes willl not cause other issues - perhaps Mssrs. Brundage, Finke, and/or Bennett will soon address these issues with an "official" (and almost surely cleaner and less kludgy) update to ShowUI 1.(4?)... But this seems to work for now.
Coordinator
Mar 20, 2013 at 6:42 AM
Wow, so ... that was an interesting font choice :)

I thought that James did a 1.4 release when I asked him to fix the fact that he'd never pushed code to CodePlex. I'll bundle it up tomorrow. It has a few nice extras which have never been blogged about (or that were missing from PowerBoots feature set).

For what it's worth, regarding your notes about running ShowUI from a remote path (network share):

In .Net 4, you can load assemblies from a remote path (it was always a stupid restriction anyway). You can use a powershell.exe.config file to configure that, even for PowerShell 2. It ought to just work in PowerShell 3.

However, you can also just put the module in a "Modules" folder anywhere you like, and then add that folder to your PSModulePath environment variable either in your system environment variables dialog, or in your powershell profile script at start up.
Mar 22, 2013 at 8:50 PM
Don't know what happened with the font - I cut and pasted the response, and it looked OK when I entered it - but after the fact...well, you see...sorry about that

Thanks for the PSModulepath bit - that should work here (haven't yet tried). But the config stuff won't (easily) as we are precluded from altering anything in the Windows directory (and the aforementioned is in a subdirectory therein).

I am not sure that I agree that the DLL load restriction is lame - it doesn't "feel right" (as in: there is a somewhat nightmare-ish specter about it) that you would want to open up DLL loading from anywhere on the network...seems like it could be an additional "attack surface" for malcontents and other undesirables...has kinda the same feel as un-restricting code signing requirements for scripts...

I'lll give 1.4 a shot w/module path.

Thanks!
Coordinator
Mar 24, 2013 at 3:15 AM
Edited Mar 24, 2013 at 3:18 AM
Well, I think restricting dlls from loading off network drives was always boneheaded ;-) and I'll tell you why:

First: executables could still load from anywhere (unless they try to load an assembly that's in the same folder as they are). Second: any code NOT written in .Net can load assemblies from anywhere, so this doesn't protect you from attack, it just makes it annoying to develop in .Net for certain types of corporate customers. That's why they just got rid of the policy in .Net 4, and recommend using more effective means such as Windows Software Restriction Policies instead. See also here.

Even if those points were not true, allowing loading didn't expand the attack surface, because you have to already be EXECUTING code: if the code was malicious, it probably wouldn't depend on external assemblies, and if it did, it would just copy them to your C: drive and loaded them from there. So the fact that it failed practically proves that it was NOT malicious. That's just frustrating, from a security perspective and a user-experience perspective.

By the way, there's some more information about CAS and CAS Policy and how to configure it for PowerShell on .Net 2x on my blog (I forgot I had posted it): how to import binary modules from network shares.
Mar 25, 2013 at 2:45 PM
Looks like 1.3 from Sept 2011 is still the version available in downloads.

Is 1.4 available someplace else?

Thanks
Coordinator
Mar 26, 2013 at 5:13 AM
Jaykul wrote:
I thought that James did a 1.4 release when I asked him to fix the fact that he'd never pushed code to CodePlex.
What actually happened is that James added a few features to a couple of commands (notably the ConvertTo-ISEAddon) in the version he included in ISEPack, so we have a release 1.4 that doesn't match what is in source control anywhere, and that was never released here. When I asked James to fix that -- he checked in his code changes, but didn't push up the release here. I will fix that soon, but you'll have to grab it from powershellise.com or show-ui.com for now.