Converti DLL in EXE

Un launcher, un sistema di deployment o un dispositivo può accettare solo un programma Windows anche quando il componente disponibile è una DLL. La soluzione pratica consiste generalmente nel creare un host EXE che chiami la DLL, non nel rinominare o convertire meccanicamente il file.

Cos'è il formato DLL

Una DLL (Dynamic Link Library) è un file Windows Portable Executable (PE) contenente codice compilato, dati o risorse che un altro processo carica. Le applicazioni usano le DLL per funzioni condivise, plug-in, codec, provider di database, driver, componenti COM e assembly .NET.

Visual Studio, .NET SDK, MinGW, Delphi e altri toolchain creano DLL. Una DLL normale è progettata per essere caricata da un altro programma ed espone funzioni o classi gestite; normalmente non fornisce l'entry point del processo, l'interfaccia utente e il comportamento di avvio previsto da un EXE.

Cos'è il formato EXE

Un EXE è un file PE destinato ad avviarsi come processo Windows. Il relativo header identifica un executable subsystem e un entry point e può contenere un programma console, un'applicazione grafica, un installer o un servizio. Un EXE può comunque dipendere dalla DLL originale e da altri file runtime, quindi non è automaticamente self-contained.

Come creare un host eseguibile

Quando è disponibile il codice sorgente

1. Identificare se la libreria è native C++, managed .NET o un altro output del compilatore; l'host deve usare un'interfaccia e un'architettura compatibili.
2. In Visual Studio, creare una Console App o Windows App tramite File → New → Project.
3. Aggiungere il progetto della libreria tramite Project → Add Project Reference. Per un binary gestito senza il relativo progetto, aggiungere l'assembly come reference e configurare il relativo file path nel progetto.
4. Implementare l'entry point dell'host: main o WinMain per native C++, oppure Program.cs e Main per un'applicazione .NET. Analizzare gli argomenti, inizializzare le impostazioni necessarie, chiamare la public API della libreria e restituire un exit code appropriato.
5. Eseguire la build tramite Build → Build Solution. Visual Studio normalmente scrive l'EXE in una configuration directory come bin\Release.

Per una libreria gestita, .NET CLI può creare e pubblicare l'host:

dotnet new console -n DllHost
dotnet add DllHost reference ..\Library\Library.csproj
dotnet publish DllHost -c Release -r win-x64 --self-contained true

I file pubblicati vengono visualizzati in DllHost\bin\Release\<target-framework>\win-x64\publish. Sostituire il target framework e il runtime identifier secondo necessità. --self-contained true include il .NET runtime, ma non garantisce un unico file fisico né rimuove le native dependencies.

Quando è disponibile solo una DLL managed .NET

Usare ILSpy per esaminare l'assembly, i relativi public types, gli referenced assemblies, il target framework e i metodi chiamabili. Creare un host C# che faccia reference alla DLL e chiami un metodo pubblico documentato. ILSpy può decompilare il codice per l'analisi, ma l'obfuscation, le dependencies mancanti, l'unsafe code e le restrizioni di licenza possono impedire una ricostruzione funzionante; usare il codice solo quando si dispone dell'autorizzazione.

Per produrre un deployment .NET single-file, impostare PublishSingleFile su true e pubblicare per uno specifico runtime come win-x64. Le native dependencies potrebbero comunque essere estratte a runtime e questo processo non converte una DLL native in managed code.

Quando è disponibile solo una DLL native

Creare un host C++ in Visual Studio o in un altro toolchain compatibile. Eseguire il link con la import library della DLL oppure caricarla a runtime con LoadLibrary e ottenere le funzioni con GetProcAddress. È necessario conoscere il nome di ogni funzione esportata, i tipi dei parametri, il layout delle strutture, la calling convention, le regole di ownership e la sequenza di inizializzazione richiesta. I metodi delle classi C++ generalmente non costituiscono un'interfaccia DLL stabile, a meno che la libreria documenti un ABI compatibile; una API esportata in stile C è più semplice da chiamare.

rundll32.exe example.dll,ExportedFunction non è un converter. Funziona solo con export che corrispondono alla restricted callback signature prevista da rundll32 ed è inadatto per funzioni arbitrarie, metodi C++ o librerie che richiedono argomenti o inizializzazione personalizzati.

Limiti di compatibilità e conversione

• Rinominare library.dll in program.exe modifica solo l'estensione del filename. Non aggiunge un executable entry point né modifica i PE metadata.
• Una DLL può essere un plug-in destinato a uno specifico host, non esporre alcuna public API utilizzabile, richiedere una configurazione o uno stato del registry oppure dipendere da DLL aggiuntive, driver, registrazione COM o runtime Visual C++/.NET. Un wrapper non può sostituire tali requisiti.
• Far corrispondere l'architettura del processo e della libreria: un host x86 richiede una DLL x86, mentre un host x64 richiede una DLL x64. Un processo a 32 bit non può caricare una DLL a 64 bit.
• Gli assembly managed .NET e le DLL native richiedono strumenti diversi. ILSpy è destinato agli assembly managed; i binary native richiedono generalmente codice sorgente, un SDK, la documentazione degli export, header compatibili e un compiler corrispondente. Strumenti come dumpbin /exports di Visual Studio possono esaminare gli export native, ma non possono dedurre i relativi tipi dei parametri.
• Non esiste un reputabile converter online general-purpose in grado di trasformare una DLL arbitraria in un EXE funzionante. I servizi Web di file-conversion non possono inventare un entry point o un wrapper e potrebbero esporre binary proprietari o non sicuri; eseguire il lavoro localmente con Visual Studio, .NET SDK o ILSpy.