.net assemblies createprocess

¿Es posible ejecutar un dll.NET sin un exe para cargarlo?



assemblies createprocess (5)

Tengo curiosidad por saber si hay una manera de ejecutar un método .DLL estático en un proceso nuevo sin tener que crear un .EXE para él.

AFAIK, esto no es posible con DLL de Win32 / 64 nativos. ¿Qué hay de los ensamblados .NET DLL?

ACTUALIZACIÓN : Olvidé mencionar que estoy interesado principalmente en hacer esto mediante programación (desde el código C #, para ser específico).

¡Gracias!

CONCLUSIÓN : Aunque nadie se "atrevió" a explicarlo, todas las respuestas parecen inclinarse hacia el "no". Uno necesita iniciar un proceso a través de una de las formas convencionales (EXE, PowerShell, etc.) y luego convencer a ese proceso para que cargue la DLL y ejecute el código dentro. Supongo que esperaba falsamente que las DLL administradas sean capaces de más.

Gracias de nuevo a todos los que intervinieron!


Mire en el programa rundll32.exe que viene con Windows. Si conoce cierta información sobre la dll, a veces puede usar este programa para ejecutar código en esa dll.


Puede iniciar un proceso y ejecutar una función dll utilizando rundll32.exe dll_name,method_name . En C # puedes hacer algo como esto:

myProcess = new Process {StartInfo = {FileName = "rundll32.exe", Arguments = "my_dll_name.dll,my_function_name"}}; myProcess.Start();

Solo asegúrate de que la DLL esté en tu RUTA. Si está pensando en ejecutar pruebas unitarias de algún tipo, asegúrese de finalizar el proceso con el método TearDown / CleanUp: myProcess.Kill() , de lo contrario, la DLL puede permanecer cargada y no podrá sobrescribirla como parte de su proceso de desarrollo. También debe buscar en este artículo una aplicación de línea de comandos que elimine todos los procesos que contienen su DLL y la agregue a sus eventos de freelib.exe my_dll_name.dll : freelib.exe my_dll_name.dll


Simplemente inicie un indicador de PowerShell.

[Reflection.Assembly]::LoadFile("Name of your dll") [Your.NameSpace.And.TypeName]::YourMethod()

Veo que quieres esto de C #

Cree el tipo usando el nombre de ensamblado calificado:

var t = Type.GetType("NameSpace.Type,Name Of Dll"); var m = t.GetMethod("NameOfMethod"); m.Invoke(null, new object[] { params });

Esto debería empezar.

No sé exactamente lo que quiere decir con "En un nuevo proceso", pero no debería ser difícil incluir esto en un archivo .exe / .ps1 que pueda comenzar con alguna opción en la línea de comandos.

Por lo tanto, no tiene que crear un nuevo archivo .exe para cada DLL que desee invocar.

Pero si desea iniciar un nuevo proceso, debe iniciar un nuevo proceso, esto normalmente se hace iniciando un nuevo .EXE.


Un ensamblado .NET se puede cargar en PowerShell . (Bueno, PowerShell es un EXE, pero no está especializado en ejecutar código desde cualquier ensamblaje en particular)


Opción 1: .NET InstallUtil (parte de la instalación normal de .NET)

Agregue una referencia a System.Configuration.Install luego suelte algo como esto en su ensamblaje:

[System.ComponentModel.RunInstaller(true)] public class Sample : System.Configuration.Install.Installer { public override void Uninstall(System.Collections.IDictionary savedState) { base.Uninstall(savedState); this.Context.LogMessage("This can be in a .dll."); // Do your thing... } }

Entonces abusa de .NET InstallUtil:

%windir%/Microsoft.NET/Framework/v2.0.50727/installutil /logtoconsole=false /logfile= /u [your assembly .dll here]

Puede ser un poco desordenado, especialmente sin que todos los parámetros de la línea de comandos deshabiliten el registro.

Opción 2: usar rundll32 nativo para invertir P / Invocar un método de clase estático

Edición de 2016: Ahora un paquete Nuget: UnmanagedExports ( src )!

Las directivas MSIL desconocidas (msdn forum, 2007) enlazan a una versión beta 1 de la Referencia del programador en lenguaje ensamblador de IL (10/3/2000, pág. 74) que establece:

Si se especifica fromunmanaged, el tiempo de ejecución generará automáticamente un procesador que convertirá la llamada al método no administrado en una llamada administrada, llamará al método y devolverá el resultado al entorno no administrado.

Hay más detalles en el ensamblador Expert .NET 2.0 IL y Inside Microsoft. NET IL Assembler . (Las mejores palabras clave de búsqueda: ilasm vtentry).

Lectura relacionada:

Exportaciones no administradas: no se puede compilar el ensamblaje (, 2010)

Exportaciones no administradas / RGiesecke.DllExport.dll (, 2010)

Cree una DLL de C # que se pueda importar en una aplicación de Delphi usando stdcall (, 2009)

Plantilla de proyecto C # para exportaciones no gestionadas ( Robert Giesecke , 2010) - msbuild, integración vs2010

IKVM.Reflection Update: exporta métodos administrados estáticos como exportaciones de DLL no administradas (mono, 2011)

Método simple de exportación de DLL sin C ++ / CLI (código de proyecto, 2009): ¿no es compatible con 64 bits?

Cómo automatizar la exportación de la función .NET a programas no administrados (codeproject, 2006) - admite 64 bits

¿Se ha agregado algo a .Net 4.0 para admitir los escenarios "Reverse P / Invoke"? (msdn forum, 2010) - listado de código

El código no administrado puede envolver métodos administrados (proyecto de código, 2004)

Posibles inconvenientes:

Gotchas con Reverse Pinvoke (no administrado a devoluciones de llamada de código administrado) (msdn blog, 2006)

Invertir P / Invocar y excepción (msdn blog, 2008)