I am not sure if this is possible or not with PowerShell.
But basically I have a Windows Forms program that configures a program called EO Server. The EO Server has an API, and I make a reference to EOServerAPI.dll to make the following code run.
using EOserverAPI;
...
private void myButton_Click(object sender, EventArgs e)
{
String MDSConnString="Data Source=MSI;Initial Catalog=EOMDS;Integrated Security=True;";
//Create the connection
IEOMDSAPI myEOMDSAPI = EOMDSAPI.Create(MDSConnString);
//Get JobID
Guid myMasterJobID = myEOMDSAPI.GetJobID("myJobRocks");
}
Is it possible to interact with an API DLL file and make the same types of calls as you would in a Windows Forms application?
Yes, you can:
Add-Type -Path $customDll
$a = new-object custom.type
You call a static method like so:
[custom.type]::method()
Instead of Add-Type, you can also use reflection:
[Reflection.Assembly]::LoadFile($customDll)
(Note that even the above is calling the Reflection library and the LoadFile static method.)
Take a look at the blog post Load a Custom DLL from PowerShell. If you can interact with an object in .NET, you can probably do it in PowerShell too.
Actually the other offered solutions don't work for me, here it's an alternative that works perfectly for me:
$AssemblyPath = "C:\SomePath\SomeLIB.dll"
$bytes = [System.IO.File]::ReadAllBytes($AssemblyPath)
[System.Reflection.Assembly]::Load($bytes)
c# dll
Add-Type -Path $dllPath
(new-object namespace.class)::Main() #Where namespace=dllnamespace, class=dllclass, Main()=dllstartvoid
info. get namespace&classes
$types = Add-Type -Path $dllPath -PassThru
$types | ft fullname
$types
if it's not "executable" dll (something get/set dll) then this is the best that i know (not needed vs for sample dll creating):
https://kazunposh.wordpress.com/2012/03/19/проверка-корректного-ввода-distinguished-name-в-скри/
Related
I'm looking for a way to retrieve the target framework attribute (e.g. .NETCoreApp,Version=v2.1) from a DLL when using PowerShell Core, ideally without loading the DLL directly into the main session.
I can do this in Windows PowerShell 5, as it has access to the ReflectionOnlyLoadFrom method...
$dllPath = 'C:\Temp\ADALV3\microsoft.identitymodel.clients.activedirectory.2.28.4\lib\net45\Microsoft.IdentityModel.Clients.ActiveDirectory.WindowsForms.dll'
[Reflection.Assembly]::ReflectionOnlyLoadFrom($dllPath).CustomAttributes |
Where-Object {$_.AttributeType.Name -eq 'TargetFrameworkAttribute'} |
Select -ExpandProperty ConstructorArguments |
Select -ExpandProperty value
However, I realise that this approach isn't available in .NET Core.
Editor's note: Even though the documentation (as of this writing) misleadingly suggests that the ReflectionOnlyLoadFrom method is available in .NET Core, it is not, as explained here.
From what I've seen, it looks likely that I should be able to access the custom attributes that hold the target framework attribute by using an instance of the System.Reflection.Metadata.MetadataReader class that's available in .NET Core (a couple of examples of this in use can be found here: https://csharp.hotexamples.com/examples/System.Reflection.Metadata/MetadataReader/GetCustomAttribute/php-metadatareader-getcustomattribute-method-examples.html ). However, all the constructors for this type seem to use a Byte* type, as the following shows when running from PowerShell Core:
([type] 'System.Reflection.Metadata.MetadataReader').GetConstructors() | % {$_.GetParameters() | ft}
I have no idea how to create a Byte* type in any version of PowerShell. Perhaps there's a method in System.Reflection.Metadata that I should be using before creating the MetadataReader object, but I haven't found it yet.
Apologies for the length of this question, but I'm hoping by sharing my notes I'll help in tracking down the solution. Any advice on how this target framework information can be obtained using PowerShell Core?
After quite a bit of work, I managed to put together a PowerShell script that works (without external dependencies) in PowerShell Core that pulls in the target framework from a DLL:
$dllPath = 'C:\Temp\ADALV3\microsoft.identitymodel.clients.activedirectory.2.28.4\lib\net45\Microsoft.IdentityModel.Clients.ActiveDirectory.WindowsForms.dll'
$stream = [System.IO.File]::OpenRead($dllPath)
$peReader = [System.Reflection.PortableExecutable.PEReader]::new($stream, [System.Reflection.PortableExecutable.PEStreamOptions]::LeaveOpen -bor [System.Reflection.PortableExecutable.PEStreamOptions]::PrefetchMetadata)
$metadataReader = [System.Reflection.Metadata.PEReaderExtensions]::GetMetadataReader($peReader)
$assemblyDefinition = $metadataReader.GetAssemblyDefinition()
$assemblyCustomAttributes = $assemblyDefinition.GetCustomAttributes()
$metadataCustomAttributes = $assemblyCustomAttributes | % {$metadataReader.GetCustomAttribute($_)}
foreach ($attribute in $metadataCustomAttributes) {
$ctor = $metadataReader.GetMemberReference([System.Reflection.Metadata.MemberReferenceHandle]$attribute.Constructor)
$attrType = $metadataReader.GetTypeReference([System.Reflection.Metadata.TypeReferenceHandle]$ctor.Parent)
$attrName = $metadataReader.GetString($attrType.Name)
$attrValBytes = $metadataReader.GetBlobContent($attribute.Value)
$attrVal = [System.Text.Encoding]::UTF8.GetString($attrValBytes)
if($attrName -eq 'TargetFrameworkAttribute') {Write-Output "AttributeName: $attrName, AttributeValue: $attrVal"}
}
$peReader.Dispose()
I'm mostly happy with it, the only issue I'd still like to sort out is that I'm getting some unhandled characters in the string output. I'll try to get rid of them.
I am using the AzureAd Powershell module for user management. However it does not have all the functionality that I need, specifically, I can't assign Application Extension values to objects, (although I can create delete and remove application extensions themselves via [Get/New/Remove]-AzureADApplicationExtensionProperty).
I know from watching the API calls with Fiddler that the graph calls are using bearer tokens, and I've called the graph API directly from Postman manually so I know how to use the Bearer token if I could get it. How do I get it?
To get the token simply use:
$token = [Microsoft.Open.Azure.AD.CommonLibrary.AzureSession]::AccessTokens['AccessToken']
But how could one come to this conclusion?
First look for where the module is located:
(Get-Module AzureAd).Path
C:\Program Files\WindowsPowerShell\Modules\AzureAD\2.0.1.3\Microsoft.Open.AzureAD16.Graph.PowerShell.dll
Now lets just make 2 assumptions. First that the token is stored in a static member of a static class, and second that it might not be stored in that dll, but any of the DLLs in the folder.
$fileInfo = New-Object 'IO.FileInfo' (Get-Module AzureAd).Path
$moduleFolder = $fileInfo.Directory.FullName
$assemblies = [AppDomain]::CurrentDomain.GetAssemblies() | where { $_.Location -ne $null -and $_.Location.StartsWith($moduleFolder)}
$assemblies | select -expandproperty ExportedTypes | Where { $_.IsSealed -and $_.IsAbstract } | Select Name, FullName
That last line btw is because of the weird way static types are noted in IL.
Which outputs a very small list:
Name FullName
---- --------
RestSharpExtensionMethods Microsoft.Open.Azure.AD.CommonLibrary.RestSharpExtensionMethods
AzureSession Microsoft.Open.Azure.AD.CommonLibrary.AzureSession
DictionaryExtensions Microsoft.Open.Azure.AD.CommonLibrary.DictionaryExtensions
Logger Microsoft.Open.Azure.AD.CommonLibrary.Logger
ImageUtils Microsoft.Open.Azure.AD.CommonLibrary.Utilities.ImageUtils
SecureStringExtension Microsoft.Open.Azure.AD.CommonLibrary.Extensions.SecureStringExtension
AzureEnvironmentConstants Microsoft.Open.Azure.AD.CommonLibrary.AzureEnvironment+AzureEnvironmentConstants
TypeToOdataTypeMapping Microsoft.Open.AzureAD16.Client.TypeToOdataTypeMapping
JsonConvert Newtonsoft.Json.JsonConvert
Extensions Newtonsoft.Json.Linq.Extensions
Extensions Newtonsoft.Json.Schema.Extensions
TypeToOdataTypeMapping Microsoft.Open.MSGraphV10.Client.TypeToOdataTypeMapping
AdalError Microsoft.IdentityModel.Clients.ActiveDirectory.AdalError
AuthenticationContextIntegratedAuthExtensions Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContextIntegratedAuthExtensions
AdalOption Microsoft.IdentityModel.Clients.ActiveDirectory.AdalOption
MiscExtensions RestSharp.Extensions.MiscExtensions
ReflectionExtensions RestSharp.Extensions.ReflectionExtensions
ResponseExtensions RestSharp.Extensions.ResponseExtensions
ResponseStatusExtensions RestSharp.Extensions.ResponseStatusExtensions
StringExtensions RestSharp.Extensions.StringExtensions
XmlExtensions RestSharp.Extensions.XmlExtensions
RestClientExtensions RestSharp.RestClientExtensions
SimpleJson RestSharp.SimpleJson
We could pipe through Out-Gridview if the list was longer, but my attention was immediatly drawn to AzureSession. After that a little PowerShell autocomplete, and I found my way to [Microsoft.Open.Azure.AD.CommonLibrary.AzureSession]::AccessTokens['AccessToken']
I'm trying to call an async method on a .Net object instantiated in Powershell :
Add-Type -Path 'my.dll'
$myobj = new-object mynamespace.MyObj()
$res = $myobj.MyAsyncMethod("arg").Result
Write-Host "Result : " $res
When executing the script, the shell doesn't seem to wait for MyAsyncMethod().Result and displays nothing, although inspecting the return value indicates it is the correct type (Task<T>). Various other attempts, such as intermediary variables, Wait(), etc. gave no results.
Most of the stuff I found on the web is about asynchronously calling a Powershell script from C#. I want the reverse, but nobody seems to be interested in doing that. Is that even possible and if not, why ?
I know this is a very old thread, but it might be that you were actually getting an error from the async method but it was being swallowed because you were using .Result.
Try using .GetAwaiter().GetResult() instead of .Result and that will cause any exceptions to be bubbled up.
For long running methods, use the PSRunspacedDelegate module, which will enable you to run the task asynchronously:
$task = $myobj.MyAsyncMethod("arg");
$continuation = New-RunspacedDelegate ( [Action[System.Threading.Tasks.Task[object]]] {
param($t)
# do something with $t.Result here
} );
$task.ContinueWith($continuation);
See documentation on GitHub. (Disclaimer: I wrote it).
This works for me.
Add-Type -AssemblyName 'System.Net.Http'
$myobj = new-object System.Net.Http.HttpClient
$res = $myobj.GetStringAsync("https://google.com").Result
Write-Host "Result : " $res
Perhaps check that PowerShell is configured to use .NET 4:
How can I run PowerShell with the .NET 4 runtime?
I have a COMPLUS apllication of activation type "1".Now i want to register few dlls under this application,that will get list down under components tab of the application.suppose the dll name is test1.dll.
How can i do this.I came to know about ICOMAdminCatalog::InstallComponent,but not getting a syntax to use it.Please help :)
Try this:
$comAdmin = New-Object -comobject COMAdmin.COMAdminCatalog;
$comAdmin.InstallComponent("MyApplication", "MyLibrary.dll", $null, $null);
Note: If you're adding a new application, make sure you $apps.SaveChanges() first.
I would like to leverage the following
$wi=new-object -com WindowsInstaller.Installer
If I do a $wi |gm I do not see the method I want "Products".
I would like to iterate Products and show a list of all items installed on the system.
So I thought... let me do a $wi.gettype().invokemember
Not really sure what to do $wi.gettype().invokemember("Products","InvokeMethod")
or something yields cannot find an overload...
But now I am lost. I have looked elsewhere but I don't want to create a whole XML file. I should be able to access the com objects methods.
If you are trying to get a list of installed programs in Windows, there is a native Powershell way, which is actually using WMI behind the scenes:
Get-WmiObject Win32_Product
Here's a related article from Microsoft Scripting Guys.
It appears that this approach has some issues, so better be avoided.
When you query this class, the way the provider works is that it
actually performs a Windows Installer “reconfiguration” on every MSI
package on the system as its performing the query!
I tried my best to find a solution that involves WindowsInstaller com object, but all of them point to an article that no longer exists. Here is one on stackoverflow.
An alternative solution is to give a try to psmsi on CodePlex.
Here my code-snippet for this:
cls
$msi = New-Object -ComObject WindowsInstaller.Installer
$prodList = foreach ($p in $msi.Products()) {
try {
$name = $msi.ProductInfo($p, 'ProductName')
$ver = $msi.ProductInfo($p, 'VersionString')
$guid = $p
[tuple]::Create($name, $ver, $guid)
} catch {}
}
$prodlist