Comment fonctionnent les applications hybrides VB6 / .Net dans le monde réel?

Je gère une application VB6 et nous étudions comment migrer vers .Net Nous envisageons de le faire progressivement en implémentant de nouvelles fonctionnalités dans les classes .Net visibles COM et en migrant lentement les fonctionnalités existantes. J'ai trouvé quelques exemples instructifs de «Hello World» sur la façon de le faire et cela fonctionne très bien avec notre application. Mais quel est le comportement réel de ces applications hybrides? Sont-ils stables, maintenables? Notre programme a pour particularité que davantage d'utilisateurs sur le même ordinateur l'utilisent en changeant de compte d'utilisateur.

EDIT: l'application VB6 lit les données d'une connexion USB et les stocke dans une base de données Access. L'utilisateur peut appeler différentes vues sur les données. Les données sont mises en cache dans un périphérique matériel, les interruptions de lecture ne sont donc pas fatales.

EDIT 4 oct. 2015: Il est temps de faire un suivi: nous sommes toujours en train de remplacer pas à pas le code VB6 existant par .Net. Nous avons d'abord pris les routines d'accès aux données, puis la logique commerciale et actuellement une forme après l'autre est convertie en WPF. Nous avons en effet fini par réécrire chaque morceau de code que nous avons converti (dans VB.Net), mais nous pourrions le faire lentement et en même temps améliorer les fonctionnalités. L'application hybride a survécu à la transition vers Windows 8, 8.1 et 10.

EDIT 9 mars 2018: Nous publierons le code entièrement converti le mois prochain. L'application hybride sera prise en charge pendant au moins un an de plus. Il montre principalement des problèmes sur les écrans haute résolution, mais fonctionne bien dans le cas contraire. Pour être honnête, nous avons plus de maux de tête en raison d'installations .Net Framework corrompues et d'installations de dépendances corrompues (parmi lesquelles SQL Server LocalDb) que nous avons des problèmes de compatibilité avec la base de code VB6 ...

J'ai eu un succès incroyable en exposant .NET à VB6 via des interfaces COM. Ce faisant, nous avons pu refactoriser initialement une énorme quantité de code VB6 et configurer un chemin de mise à niveau vers .NET. Gardez simplement à l'esprit que le VB6 idiomatique ne se traduit pas bien en C # ou même VB.NET, vous voudrez donc marcher avec prudence.

Le seul problème que nous avons eu qui était assez ennuyeux était le nombre excessif de reconstructions que nous avons dû faire en raison des modifications apportées à l'interface COM publique. Cela a été résolu par Visual Make .

FWIW, d'après mon expérience, la nécessité de mettre à niveau une application VB6 vers .Net fournit l'excuse idéale pour une réécriture. À moins que les codeurs originaux ne soient de brillants visionnaires, les techniques répandues dans VB6 sont rarement portées proprement sur .Net.

Certains des délices que vous rencontrerez:

1. Vous vous retrouverez avec des références à Microsoft.VisualBasic que vous ne voulez vraiment pas.
2. Ce seront des bogues difficiles à trouver, par exemple lorsque la sous-chaîne VB6 (a, b, c) s'affiche silencieusement sous la forme d'une sous-chaîne (b, c) et explose car elle était basée sur 1 en VB6 et Basé sur 0 dans .Net.
3. Toutes ces conversions implicites faciles à coder sortiront du travail du bois, généralement sur le premier PC qui n'a pas "," comme délimiteur de liste et / ou "." comme séparateur décimal.
4. Vos classes converties n'auront pas la dissimulation de données souhaitable qu'une nouvelle conception devrait apporter.

HTH

Cela devrait bien fonctionner pour vous, il n'y a rien de particulier sur le changement rapide d'utilisateur / plusieurs sessions qui devrait vous poser des problèmes.

En termes de maintenabilité, gardez à l'esprit que le VB6 / VB.NET hybride ne devrait être qu'une solution temporaire: votre plan devrait être de migrer entièrement vers VB.NET au fil du temps.