2008-12-02 3 views
9

¿Existen recursos 'buenos' para portar una aplicación de winforms de VB.NET a C#? Estoy seguro de que hay software que solo traduce el código, pero estoy buscando refactorizar el código al mismo tiempo. Mantenerlo en su forma actual es problemático, ya que utiliza algunas de las prácticas de 'mal diseño' que permite VB.NET, y complicaría aún más el mantenimiento futuro. ¿Alguien ha pasado por ese proceso y cómo lo hizo? ¿Utilizaste un enfoque de traducción/refactorización? ¿Usó el producto final para recrear la funcionalidad sin mirar la base de código actual durante la mayor parte? ¿Qué recomendaría (colectivamente)?Vinculación de aplicaciones de Winforms VB.NET a C#

actualización:

Como le decía Grauenwolf, manteniéndolo en su idioma actual presenta los siguientes problemas:

  • No ser capaz de añadir fácilmente características. VB.NET no es un lenguaje en el que sea sólido. Aprecio la ironía de aprender el idioma para trasladarlo, pero el mantenimiento futuro deberá dar cuenta de alguien que no conoce VB.NET.
  • El resto de la aplicación se ha portado a C# (hace mucho tiempo, de hecho); todas las funciones que nos gustaría agregar dependen del desacoplamiento de la aplicación (ahora mismo está muy unido). Mis opciones son refactorizarlo en un idioma con el que no estoy muy familiarizado o refactorizarlo en un idioma que entiendo.

Para cualquier persona que votó la cuestión hacia abajo, no estoy realmente seguro de por qué que hizo; la preocupación no es si debería dejarlo en VB.NET; la preocupación es cuál es el costo futuro de no portarlo ahora. Si voy a ahorrar grandes gastos para solucionarlo, ¿por qué no dar un paso más y hacerlo más fácil para un futuro programador?

Nota del autor: No había mirado esta pregunta en años, había una respuesta reciente, así que cambié mi 'respuesta' a la pregunta y borré la 'respuesta' (ya que no era realmente una responder).

Respuesta

16

Basado en mi experiencia trabajando con algunas aplicaciones grandes que mezclan proyectos VB y C#, recomendaría dejarlo en VB.NET. Si hay problemas con el diseño, corríjalos, pero convertir todo en C# me parece una distracción desordenada e innecesaria.

Las diferencias no estilísticas entre los dos idiomas son muy mínimas, por lo que es difícil ver una necesidad funcional que forzaría una conversión. (Hubo un error antiguo en Visual Studio 2003 que descartaba ciertas cadenas de referencias de proyectos que mezclaban proyectos C# y VB de maneras específicas, pero es el único con el que me he encontrado como obstáculo práctico).

Individual los desarrolladores ciertamente tienden a tener una preferencia estilística que favorece a uno u otro, pero una conversión completa es mucho trabajo por algo que equivale a un gusto por un sabor diferente de azúcar sintáctico.

+0

Publiqué más información en una respuesta a la pregunta a continuación. Además, y no sé si esto está relacionado, cada vez que hago clic en 'Ir a la definición' para un componente C# que escribimos (uno que está dentro de otro proyecto en la misma solución), se abre el navegador de objetos en lugar de definición –

+0

¿Alguna idea más? –

+0

La inhabilidad irregular de ir y venir entre los proyectos de C# y VB.NET a través de "Ir a definición" es definitivamente una molestia. Por otro lado, la compilación incremental de VB.NET es realmente agradable (aunque el uso de ReSharper mejora las cosas para C#). – McKenzieG1

6

Si utiliza algo como Reflector o Anakrino, su salida se basa en el IL en lugar de la fuente original. Ya sea que produzca o no un código mejor está abierto al debate ... Pero podría intentarlo de todos modos. :)

+0

Acepto - Descompilar a C# y luego refactorizar los resultados, no debería ser necesario traducirlo en absoluto. –

+0

La última versión de Reflector le permite "optimizar" el decompilador para diferentes versiones del marco y en varios idiomas diferentes. Muy genial. – GalacticCowboy

1

He usado C-Sharpener para hacer la conversión en algunas de nuestras aplicaciones, pero está lejos de ser perfecto. Convirtió aproximadamente el 95% del código, y terminé refactorizando mientras estaba arreglando manualmente el 5% restante.

2

En mi trabajo hemos utilizado el traductor de developerfusion, pero nada automatizado (simplemente traduzca la pieza de código o la clase, y pegue manualmente el resultado en el proyecto C#).

Reflector es una gran herramienta, pero puede encontrar algunos problemas al leer las funciones de lambda.

Para refactorizar, la mejor herramienta que hemos probado es Refactor Pro.

3

Mantenerlo en su forma actual es problemático, ya que utiliza algunas de las prácticas de 'mal diseño' que permite VB.NET, y complicaría aún más el mantenimiento futuro.

¿Y crees que C# no permitirá los malos diseños?

El problema no es VB, el problema es el tipo que lo escribió y el chico que se niega a solucionarlo. Así que da un paso atrás, respira profundamente, luego comienza a arreglar el código. Y quién sabe, puede aprender que algunas de esas 'malas prácticas de diseño' realmente tienen mucho sentido.

+1

Acepto, si algo C# presenta MÁS formas de ahorcarse, porque el lenguaje hace menos por usted. Si hay un problema estructural, simplemente corrígelo en VB. Dicho esto, si el problema es que no te gusta VB o no sabes C# mejor, podrías reescribir ensamblajes problemáticos en C#, pero creo que volver a hacer todo es buscar problemas. C# no ofrece ninguna ventaja tangible sobre VB, solo elija la que prefiera. –

1

Tengo algunas experiencias en VB.NET alrededor de 2 años, pero ahora solo uso C# en mi desarrollo diario. Antes de intentar usar VB.Net to C# para convertir mi código VB.NET en C#, aprendí de él y también del libro.

0

Oo Wow! Soy la última persona en atrapar las cosas. Tengo un código VB.NET muy grande en WinForms y he sido asignado para portarlo a C# y WinForms. Tengo 0 conocimiento de VB pero tuve que realizar la tarea. Utilicé T elerik Online Code Converter para convertir toda la lógica comercial de VB en C#. El convertidor es una tontería y me presentaron alrededor de 5000 errores que confunden principalmente el [] con (), problemas con los parámetros de ref y enhebrar, así como lo que no. El compilador (VS 2013) ni siquiera fue capaz de resolver todos los errores en una sola compilación . Tuve que pasar 2 meses solucionando esos errores y construyendo el proyecto una y otra vez. Copié la interfaz de usuario de WinForms a la interfaz de usuario de Winforms C# - Eso no fue un gran problema y ahora he estado depurando ambos códigos simultáneamente para ver el resultado.

Me gustaría decir que son 4 meses y todavía estoy completando el proyecto. Mi experiencia con la coversion ha sido muy amarga y no quisiera recomendar a nadie.

Cuestiones relacionadas