2011-01-09 21 views
6

Lettore di lunga data, prima domanda. fsi.exe è un eseguibile .NET e quindi contiene il proprio assembly completo di tutti i metodi yummy e whatnot fsi utilizza per eseguire gli script F #.Assemblaggio fsi.exe: qualcuno sa come inserirlo?

Guardando l'assemblea in .NET Reflector (scegli la tua classe, ma Shell è l'esempio migliore) rivela un sacco di nomi di garbage * che sembrano funzioni C++ decorate (per esempio, da Dependency Walker). Incidentalmente e un po 'oltre il punto, gli assembly F # si compilano più o meno allo stesso modo, con molti nomi garbage *, il che mi porta a pensare che fsi.exe sia stato scritto in F #, forse come prova di usabilità?

In ogni caso, ecco la mia domanda: qualcuno ha approfondito FSI.exe e capito come incorporarlo in un'applicazione .NET? Perché mi piacerebbe usare F # come linguaggio di scripting, ma i programmi compilano programmi (a sorpresa) e gli script devono essere eseguiti da fsi.exe, che è inaccettabile nel mio dominio (ho bisogno di una VM persistente). Non mi aspetto una guida su come utilizzare fsi.exe, ma sono curioso di sapere se qualcuno ha giocato con esso e, in tal caso, cosa hai scoperto su come funziona?

Grazie per il vostro tempo.

* Spazzatura a colpo d'occhio. Ovviamente sono formattati in questo modo particolare per una ragione particolare che è sotto il cofano.

+1

Quindi, in pratica, si vuole [eval] (http://en.wikipedia.org/wiki/Eval)? –

+1

Mi sto chiedendo, la licenza di F # permette di incorporare fsi in primo luogo? – Juliet

+0

@ Juliet: Perché dovrebbe essere un problema di licenza? – leppie

risposta

6

Per quanto ne so, fsi.exe non espone alcuna API che è possibile utilizzare per incorporarla nella propria applicazione (ad esempio per implementare lo scripting). Penso che ci sono essenzialmente due opzioni:

  • Se si desidera utilizzare fsi.exe esistente direttamente, l'unico modo è quello di iniziare utilizzando .NET Process classe e di comunicare con esso in qualche modo. Questo dovrebbe essere fattibile - puoi inviare comandi al processo usando l'input standard. Per leggere l'output, è possibile utilizzare l'output standard, ma questo fornisce solo informazioni limitate. Probabilmente sarebbe possibile utilizzare .NET Remoting per comunicare tra fsi.exe e la tua applicazione (ad esempio gli oggetti caricati nel contesto di script in FSI invierebbero informazioni alla tua applicazione tramite Remoting).

  • Un'altra alternativa è utilizzare open-source release di F # e modificare fsi.exe per esporre tutte le informazioni necessarie come API. Ciò richiede uno sforzo maggiore per capire come funziona fsi.exe, ma dovrebbe essere fattibile. Probabilmente non hai bisogno di molte aggiunte: lo stato gestito da FSI contiene cose come le variabili globali.

Per quanto riguarda la licenza - probabilmente non è possibile utilizzare fsi.exe distribuiti con Visual Studio. Non sono sicuro di fsi.exe fornito con la versione CTP. La compilazione dalla fonte (disponibile here) andrà sicuramente bene (perché ha una versione open source).

+0

Grazie per l'input, Tomas.Dopo aver visto il power pack di F #, vedo che è stato scritto in F #, che è deliziosamente ironico. Sono in procinto di approfondire la fonte. Probabilmente è troppo avanzato per adattarmi, ma è comunque interessante. Mi piacerebbe valutarti per la risposta completa, ma non ho il rappresentante per questo. – Tom

+0

È possibile in qualche modo incorporarlo in un altro AppDomain? In questo modo non avrai il sovraccarico di un altro processo .net e forse più facile da gestire architettonicamente. –

+0

@ashley - Purtroppo no, al momento deve essere avviato come processo separato. –

Problemi correlati