Compilar codigo en tiempo de ejecucion?

Heberto,

Mira este artículo, de uno de los miembros más destacados de la comunidad
Fox (y también .NET) en USA:

http://www.west-wind.com/presentati...icCode.htm

Slds - Octavio


"Heberto Villavicencio" escribió en el mensaje
news:OAR%

Saludos, se puede implementar en C# compilar y ejecutar codigo en tiempo
de ejecucion, es decir, algo como esto:

COMPILE ("C:\DATOS\IMPRIME.PRG")
DO ("C:\DATOS\IMPRIME.PRG")

Coloco la anologia desde FoxPro que es con lo que trabajo actualmente pero
estoy planteandome migrar a .NET y escogi C# como proximo lenguaje de
trabajo.
Gracias por sus comentarios

Hola Heberto

Yo no usaría código compilado en tiempo de ejecución, lo haría usando
iyección de dependencia.

El sistema conocería la interface que debe impelmentar la clase que cambia
según el cliente.
En un archivo de configuración le pondría cual el assembly y la calse que
debe utilizar.
Pondría en cada cliente el assembly personalizado para su caso.

Esto no se genera dinamicamente, pero por lo que contas no lo necesitas.

Podes compilar en tu cliente si queres utilizando el compilador del
framework y nada cambiara.

Si queres un ejemplo de inyeccion de dependencia te puedo andar un
proyectito que hace eso. ( no la facturación, simplemente instanciar
dinamicamente.)

Seguramente la opcion de Diego sea la que as se ajusta a tu necesidad.

Otra opción es agregar y invocar javascript desde tu aplicación, tiene
Eval(), te suena??? ;), podrías hacerlo asi posiblemente tambien.

Saludos

Daniel A. Calvin
MCP


"Heberto Villavicencio" wrote:

Lo que pasa es que tengo cantidad de sistemas regados, cada cliente imprime
sus facturas segun su formato y criterio, entonces simplemente el
procedimiento que imprime la factura esta almacenado en un PRG en el
cliente, el sistema lo compila en tiempo de ejecucion y lo ejecuta por tal
forma lo unico que tengo que cambiar de un cliente a otro es el
procedimiento de imprimir la factura y esto puedo hacerlo en el mismo
cliente con el notepad por ejemplo. De esta forma evito modificar el proceso
de facturacion del sistema en cada punto que instale. Es evidente que para
cambiar a C# necesitaria tener un proceso similar a este o se perderia dicha
funcionalidad la cual es imprescindible para la aplicacion, ya que
actualmente hay mas de 300 puntos que trabajan de esa forma.


"Diego Jancic" wrote in message
news:
> On 29 mar, 09:38, "Heberto Villavicencio"
> wrote:
>> Saludos, se puede implementar en C# compilar y ejecutar codigo en tiempo
>> de
>> ejecucion, es decir, algo como esto:
>>
>> COMPILE ("C:\DATOS\IMPRIME.PRG")
>> DO ("C:\DATOS\IMPRIME.PRG")
>>
>> Coloco la anologia desde FoxPro que es con lo que trabajo actualmente
>> pero
>> estoy planteandome migrar a .NET y escogi C# como proximo lenguaje de
>> trabajo.
>> Gracias por sus comentarios
>
> Hola,
> Si se puede, aca tenes un ejemplo simple (no tan simple como en
> FoxPro): http://www.codeproject.com/csharp/cscompiler.asp
> De todas formas pensa si realmente es lo que mas te conviene, muchas
> veces compilar codigo es la solucion mas facil de hacer, pero la que
> trae mas problemas. Si queres conta que vas a hacer y te damos una
> mano ;-)
>
> Saludos!
> Diego
>

Hola,
Eso se puede hacer perfectamente, pero es algo que practicamente no se
usa los problemas que causa. Por ejemplo:

1) El codigo lo modificas en tu cliente, pero no en tu maquina de
desarrollo, por lo que tenes 2 versiones diferentes, seguramente en la
proxima actualizacion te olvides de ponerlo. Y si te acordas de
ponerlo posiblemente no sea el mismo codigo. Y si tenes suerte e
hiciste todo bien terminaste escribiendo el mismo codigo 2 veces, no
es muy lindo, no?

2) Seguridad, al hacer eso le estas dando la posibilidad a cualquier
persona de que modifique el codigo en notepad y ejecute algun virus o
algo. Al menos en la implementacion de .net

3) Agregar el codigo usando notepad implica seguramente que no
reacomodaste el codigo, y queda desprolijo. Si es una linea no le veo
mucho problema, pero si son 5 lineas dudo que te tomes el trabajo de
crear una clase encargada de hacer esa tarea, todos los metodos, etc,
etc...

4) Performance, a menos que compiles el archivo SOLO cuando se
modifica, vas a tener una perdida de performance imporatante.

5) Normalmente el cliente no necesita las cosas tan rapido como dice,
un cambio puede tardar 1 o 2 dias en realizarse. A mi criterio es
mucho mejor comercialmente y organizacionalmente dividir bien las
cosas, cuando se esta relevando una nueva funcionalidad no se
programa, y viceversa. Ademas en ninguna empresa importante los
cambios te los realiza la persona con la que hablas. Si queres un
cambio, espera a que lo hagan.

Bueno, creo que hay muchas mas contras sobre mantinibilidad, pero esos
son los puntos por los que no le veo ventaja hacerlo asi. El punto 5
no tiene nada que ver con programacion, pero creo que es uno de los
mas importantes. Al cliente le puede gustar pero me parece poco serio
cambiar el programa en el cliente.

Saludos,
Diego

Eso esta muy bien, pero como le haces por ejemplo para atender 300 clientes
que todos requieran formatos de impresion diferentes por ejemplo, o en el
caso que la configuracion de formatos de impresion (que es el principal
motivo de tenerlo asi) lo hagan terceras personas encargadas de la
configuracion de cada punto, lo que tu planteas me parece que seria algo asi
como que microsoft se encargara de realizar la configuracion de cada windows
que se instalara, impresora tamaño de papel calidad de impresion, colores
etc etc.

Ahora bien se pueden implementar mecanismos de seguridad de tal forma de por
ejemplo si cambio el codigo fuente se puede utilizar algun sistema de
validacion, o disponer de una herramienta externa al sistema que sea la que
compile, pero en cualquier caso para mi la solucion pasa por poder modificar
el codigo en el mismo sitio de la instalacion sin tener que tocar el nucleo
del sistema, ni tener que tener instalado el entorno de desarrollo en el
sitio de instalacion del sistema.


"Diego Jancic" escribió en el mensaje
news:

Hola,
Eso se puede hacer perfectamente, pero es algo que practicamente no se
usa los problemas que causa. Por ejemplo:

1) El codigo lo modificas en tu cliente, pero no en tu maquina de
desarrollo, por lo que tenes 2 versiones diferentes, seguramente en la
proxima actualizacion te olvides de ponerlo. Y si te acordas de
ponerlo posiblemente no sea el mismo codigo. Y si tenes suerte e
hiciste todo bien terminaste escribiendo el mismo codigo 2 veces, no
es muy lindo, no?

2) Seguridad, al hacer eso le estas dando la posibilidad a cualquier
persona de que modifique el codigo en notepad y ejecute algun virus o
algo. Al menos en la implementacion de .net

3) Agregar el codigo usando notepad implica seguramente que no
reacomodaste el codigo, y queda desprolijo. Si es una linea no le veo
mucho problema, pero si son 5 lineas dudo que te tomes el trabajo de
crear una clase encargada de hacer esa tarea, todos los metodos, etc,
etc...

4) Performance, a menos que compiles el archivo SOLO cuando se
modifica, vas a tener una perdida de performance imporatante.

5) Normalmente el cliente no necesita las cosas tan rapido como dice,
un cambio puede tardar 1 o 2 dias en realizarse. A mi criterio es
mucho mejor comercialmente y organizacionalmente dividir bien las
cosas, cuando se esta relevando una nueva funcionalidad no se
programa, y viceversa. Ademas en ninguna empresa importante los
cambios te los realiza la persona con la que hablas. Si queres un
cambio, espera a que lo hagan.

Bueno, creo que hay muchas mas contras sobre mantinibilidad, pero esos
son los puntos por los que no le veo ventaja hacerlo asi. El punto 5
no tiene nada que ver con programacion, pero creo que es uno de los
mas importantes. Al cliente le puede gustar pero me parece poco serio
cambiar el programa en el cliente.

Saludos,
Diego