Why PowerShell does not 'understand' the instructions of a response file? - c#

I have created the following response file (I'm following the examples found in this article: Working with the C# 2.0 Command Line Compiler):
# MyCodeLibraryArgs.rsp
#
# These are the options used
# to compile MyCodeLibrary.dll
# Output target and name.
/t:library
/out:MyCodeLibrary.dll
# Location of C# files.
/recurse:*.cs
# Give me an XML doc.
/doc:myDoc.xml
Then I try to execute it using the C# Compiler (csc.exe) from the PowerShell:
csc #MyCodeLibraryArgs.rsp
Then it generates the following error:
Cannot expand the splatted variable '#MyCodeLibraryArgs'. Splatted variables
cannot be used as part of a property or array expression. Assign the result of
the expression to a temporary variable then splat the temporary variable instead.
At line:1 char:23 + csc #MyCodeLibraryArgs <<<< .rsp
+ CategoryInfo : ParserError: (:) [], ParentContainsErrorRecordException
+ FullyQualifiedErrorId : NoPropertiesInSplatting
So, I decide to use the prompt (command-line), and it works correctly.
What is the cause (s) of this problem with PowerShell (v.3.0)?
Thanks in advance for your responses and comments.

# is a special syntax in powershell for "splatting" variables. You want to escape the # like so
csc `#MyCodeLibraryArgs.rsp
Splatting allows you to pass cmdlet arguments in a hashtable. This is convenient if you want to dynamically build the arguments you are passing. It can also be more readable if there are a lot of arguments. More info on splatting here.

Related

How to use C# interfaces and extension methods in Powershell?

I am trying to use some C# interfaces and extension methods in Powershell. I have loaded necessary binaries at the beginning of the script and written following piece of code:
$environmentsPath = Resolve-Path (Join-Path -Path $PSScriptRoot -ChildPath '..\Deploy.V2\environments')
$configFolder = Join-Path -Path $environmentsPath -ChildPath '.\Stage\configFiles'
$builder = New-Object Microsoft.Extensions.Configuration.ConfigurationBuilder
[Microsoft.Extensions.Configuration.IConfigurationBuilder]$interface = ([Microsoft.Extensions.Configuration.IConfigurationBuilder]$builder)
$interface = [Microsoft.Extensions.Configuration.FileConfigurationExtensions]::SetBasePath($interface, $configFolder)
I am getting following error while trying to run above code:
Cannot convert argument "builder", with value: "Microsoft.Extensions.Configuration.ConfigurationBuilder", for "SetBasePath" to type
"Microsoft.Extensions.Configuration.IConfigurationBuilder": "Cannot convert the "Microsoft.Extensions.Configuration.ConfigurationBuilder" value of type
"Microsoft.Extensions.Configuration.ConfigurationBuilder" to type "Microsoft.Extensions.Configuration.IConfigurationBuilder"."
Even though I have tried to convert object to an interface implementation (at line 4 of the above script) I still see in debugger that it has Microsoft.Extensions.Configuration.ConfigurationBuilder type and the error occurs. I have tried several ways to cast the object but without a success.
Could someone explain me please how can I pass C# function argument being interface implementation in Powershell?

PowerShell and LuaInterface.dll

LuaInterface
Here is an example on c#
Im newbie. How is properly to call this dll?
I was trying this:
[System.Reflection.Assembly]::LoadFile("E:\\lua\\LuaInterface.dll")
$Lua = new-object LuaInterface.Lua # Here IntelliSense see class lua after dot
$lua.DoString("local a=5") # Here IntelliSense see all methods after dot
And this:
Add-Type -path "E:\lua\LuaInterface.dll"
[LuaInterface.Lua]::DoString("local a=5")
But unsuccessfully. Pls, show me example of "3+2" from LuaInterface.
Methods from class Lua PS somehow cant see.
On screenshot powershell can see methods from luaDLL class. But there needed always one more parameter luastate.
You're really close, but :: is only for static member access.
I got the following working in a 32-bit console (PowerShell 5.1):
# Load LuaInterface
Add-Type -Path path\to\luainterface.dll
# Create Lua instance
$lua = [LuaInterface.Lua]::new()
# Set global variable values
$lua['a'] = 2
$lua['b'] = 3
# return result of `a+b`
$lua.DoString("return a+b")

How to access a PSDrive from System.IO.File calls?

I'm writing a c# cmdlet which copies files from one location to another (similar to rsync). It even supports ToSession and FromSession.
I'd like it to work with PSDrives that use the Filesystem provider but it currently throws an error from System.IO.File.GetAttributes("psdrive:\path")
I'd really like to use calls from System.IO on the PSDrive.
How does something like copy-item do this?
I've performed a search for accessing PSDrives from c# and have returned no results.
This is the equivalent of my code
new-psdrive -name mydrive -psprovider filesystem -root \\aserver\ashare -Credential domain\user
$attributes=[system.io.file]::GetAttributes("mydrive:\path\")
returns
Exception calling "GetAttributes" with "1" argument(s): "The given path's format is not supported."
.NET knows nothing about PowerShell drives (and typically also has a different working directory), so conversion to a filesystem-native path is necessary:
In PowerShell code:
Use Convert-Path to convert a PowerShell-drive-based path to a native filesystem path that .NET types understand:
$attributes=[System.IO.File]::GetAttributes((Convert-Path "mydrive:\path\"))
By default (positional argument use) and with -Path, Convert-Path performs wildcard resolution; to suppress the latter, use the -LiteralPath parameter.
Caveat: Convert-Path only works with existing paths. Lifting that restriction is the subject of the feature request in GitHub issue #2993.
In C# code:
In PSCmdlet-derived cmdlets:
Use GetUnresolvedProviderPathFromPSPath() to translate a PS-drive-based path into a native-drive-based path[1] unresolved, which means that, aside from translating the drive part:
the existence of the path is not verified (but the drive name must exist)
and no wildcard resolution is performed.
Use GetResolvedProviderPathFromPSPath() to resolve a PS-drive-based path to a native-drive-based one, which means that, aside from translating the drive part:
wildcard resolution is performed, yielding potentially multiple paths or even none.
literal path components must exist.
Use the CurrentProviderLocation() method with provider ID "FileSystem" to get the current filesystem location's path as a System.Management.Automation.PathInfo instance; that instance's .Path property and .ToString() method return the PS form of the path; use the .ProviderPath property to get the native representation.
Here's a simple ad-hoc compiled cmdlet that exercises both methods:
# Compiles a Get-NativePath cmdlet and adds it to the session.
Add-Type #'
using System;
using System.Management.Automation;
[Cmdlet("Get", "NativePath")]
public class GetNativePathCommand : PSCmdlet {
[Parameter(Mandatory=true,Position=0)]
public string PSPath { get; set; }
protected override void ProcessRecord() {
WriteObject("Current directory:");
WriteObject(" PS form: " + CurrentProviderLocation("FileSystem"));
WriteObject(" Native form: " + CurrentProviderLocation("FileSystem").ProviderPath);
//
WriteObject("Path argument in native form:");
WriteObject(" Unresolved:");
WriteObject(" " + GetUnresolvedProviderPathFromPSPath(PSPath));
//
WriteObject(" Resolved:");
ProviderInfo pi;
foreach (var p in GetResolvedProviderPathFromPSPath(PSPath, out pi))
{
WriteObject(" " + p);
}
}
}
'# -PassThru | % Assembly | Import-Module
You can test it as follows:
# Create a foo: drive whose root is the current directory.
$null = New-PSDrive foo filesystem .
# Change to foo:
Push-Location foo:\
# Pass a wildcard path based on the new drive to the cmdlet
# and have it translated to a native path, both unresolved and resolved;
# also print the current directory, both in PS form and in native form.
Get-NativePath foo:\*.txt
If your current directory is C:\Temp and it happens to contain text files a.txt and b.txt, you'll see the following output:
Current directory:
PS form: foo:\
Native form: C:\Temp\
Path argument in native form:
Unresolved:
C:\Temp\*.txt
Resolved:
C:\Temp\a.txt
C:\Temp\b.txt
[1] If a PS drive (created with New-PSDrive) referenced in the input path is defined in terms of a UNC path, the resulting native path will be a UNC path too.

Run C# code on linux terminal

How can I execute a C# code on a linux terminal as a shell script.
I have this sample code:
public string Check(string _IPaddress,string _Port, int _SmsID)
{
ClassGlobal._client = new TcpClient(_IPaddress, Convert.ToInt32(_Port));
ClassGlobal.SMSID = _SmsID;
string _result = SendToCAS(_IPaddress, _Port, _SmsID );
if (_result != "") return (_result);
string _acoknoledgement = GetFromCAS();
return _acoknoledgement;
}
When I run a shell bash I use #!/bin/bash. There is how to do the same with C#?
Of course it can be done and the process is extremely simple.
Here I am explaining the steps for Ubuntu Linux.
Open terminal:
Ctrl + Alt + T
Type
gedit hello.cs
In the gedit window that opens paste the following example code:
using System;
class HelloWorld {
static void Main() {
Console.WriteLine("Hello World!");
}
}
Save and close gedit.
Back in terminal type:
sudo apt update
sudo apt install mono-complete
mcs -out:hello.exe hello.cs
mono hello.exe
Output:
Hello World!
NOTE: #adabru's answer below makes my solution obsolete unless you are using an older mono platform.
C# scripts can be run from the bash command line just like Python and Perl scripts, but it takes a small bit of bash magic to make it work. As Corey mentioned above, you must first install Mono on your machine. Then, save the following code in an executable bash script on your Linux machine:
if [ ! -f "$1" ]; then
dmcs_args=$1
shift
else
dmcs_args=""
fi
script=$1
shift
input_cs="$(mktemp)"
output_exe="$(mktemp)"
tail -n +2 $script > $input_cs
dmcs $dmcs_args $input_cs -out:${output_exe} && mono $output_exe $#
rm -f $input_cs $output_exe
Assuming you saved the above script as /usr/bin/csexec, an example C# "script" follows:
#!/usr/bin/csexec -r:System.Windows.Forms.dll -r:System.Drawing.dll
using System;
using System.Drawing;
using System.Windows.Forms;
public class Program
{
public static void Main(string[] args)
{
Console.WriteLine("Hello Console");
Console.WriteLine("Arguments: " + string.Join(", ", args));
MessageBox.Show("Hello GUI");
}
}
Save the above code to a file such as "hello.cs", make it executable, change the first line to point to the previously saved bash script, and then execute it, you should see the following output along with a dialog saying "Hello GUI":
bash-4.2$ ./hello.cs foo bar baz
Hello Console
Arguments: foo, bar, baz
Note that the GUI requires that you be at run level 5. Here is a simpler C# script that runs at a pure text console:
#!/usr/bin/csexec
using System;
public class Program
{
public static void Main(string[] args)
{
Console.WriteLine("Hello Console");
Console.WriteLine("Arguments: " + string.Join(", ", args));
}
}
Notice that the command line arguments are passed to the C# script, but the shebang arguments (in the first C# script above "-r:System.Windows.Forms.dll -r:System.Drawing.dll") are passed to the C# compiler. Using the latter functionality, you can specify any compiler arguments you require on the first line of your C# script.
If you are interested in the details of how the bash script works, shebang (#!) lumps together all arguments passed to it on the first line of the C# script, followed by the script name, followed by command line arguments passed to the script itself. In the first C# example above, the following 5 arguments would be passed into the bash script (delineated by quotes):
"-r:System.Windows.Forms.dll -r:System.Drawing.dll" "hello.cs" "foo" "bar" "baz"
The script determines that the first argument is not a filename and assumes it contains arguments for the C# compiler. It then strips off the first line of the C# script using 'tail' and saves the result to a temporary file (since the C# compiler does not read from stdin). Finally, the output of the compiler is saved to another temporary file and executed in mono with the original arguments passed to the script. The 'shift' operator is used to eliminate the compiler arguments and the script name, leaving behind only the script arguments.
Compilation errors will be dumped to the command line when the C# script is executed.
The #! (hashbang) tag is used to tell the shell which interpreter to use so that your perl, php, bash, sh, etc. scripts will run right.
But C# is not a scripting language, it is intended to be compiled into an executable format. You need to install at least a compiler and runtime if you want to use C#, and preferably an IDE (Integrated Development Environment) to help you develop and debug your applications.
Install Mono for the compiler and runtime, then MonoDevelop for the IDE.
After installing mono you can use csharp hello.cs. Starting with Mono 2.10, you can also use the shebang like this:
#!/usr/bin/csharp
Console.WriteLine ("Hello, World");
If you need assemblies, you can load them e.g. with the line LoadAssembly("System.IO.Compression") inside your script.
Reference: man csharp.
You can't execute C# like a script, you have to compile it first. For that, you could install mono.
You can then compile your program with mcs and execute it with mono.
First, you have to install mono
sudo apt install mono-complete
Commands to execute
mcs -out:$1.exe $1.cs
mono $1.exe
You can add these in a script to make the process easier. Create a shell sript and add the parent directory to the PATH environment variable.
Example:
export PATH=$PATH":$HOME/Desktop/customcommands"
And also give execute permission to the script file.
Shell script:
#!/bin/sh
dpkg -s mono-complete > /dev/null
if [ $? -eq 0 ]; then
echo
else
read -p "Package mono-complete not installed. Press y to install or n to quit." response
yes="y"
if [ "$response" = "y" ];
then
sudo apt install mono-complete
echo " "
echo " "
fi
fi
mcs -out:$1.exe $1.cs
mono $1.exe

Calling Matlab Compiler from inside C# app throws exception

I found this code to invoke the Matlab compiler, it works fine when the function is called from Matlab command prompt, I build this function to .Net Assembly but whenever I try to use it in my C# app in order to build some .m file I get an exception, where do you think my problem is?
Matlab Code:
function compileCode(mfile,dllName , dnetdir)
%% Create directories if needed
if (exist(dnetdir, 'dir') ~= 7)
mkdir(dnetdir);
end
%% Build .NET Assembly
eval(['mcc -N -d ''' dnetdir ''' -W ''dotnet:' dllName ',' ...
'' dllName ',0.0,private'' -T link:lib ''' mfile '''']);
end
C# code:
var cmm = new compiler.MatlabCompiler();
MWCharArray x = new MWCharArray(#"C:\Users\ePezhman\Documents\MATLAB\Graph2D.m");
MWCharArray y = new MWCharArray("Graph");
MWCharArray z = new MWCharArray(#"C:\Matlab\dotnet");
cmm.compileCode(x,y,z);
Exception:
... MWMCR::EvaluateFunction error ... Undefined function 'mcc' for
input arguments of type 'char'. Error in => compileCode.m at line 9.
... Matlab M-code Stack Trace ...
at file C:\Users\ePezhman\AppData\Local\Temp\ePezhman\mcrCache8.0\compil0\compiler\compileCode.m,
name compileCode, line 9.
Interesting, I assume you are trying to compile a function that can dynamically compile other functions..
Unfortunately, I dont think the mcc function can be compiled/deployed itself
To be exact, the problem you are seeing is because MATLAB needs to know all functions called at compile-time, and by using eval, it wont figure it out on its own (since it wont parse inside the string). You can fix this particular issue by writing special comments for the compiler..
function myEval()
%#function foo
eval('...');
end
(Another alternative is using function handles).
Still even if you do that, it will fail at runtime inside the mcc function saying that: "License checkout failed, [...] Cannot find a valid license for Compiler".
The reason is as mentioned in the comments, mcc is a development tool and cannot be deployed to standalone programs which only depends on the free MCR runtime.
Think about it, if it was possible, it would defeat the whole purpose of buying licenses for the product, as you could create a standalone program that can compiler other codes without having the Compiler toolbox :)

Categories