I'm quite a newbie in PHP and today I discovered DOTNET class.
So I studied manual, surfed the web to find some example and finally wrote my test app:
Created a new DLL using Framework 4.0 Client Profile
Signed the assembly with a strong name key
Marked assembly as COM-Visible
This is the test code I wrote
using System;
namespace CSharpCOM
{
public class CSharpCOMClass
{
public string Base64(string s)
{
return Convert.ToBase64String(System.Text.Encoding.UTF8.GetBytes(s));
}
}
}
I compiled the assembly and then registered in GAC (gacutil /if fullpath\CSharpCOM.dll).
If I use gacutil /l CSharpCOM I see
La cache di assembly globale contiene gli assembly seguenti:
csharpcom, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=beb607ae770f5750, processorArchitecture=MSIL
Numero di elementi = 1
So everything seems ok.
Then wrote this basic php:
<?php
try{
$csclass = new DOTNET("CSharpCOM, Version=1.0.0.0, Culture=neutral, " .
"PublicKeyToken=beb607ae770f5750",
"CSharpCOM.CSharpCOMClass");
echo $csclass->Base64("Test string"),"\n";
} catch (Exception $e) {
echo 'Caught exception: ', $e->getMessage(), "\n";
}
?>
Whatever I try, loading page hosted in Apache (http://localhost/test01/dotnet.php) I always get
Caught exception: Failed to instantiate .Net object [CreateInstance]
[0x80070002] Impossibile trovare il file specificato.
Translation could be: unable to find specified file
Just another thing: using some example (a very basic one here) I read that my assembly (when registered) should be found on %windir%\assembly, but I'm only able to find it in %windi%\Microsoft.NET\assembly\GAC_MSIL\CSharpCOM\v4.0_1.0.0.0__beb607ae770f5750: is this correct? Why don't I have it on first directory?
More: if I create another framework project and try to add a .NET reference I can't find my assembly: is this related to the fact I'm not able to load this assembly from PHP?
Last note: I tried it on Windows XP Professional SP3 32bit and on Windows Seven Enterprise 64bit
UPDATE:
This works:
$form = new DOTNET('System.Windows.Forms, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089', 'System.Windows.Forms.Form');
but this one does not:
$form = new DOTNET('System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089', 'System.Windows.Forms.Form');`
Is it possible that PHP can load only framework 2.0 assemblies?
According to this bug report the DOTNET class is not loading .NET 4.0 DLLs. If you're not using any of the new libraries in .NET 4.0 you can target your to .NET 3.5 or lower by opening the project properties and on the "Application" tab change the "Target framework" to ".NET Framework 3.5 Client Profile"
Now when you install your DLL into the GAC it will get installed into the CLR 2.0 GAC and should be able to be loaded using the DOTNET class in PHP.
There is a library out there called NetPhp (https://github.com/david-garcia-garcia/netphp) that will let you:
Use any .Net binaries (even without COM Visibility) and ANY version of the .Net framework including CLR4
Dump a PHP class model
Iterate over .Net collections directly from PHP
PHP class model generation, to use PHP classes as if it where .Net
Automatic propagation of .Net errors into native PHP exceptions that can be properly handled
Acces native enums and static methods
Use class constructors with parameters
Debug .Net and PHP code at the same time as if it was a single application.
There is a project with code samples here:
https://github.com/david-garcia-garcia/netphp-sample
This is what a piece of code with NetPhp looks like:
$datetime = $runtime->TypeFromName("System.DateTime");
$datetime->Instantiate();
echo $datetime->ToShortDateString()->Val(); // Outputs 01/01/0001
// We can only use Int32 from native PHP, so parse
// an Int64 that is equivalent to (long) in the DateTime constructor.
$ticks = $runtime->TypeFromName("System.Int64")->Parse('98566569856565656');
$ticks = \ms\System\netInt64::_Parse('98566569856565656');
$datetime->Instantiate($ticks);
echo $datetime->ToShortDateString()->Val(); // Outputs 07/05/0313
$now = $runtime->TypeFromName("System.DateTime")->Now;
echo $now->ToShortDateString()->Val(); // Outputs "23/10/2015"
$now = $runtime->TypeFromName("System.DateTime")->Now();
echo $now->ToShortDateString()->Val(); // Outputs "23/10/2015"
$timer = $runtime->TypeFromName("System.Timers.Timer")->Instantiate();
$timer->AutoReset(TRUE);
$timer->AutoReset = TRUE;
Related
We have a software product that is currently released that is a .NET Framework 4.7.2 application (the "legacy" app). The legacy client-server implementation is built on System.Runtime.Remoting, which is not supported in .NET 5 and later, so the .NET 5 implementation is gRPC.
It is necessary to instantiate each of the two COM servers in turn because the legacy and the .NET 5 COM servers can only connect to the comm (not COM) server application that implements the same communications framework, which are System.Runtime.Remoting and gRPC, respectively.
The COM servers are used by third party applications to interface with the comm server application, so I am currently working on creating a static class that returns the interface from the COM server that can connect to the currently running instance of the comm server.
I have a .NET 5 WPF implementation of the product almost complete, but I've hit a roadblock in that, I am unable to register the .NET COM server.
I found these two articles:
Exposing .NET Core Components to COM
GitHub Issue
I have now been able to:
Create a Type Library
I found a comment from #SimonMourier suggesting copying the .NET 5 COM server code into a .NET Framework project and use RegAsm to export the type library to be used in the .NET 5 project. The type library was added to the .NET 5 COM server project folder and "" was added to an ItemGroup in the .csproj file per the first referenced article.
Register the .NET 5 COM server
This required using the "dotnet publish -r win-x64 -c Debug" command in the project folder from the Visual Studio Developer Command Line. I was then able to use regsvr32 to register the WinCalRemoting.comhost.dll in the "bin\Debug\net5.0\win-x64\publish" project directory.
Create an Instance of the COM Class
After registering the COM server, I am now able to create an instance of the COM class, but haven't been successful at getting the interface from it:
public static IWinCalClient LoadCompatibleRemotingClient(bool useClientEventWindow, string serverName, int serverPort, bool connectToServer = true)
{
UseClientEventWindow = useClientEventWindow;
WinCalServerName = serverName;
WinCalServerPort = serverPort;
ClassIdList = new Guid[]
{
LegacyWinCalClientClsId, // CAN'T GET INTERFACE FROM THIS COM SERVER
//WinCal5ClientClsId // THE .NET 5 COM SERVER WORKS
};
if (RemotingClassObject != null)
{
UnloadClient();
}
foreach (Guid clsId in ClassIdList)
{
try
{
RemotingClassObject = Activator.CreateInstance(Type.GetTypeFromCLSID(clsId, true));
}
catch (Exception e)
{
continue;
}
if (RemotingClassObject != null)
{
RemotingInterface = (IWinCalClient)RemotingClassObject;
if (RemotingInterface == null)
{
UnloadClient();
continue;
}
if (CanClientConnect(_RemotingInterface, connectToServer))
{
break;
}
}
if (Marshal.IsComObject(RemotingClassObject))
{
Marshal.FinalReleaseComObject(RemotingClassObject);
}
RemotingClassObject = null;
}
return RemotingInterface;
}
Update on the exception
After correcting the "bitness" of the test COM Client application that #SimonMourier clued me to, I am able to get the interface from the .NET 5 COM server. I have updated the code from the method.
HOWEVER, I'm now struggling with getting the interface from the .NET Framework COM server in the same way I get it from the .NET 5 COM server. I successfully register it using RegAsm.exe, but I get the following exception:
System.InvalidCastException: 'Unable to cast object of type 'CMI.WinCalRemoting.cWinCalClient' to type 'CMI.WinCalRemoting.IWinCalClient'.'.
I've done an exhaustive search to try to find out how to fix the .NET Framework COM project so that it can be used in the same way that the .NET 5 COM server is used so that it doesn't matter whether the COM client is a .NET Framework or a .NET Core assembly.
I added a .NET Framework COM server project to the shared directory below to replicate what I'm seeing. With the .NET Framework COM server.
I also switched the test application to be 32-bit to replicate how our sister application will be using the COM servers.
All of the projects are located here:
.NET 5 COM Interop
Unable to Add .NET Framework COM Type Library Reference
For a .NET Framework client assembly, I've attempted to add a reference to the .NET Framework COM server that was registered with regasm.exe, but that fails with the following message:
I've managed to boil down my test to a simple command:
PS C:\Users\CpUser> [System.Reflection.Assembly]::LoadFrom("C:\Users\CpUser\.nuget\packages\njsonschema\10.4.0\lib\net45\NJsonSchema.dll")
MethodInvocationException: Exception calling "LoadFrom" with "1" argument(s): "Could not load file or assembly 'NJsonSchema, Version=10.4.0.0, Culture=neutral, PublicKeyToken=c2f9c3bdfae56102'."
I'm using 64-bit Powershell v7.1.3 on Windows 10. Ran as administrator. It's not able to load the DLL I gave it, which is very odd to me. It also does not give me any detail as to why it cannot load it. When I try a lower version of NJsonSchema.dll, it works, but it loads it from an unexpected location:
PS C:\Users\CpUser> [System.Reflection.Assembly]::LoadFrom("C:\Users\CpUser\.nuget\packages\njsonschema\9.10.52\lib\net45\NJsonSchema.dll")
GAC Version Location
--- ------- --------
False v4.0.30319 C:\Program Files\PowerShell\7\NJsonSchema.dll
It's loading it from C:\Program Files\Powershell\7 which seems wrong to me. I sent to the Properties -> Details of that DLL and it says it is version 10.2.2. What it seems like is happening here is:
Powershell takes the version of the assembly I provided in the LoadFrom() call
It searches C:\Program Files\PowerShell\7 for the same DLL with a version equal to or greater than the version obtained in the previous step
If not found, fail.
What I expect is for it to load the DLL using the absolute path I gave it.
As a workaround, I found another solution that does seem to work:
$AssemblyPath = "C:\Users\CpUser\.nuget\packages\njsonschema\10.4.0\lib\net45\NJsonSchema.dll"
$bytes = [System.IO.File]::ReadAllBytes($AssemblyPath)
[System.Reflection.Assembly]::Load($bytes)
I get a successful result when I run the above in a script:
PS C:\Users\CpUser> .\testLoadDll.ps1
GAC Version Location
--- ------- --------
False v4.0.30319
So I feel like this rules out any issues with the DLL itself. I'm completely lost here. Can someone explain the behavior I'm seeing and how to get the behavior I expect?
According to the documentation, for Assembly.LoadFrom Method
The LoadFrom method has the following disadvantages. Consider using
Load instead.
...
If an assembly is loaded with LoadFrom, and the probing path includes
an assembly with the same identity but a different location, an
InvalidCastException, MissingMethodException, or other unexpected
behavior can occur.
Update:
According to Resolving PowerShell module assembly dependency conflicts,
PowerShell and .NET
PowerShell runs on the .NET platform. NET is ultimately responsible
for resolving and loading assembly dependencies, so we must understand
how .NET operates here to understand dependency conflicts.
We must also confront the fact that different versions of PowerShell
run on different .NET implementations. In general, PowerShell 5.1 and
below run on .NET Framework, while PowerShell 6 and above run on .NET
Core. These two implementations of .NET load and handle assemblies
differently. This means that resolving dependency conflicts can vary
depending on the underlying .NET platform.
Therefore, ensure you are loading the DLL in the netstandard2.0 folder, if using Powershell version 6 and above.
Try the following:
Open PowerShell version 7.1.3:
In "Type here to search" box, enter pwsh
Right-click PowerShell 7 (x64)
Select Run as administrator
Get PowerShell version:
Get-Host | Select-Object Version
Get Loaded Assemblies:
[System.AppDomain]::CurrentDomain.GetAssemblies()
Load NJsonSchema.dll:
Note: Since we're using PowerShell 7.x.x, use the NJsonSchema.dll file in the netstandard2.0 folder.
$Assembly = [System.Reflection.Assembly]::Loadfile('C:\Users\CpUser\.nuget\packages\njsonschema\10.4.0\lib\netstandard2.0\NJsonSchema.dll')
Get Loaded Assemblies (again):
[System.AppDomain]::CurrentDomain.GetAssemblies()
Check the version of NJsonSchema.dll:
$Assembly.GetName()
I tried to create a simple console application which is using the Microsfot.Kinect.Tools. I add reference to the microsoft.Kinect.Tools.dll. I add the correspond namespace using Microsoft.Kinect.Tools;. I am facing the following exception when I tried to check if the import of the library is working:
Could not load file or assembly "Microsoft.Kinect.Tools" Version=
2.0.0.0, Culture=neutral, PublicKeyToker=..., or one of its dependencies. An attempt make to load a program with an incorrect
format.
What I am trying to do is to create a function that records .xef files:
public void writeXefFiles(String filePath)
{
using (KStudioClient client = KStudio.CreateClient())
{
client.ConnectToService();
...
}
}
However it seems that I cant call that function at all (the exception is rising).
quite possible you have dll in your gac of some other version. Try uninstalling the same:
go to cmd and run the command: gacutil /u Microsoft.Kinect.Tools.dll
other reason could be the configuration: x86 or x64 or any cpu. Make sure you have used the correct configuration.
In my program I have this simple code:
using System;
using System.Data;
using Mono.Data.SqliteClient;
....
IDbConnection cnx = new SqliteConnection("URI=file:reestr.db");
cnx.Open();
....
And this is how I compile it:
$ mcs Test.cs -r:System.Data.dll -r:mono.data.sqliteclient.dll
It compiles ok. But when I run it with ./Test.exe, I get this error messages:
Missing method .ctor in assembly ....
Unhandled Exception:
System.IO.FileNotFoundException: Could not load file or assembly 'Mono.Data.SqliteClient, Version=2.0.0.0, Culture=neutral, PublicKeyToken=0738eb9f132ed756' or one of its dependencies.
File name: 'Mono.Data.SqliteClient, Version=2.0.0.0, Culture=neutral, PublicKeyToken=0738eb9f132ed756'
I'm not sure what I'm doing wrong here and how to repair it.
PS. I'm using Ubuntu as my OS.
It appears that Mono.Data.SqliteClient can not find the native SQLite binaries:
Prerequisites If you do not have SQLite, download it. There are
binaries for Windows and Linux. You can put the .dll or .so along side
your application binaries, or in a system-wide library path.
Ref: http://www.mono-project.com/docs/database-access/providers/sqlite/
To obtain pre-compiled native binaries (or source) for your platform:
http://www.sqlite.org/download.html
Also if you have the SQLite native shared libraries installed, are they available via dlopen? If not, you can assign the LD_LIBRARY_PATH env. var so Mono can find them at runtime.
Linux Shared Library Search Path From the dlopen(3) man page, the
necessary shared libraries needed by the program are searched for in
the following order:
A colon-separated list of directories in the user’s LD_LIBRARY_PATH
environment variable. This is a frequently-used way to allow native
shared libraries to be found by a CLI program. The list of libraries
cached in /etc/ld.so.cache. /etc/ld.so.cache is created by editing
/etc/ld.so.conf and running ldconfig(8). Editing /etc/ld.so.conf is
the preferred way to search additional directories, as opposed to
using LD_LIBRARY_PATH, as this is more secure (it’s more difficult to
get a trojan library into /etc/ld.so.cache than it is to insert it
into LD_LIBRARY_PATH). /lib, followed by /usr/lib.
Ubuntu Notes:
$ sudo apt-get install sqlite
$ ls -1 /usr/lib/libsqlite*
/usr/lib/libsqlite.so.0
/usr/lib/libsqlite.so.0.8.6
$ export LD_LIBRARY_PATH=/usr/lib:$LD_LIBRARY_PATH
$ mono ./Test.exe
I solve the problem in my Mac in this way. Right Click in Mono.Data.Sqlite on References and click in Local Copy. This make mono copy dll to debug folder and your application will find the library.
OBS: Sorry for my bad english.
Here's the code that raises the exception
public Configuration GetConfiguration()
{
var persister = SQLiteConfiguration
.Standard
.UsingFile("Test.db")
.ShowSql();
var configuration = Fluently
.Configure()
.Database(persister)
.Mappings(map => map.FluentMappings.AddFromAssemblyOf<WordMap>())
.BuildConfiguration();
new SchemaExport(configuration).Execute(true, true, false);
return configuration;
}
The full exception text:
Failure: NHibernate.HibernateException : Could not create the driver
from NHibernate.Driver.SQLite20Driver, NHibernate, Version=2.1.2.4000,
Culture=neutral, PublicKeyToken=aa95f207798dfdb4.
----> System.Reflection.TargetInvocationException : Exception has been thrown by the target of an invocation.
----> NHibernate.HibernateException : The IDbCommand and IDbConnection implementation in the assembly System.Data.SQLite could
not be found. Ensure that the assembly System.Data.SQLite is located
in the application directory or in the Global Assembly Cache. If the
assembly is in the GAC, use element in the
application configuration file to specify the full name of the
assembly.
Version of NHibernate is 2.1.2.4000
Version of System.Data.SQLite is 1.0.66.0
Target Framework is 3.5 (x86)
Local copy for System.Data.SQLite is ON.
What may be wrong?
Just copy System.Data.SQLite.dll library to the the base directory of your application (especially where NHibernate.dll library is placed).
You even don't need it to add as reference under VS.
Regards
Bronek
I just installed the SQLite NuGet package and that worked for me.
I got rid of this issue by adding useLegacyV2RuntimeActivationPolicy="true" to app.config. See Problem Upgrading NHibernate SQLite Application to .Net 4.0
Could not create the driver from NHibernate.Driver.SQLite20Driver, NHibernate, Version=2.1.2.4000, Culture=neutral, PublicKeyToken=aa95f207798dfdb4
Solution:
testsettings:
choose hosts
choose run tests in 64 bit process on 64 bit machine
hoping I could help.
merry coding
If LocalCopy is on, is it on for a version of System.Data.SQLite in the start-up project because that's where it'll be looking for it, not in the bin directory of a sub-project.
In VS 2019, in Test -> Processor Architecture for AnyCPU Projects, I changed from x64 to Auto and it solved my problem.