Consider the following PowerShell snippet:
$csharpString = @\"
using System;
public sealed class MyClass
{
public MyClass() { }
public override stri
This technique works well for me:
if (-not ([System.Management.Automation.PSTypeName]'MyClass').Type)
{
Add-Type -TypeDefinition 'public class MyClass { }'
}
Internally, the PSTypeName class calls the LanguagePrimitives.ConvertStringToType() method which handles the heavy lifting. It caches the lookup string when successful, so additional lookups are faster.
I have not confirmed whether or not any exceptions are thrown internally as mentioned by x0n and Justin D.
The simplest way to do this is a try/catch block. You have two options for doing this:
try { [MyClass] | Out-Null } catch { Add-Type -TypeDefinition $csharpString; }try { Add-Type -TypeDefinition $csharpString; } catch {}This way no exception is thrown, it's just a little slow base on number of assemblies loaded:
[bool]([appdomain]::CurrentDomain.GetAssemblies() | ? { $_.gettypes() -match 'myclass' })
There's a nicer way to do this without incurring the cost of exceptions:
if (-not ("MyClass" -as [type])) {
add-type @"
public class MyClass { }
"@
}
update: well, apparently powershell signals internally with an exception anyway. It has a bad habit of doing this. The interpreter uses SEH to signal with the break and continue keywords, for example.
Actually, none of this is required. Add-Type maintains a cache of any code that you submit to it, along with the resulting type. If you call Add-Type twice with the same code, then it won't bother compiling the code and will just return the type from last time.
You can verify this by just running an Add-Type call twice in a row.
The reason you got the error message in the example above is that you changed the code between calls to Add-Type. While the solution above makes that error go away in this situation, it also means that you're working with an older definition of the type that probably isn't acting the way you think it is.