c# - instalar - windows forms c++ visual studio 2017
Portar aplicación de Winforms de VB.NET a C# (7)
¿Hay algún recurso "bueno" 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)?
Actualización :
Como le estaba diciendo a Grauenwolf, mantenerlo en su idioma actual presenta los siguientes problemas:
- No ser capaz de agregar funciones fácilmente. 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 ha sido 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 cualquiera que haya votado la pregunta, no estoy muy seguro de por qué lo 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 en realidad no era una respuesta).
De acuerdo con mi experiencia trabajando con algunas aplicaciones grandes que mezclan proyectos de 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 viejo error en Visual Studio 2003 que descartó ciertas cadenas de referencias de proyectos que mezclaron proyectos C # y VB de maneras específicas, pero es el único con el que me he encontrado como obstáculo práctico).
Los desarrolladores individuales ciertamente tienden a tener una preferencia estilística que favorece a uno u otro, pero una conversión completa es mucho trabajo para hacer por algo que equivale a un gusto por un sabor diferente del azúcar sintáctico.
En mi trabajo, hemos utilizado el traductor de developerfusion , pero no hay nada automatizado (simplemente traduce el fragmento de código o la clase, y pega el resultado manualmente 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 .
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.
Si usa algo como Reflector o Anakrino, su salida se basa en el IL y no en la fuente original. Ya sea que produzca o no un código mejor está abierto al debate ... Pero podría intentarlo de todos modos. :)
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á diseños malos?
El problema no es VB, el problema es el tipo que lo escribió y el tipo que se rehúsa 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.
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 a C # para convertir mi código VB.NET a C #, aprendí de él y también del libro.
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 hacer 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 erros que confunden principalmente el [] con () , problemas con los parámetros de ref y el enhebrado, así como también lo que no. El compilador (VS 2013) ni siquiera fue capaz de descifrar 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 C # Winforms. 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 aún estoy completando el proyecto. Mi experiencia con Cover Cover ha sido muy amarga y no quisiera recomendar a nadie.