Method not found: GenericChart when using FSharp.Charting from powershell cmdlet - powershell

I am trying to use the FSharp charting library from a powershell cmdlet (also written in F#) but I get a MissingMethodException for GenericChart.
The sample of the charting code:
open FSharp.Charting
let testchart() =
let foo = DataAccessLayer.GetTestData()
Chart.Line(foo) |> Chart.Show
The testchart function is called from the ProcessRecord() method on the PSCmdlet derived class.
Both the charting and cmdlet code are in the same solution, though different projects. The solution compiles without error. The charting code runs in interactive without error. But when I try to execute the powershell cmdlet I get the missing method exception.
This happens when using VS2013 and VS2015.
According to documentation GenericChart should be in the FSharp.Charting.dll. I confirmed that the dll is in the same directory as the powershell module code.
Again, in VS all the intellisense works, everything compiles and works in interactive.
Any suggestions are much appreciated.

This problem is due to having an obsolete copy of the Libraries. Rebuild from scratch using the latest F# libraries and it will clear.
I had exactly the same error message and doing so fixed it.

Related

New-Object vs [type]::New(), script vs ISE

Sigh. Another day, another PowerShell method interaction with .NET I just don't understand. This time with signed XML, but it's an issue with how to create a new object.
$signedXml = New-Object system.security.cryptography.xml.signedXml -argumentList:$xml works. But where possible I have been moving to [type]::New(). And...
$signedXml = [System.Security.Cryptography.Xml.SignedXml]::New($xml) doesn't work. In a script. Works fine in the ISE, but when run as a script I get
Unable to find type [System.Security.Cryptography.Xml.SignedXml].
So, what is going on under the hood such that using a constructor only works in the ISE, while New-Object works in a script also. And, how does one grok what is going to fail? I have plenty of other things I have moved to [type]::New() with no issues. Is my only option to fall back on the commandlet when the constructor fails me? That results in less consistent, readable code in my view.
It didn't work for me in the ISE either, until I did this. Maybe you loaded some module in the ISE that did something like it.
using assembly system.security
Try:
Using namespace System.Security.Cryptography.Xml;
Powershell has the ability to call namespaces like C#.
The below code seemed to work with for me fine in Powershell Core:
Using namespace System.Security.Cryptography.Xml;
$xml = [xml]::New()
$signed = [SignedXml]::New($xml)

Powershell - Missing System.Collections.Generic in C:\windows\assembly\GAC_MSIL

I'm trying to use this code in Powershell:
Add-Type -AssemblyName "System.Collections.Generic"
However I get this error:
Add-Type : Cannot add type. One or more required assemblies are missing.
I've looked in C:\windows\assembly\GAC_MSIL and can see that there is no folder named System.Collections.Generic.
Do I need to download this library, if so where?
There is no System.Collections.Generic assembly. That is a namespace. A large portion of the types in that namespace are in the core library assembly, mscorlib.dll which is already available in Powershell since Powershell is .Net.
Go to MSDN for the namespace, find the type you are trying to use, and you can see the assembly it is in, and remember that there is not necessarily a one to one relationship between assemblies and namespaces.
Using generic types is a bit involved in Powershell and can depend on using reflection, or formatting complex type names.
See this stackoverflow question for some more details.
Never mind,
not sure why that doesn't work, but turns out I don't need it anyway.
I had this code which for some reason wasn't working intially because it couldn't find [Collections.Generic.List[String]], but now it seems to work:
[string[]] $csvUserInfo = #([IO.File]::ReadAllLines($script:EmailListCsvFile))
[Collections.Generic.List[String]]$x = $csvUserInfo
I would answer by another question, Why do you need this assembly ?
Can you try to replace your code by :
$x = [IO.File]::ReadAllLines($script:EmailListCsvFile)
In PowerShell it should work.

Print x86 assembly instead of getting machine code from ExecutionEngine

I've seen several conflicting descriptions of how to do this around the google results, and haven't been able to get any of them to work.
My problem is basically this: where I call ExecutionEngine::getPointerToFunction (with an llvm::Function*), I'd like to instead get the pretty-printed x86 assembly that would be produced for this function.
Anybody?
[ETA: I'm using LLVM 3.3. The descriptions I've found seem to be for earlier versions of LLVM.]
It turns out that you can add an event listener to a JIT ExecutionEngine with ExecutionEngine::RegisterJITEventListener. If you provide an instance of that class, you can have your callback invoked when machine code is generated for you, and you'll be given a pointer to the machine code and its length. With this, you can call llvm::sys::disassembleBuffer to get a description of the machine code buffer.
However, the llvm::sys::disassembleBuffer function just defers to the udis library if LLVM was compiled with that support. Since my build of LLVM didn't have this flag set and I can't rebuild it, I'll just look into using the udis library directly:
https://github.com/vmt/udis86

How to reference COM lib like shdocvw using vbc commandline compiler (no IDE)?

The basis of this question comes from this tutorial on support.microsoft.com:
http://support.microsoft.com/kb/176792
To run the following code, it is necessary to add a reference to
"Microsoft Internet Controls" (Shdocvw.dll) and "Microsoft HTML Object
Library" (Mshtml.dll) to the Visual Basic project:
Dim SWs As New SHDocVw.ShellWindows
Dim IE As SHDocVw.InternetExplorer
This works fine in Visual Studio 2010, but it seems to rely on some behind-the-scenes magic that I can't duplicate using the straight commandline vbc compiler.
Obviously there is no "Add Reference" dialog for the commandline compiler. I naively tried adding:
/reference:"C:\windows\system32\shdocvw.dll"
to the commandline, but that didn't help. In both cases, I get:
error BC30002: Type 'SHDocVw.ShellWindows' is not defined.
error BC30002: Type 'SHDocVw.InternetExplorer' is not defined.
I've successfully used shdocvw.dll, AKA Shell.Application, from other languages like vbscript and autohotkey, but I currently have too little understanding of VB.NET to know whether I'm just doing it wrong or it's not possible.
You will have to run the Tlbimp.exe utility first. That's the tool that generates the interop library from the type library embedded in shdocvw.dll, normally done automatically when you add the reference in the IDE. It produces interop.shdocvw.dll, the one you need to pass with the /reference option.

Powershell in SQLCLR?

In the past I've been able to embed a sripting languate (like JScript) inside the SQLCLR, so scripts can be passed as parameters of functions, to perform certain calculations. Here is a simplistic example (the function ssScriptExecute returns a concatenation of all the print's in the script):
select dbo.ssScriptExecute( 'print("Calculation: "+(1+2/3) );' )
-- Calculation: 1.6666666666666665
I'd love to be able to embed a Powershell runtime in the same way. But I've had all sort of problems because the runtime tries to find assemblies by path, and there are no paths inside the SQlCLR. I'm happy to provide more information on the errors I get, but I was wondering if anybody has tried this!
Thanks!
I use il code injection to modified System.Automation.Management.
make variable version in GetPSVersionTable() be "2.0"
then i can run Powershell Code in SQL Server.
Be sure reference this modified dll in your visual studio project.
http://www.box.net/shared/57122v6erv9ss3aopq7p
btw, automated registering all dll you needed with running powershell in SQL
you can use this ps1 code
http://www.box.net/shared/tdlpu1875clsu8azxq4b
I think the only way to do this is to create a WCF service hosting powershell, and let SQLCLR send the request dbo.ssScriptExecute(...) to that service for execution.
Besides from that, I've also successfully embedded paxScript.net in the SQLCLR (an interpreter that does not have the memory leak problems of the DLR languages).
I thought SQLCLR was restricted to just a certain set of assemblies and PS Automation is not one of them.