All,

I have a project that needs to register some performance counters with the operating system. I can do this using some helper classes in Enterprise Library. The samples show, of course, the way to do this via a C# console application -- but it seems sill to have a compiled program around to just do a couple of lines of code.

Enter PowerShell.

I've gotten fairly far with the following script:

param
(
    [switch]$install,
    [switch]$uninstall,
    [string]$configFile = $(throw "-configFile is required")
)

[System.Reflection.Assembly]::LoadFrom("Microsoft.Practices.EnterpriseLibrary.PolicyInjection.dll")
[System.Reflection.Assembly]::LoadFrom("Microsoft.Practices.EnterpriseLibrary.PolicyInjection.CallHandlers.dll")
[System.Reflection.Assembly]::LoadFrom("Microsoft.Practices.EnterpriseLibrary.Common.dll")

$configSource = New-Object Microsoft.Practices.EnterpriseLibrary.Common.Configuration.FileConfigurationSource $configFile
$installer = New-Object Microsoft.Practices.EnterpriseLibrary.PolicyInjection.CallHandlers.Installers.PerformanceCountersInstaller $configSource
$installer.Context = New-Object System.Configuration.Install.InstallContext

if( $install )
{

    $state = New-Object System.Collections.Hashtable
    $installer.Install($state)
    $installer.Commit($state)

}
elseif( $uninstall )
{
    $installer.Uninstall()
}

Unfortunately, I always error out when the utility class goes to open the config file specified on the command line. After some sniffing, I was able to determine that the problem was that the config file had some configuration section handlers defined in it and the framework was trying unsuccessfully to load those dynamically. I thought perhaps I could overcome the issue by explicitly loading those assemblies in my PS script, but they appear to load into a different appdomain, because they are not visible to the class which it trying to dynamically load those assemblies listed in the config file.

Here is the portion of the config file which causes the problems (pretty standard NET stuff):

[configsections]
  [section name="policyInjection" type="Microsoft.Practices.EnterpriseLibrary.PolicyInjection.Configuration.PolicyInjectionSettings, Microsoft.Practices.EnterpriseLibrary.PolicyInjection, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" /]
  [section  name="dataConfiguration" type="Microsoft.Practices.EnterpriseLibrary.Data.Configuration.DatabaseSettings, Microsoft.Practices.EnterpriseLibrary.Data, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" /]
[/configsections]

So, what am I missing here? Is there a particular trick to helping PS find those assemblies in the config file, or am I just attempting to do something that the tool was not really designed to do?

Thanks in advance for any advice!

-Jon

90% positive I'm wrong here, but that never stopped me before. When you say it registers them in a different appdomain. It is possible that powershell is simply scoping it into a different namespace. Have you tried to just run your script line my line in to console. I.e. Not as a script but just type the commands? or just dot source your script to run it in your current namespace/scope? . ./myscript.ps1 ~Glenn P.S. While it's true that what your doing was never intended... It is more then possible.