I was wondering if i can run a dll (c#) with crontab ? The dll is compile with mono.
thx :)
-- EDIT --
Well it can be a .exe. I was looking at daemons on mac and linux, do you think I can run .exe as a daemon.
Why not write a mono-based exe that takes the DLL path and entry point method as parameters? The exe would then use reflection to load the DLL and execute the specified method. (You could opt for convention-over-configuration by specifying something like a DllMain method in your DLL which the exe would know to call automatically. Then just one parameter would be required and the intent of your code more obvious.)
Implementing such an applet would give you a utility similar to RunDll in Windows and allow you to run mono DLLs from cron.
You may want to check out the latest mono release and C# Shell (although I would personally make an exe that called the functions you want from the DLL).
http://www.mono-project.com/CsharpRepl
"On startup the csharp shell will load any C# script files and pre-compiled libraries (ending with .dll) that are located in the ~/.config/csharp directory (on Windows this is the value of Environment.GetFolderPath (Environment.SpecialFolder.ApplicationData)).
The assemblies are loaded first, and then the scripts are executed. This allows your scripts to depend on the code defined in the assemblies.
C# script files are merely files that contains statements and expressions, they can not contain full class definitions, those should be stored and precompiled in DLL files. "
Then you can do things like:
csharp> using System;
csharp> Console.WriteLine ("hello");
hello
csharp>
Related
I want to force the compiled program to use the dll from the %temp% folder.
However, if I do like that
compars.EmbeddedResources.Add(Path.GetTempPath() + "\\Newtonsoft.Json.dll");
compars.ReferencedAssemblies.Add(Path.GetTempPath() + "\\Newtonsoft.Json.dll");
The program crashes.
I have also added using Newtonsoft.Json.dll but I still need to have the Newtonsoft.Json.dll in the same folder as my program, if so, the program isn't crashing, otherwise it crashes even if Newtonsoft.Json.dll is in the %temp% folder. So in general, I want to run the program successfully without having the dll in the same folder, and force it to use the dll from the %temp% or something like that.
You can embed other dlls into your program easier. Please refer to the following link:
stackoverflow.com/questions
You can also use ILMerge to do it automatically.
You can also surround your code with try-catch to get more detailed information. I guess your dll's version is not equal or some similar issues.
Adding the referenced assemblies to the compiler parameters (I assume that is what compars is referring to) will make sure the compiler uses that dll as reference at compile-time. During execution of the compiled program, the operating system will try to locate the referenced assemblies in the "usual way".
There are so many detailed specifications on this that you could read them 24/7 until your death (e.g. https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order).
But to accomplish what you want, namely to have the compiled program use the specific dll from your temp folder at run-time, you can merge it with ILMerge as suggested in Mostafa Khodakarami's answer. The library will become an integral part of yours. Your dll will not be at risk of failing to find the needed reference, but it will also not use a newer version of the referenced library if one is available. Depending on how you do the merging, you also might not be able to share objects created with the library with other third party libraries that also use it, unless you also merge them.
Another tool to do the merging is ILRepack (see https://github.com/gluck/il-repack) which touts itself as being better than ILMerge. We switched from ILMerge to ILRepack because we reached some kind of internal limit on the number of objects in ILMerge.
Finally, you could also have your program load the dll itself "manually" by using
public static System.Reflection.Assembly LoadFrom (string assemblyFile);
(see https://learn.microsoft.com/en-us/dotnet/api/system.reflection.assembly.loadfrom?view=net-6.0)
Call the method like this at the beginning of your program, before any methods are called or objects created that use that library:
Assembly.LoadFrom(Path.GetTempPath() + "\\Newtonsoft.Json.dll");
In my project, some of the algorithms are implemented in python as Modules for calling and libraries such as Numpy/Scipy are used . Now I need to embed these Modules into my UI(implemented by C# and run in Windows 7). There are two reasons I need to package my python modules into a file like DLL(I don't want to package as an .exe because it is not friendly to embed). The first reason is for easily calling, and the second reason is to protect my algorithm source code. Does anyone have any idea?
Finally, I solve my problem by using nuitka. It compile my module into .pyd file, and I can import the module using pythonnet by adding reference Python.Runtime.dll.
My compile command is:nuitka --module --nofreeze-stdlib --recurse-all --recurse-not-to=numpy --recurse-not-to=sklearn --recurse-not-to=pywt --recurse-not-to=matplotlib --recurse-not-to=matplotlib.pyplot --recurse-not-to=scipy.io myfile.py
and my C# code is:
PythonEngine.Initialize();
IntPtr pythonLock = PythonEngine.AcquireLock();
PythonEngine.RunSimpleString("import sys\n");
PythonEngine.RunSimpleString("sys.path.append('C:\\path\\to\\pyd')\n");
PyObject pModule = PythonEngine.ImportModule("modulename");
pModule.InvokeMethod("funcitonname", para1, para2);
Try pythonnet to embed CPython in .NET:
python4.net
I tried to use this way:
DLLImport a variable MFC dll
It works.
The problem is the C++ dll "myDLL" needs another DLL "XDLL",
I found that
the service current fodler when services started is the system32, not where the assemble are !!!
In this case, if I put "XDLL" in system32 it would work...
What I need is away to run it without copying anything to System32 or anyway else
Is it C# windows service issue ? or C++ ? what should I do ?
Thanks
If DLLs are specified by name only, that is without a complete path, then the Dynamic-Link Library Search Order comes into play.
There are lots of ifs and buts with this, but the bottom line is that if you put all the DLLs that your executable needs in the same directory as the executable, then the loader will be able to find the DLLs. That is the best practice because it requires no configuration, and you can be certain of which version of the DLL is to be loaded.
I have a small WPF application written in C# using VS2008. For one particular task I would like to use some C++/CLI code (since it requires heavy native interop).
I know I can compile the C++/CLI code as a DLL and then reference this from the C# app, but that seems silly when the code in question is going to be fairly small. I want to build them into the same file. (And without extracting a DLL at runtime.)
Via some command-line-compiler magic (similar to that shown here) I have managed to successfully get this to compile and work when compiling C++ code into a C# DLL, for a different application.
When trying the same thing to compile C++ code into a C# EXE, however, while the compile and link works fine, trying to run the resulting executable results in the following error:
Error while trying to run project: Attempt to load an unverifiable executable with fixups (IAT with more than 2 sections or a TLS section.) (Exception from HRESULT: 0x80131019)
The command lines are basically:
cl /nologo /clr /Zi /MDd /DWIN32 /D_LIB /FUmanaged.dll /c interface.cpp /FoDebug\interface.obj
csc /target:module /addmodule:Debug\interface.obj /r:managed.dll App.cs MainWindow.xaml.cs Debug\MainWindow.xaml.g.cs Properties\AssemblyInfo.cs /out:Debug\Program.netmodule
link /entry:TestApp.App.Main /subsystem:Windows /clrimagetype:ijw /debug /ltcg /manifest /out:Debug\TestApp.exe Debug\App.netmodule Debug\interface.obj
Any ideas where it's going wrong? (managed.dll is a separate C# DLL containing common definitions required by both parts of the code. I'm ok with keeping this separate and it's not really related to the problem at hand, but I've included it for completeness.)
The link command line for the working DLL version is basically the same except that it uses /dll instead of /entry: /subsystem: /clrimagetype:. I've tried removing each of those and only the last seems optional and removing it did not help.
Can I compile an IronPython code to EXE or DLL in a .NET runtime?
Simply use clr.CompileModules in an IronPython script to convert it to a dll file.
Or you can use pyc.py (found inside of your IronPythonInstallDirectory\Tools\Scripts) which can also generate an exe for you also.
If I really, really needed that I would create a wrapper DLL/EXE in another language. The Python code can then be stored as a resource in the DLL that is loaded when the assembly is first accessed.
Yes you can! I posted a Python script which can take an IronPython file, figure out its dependencies and compile the lot into a standalone binary at Ironpython 2.6 .py -> .exe. Hope you find it useful.