Преобразование C (не C ++) в C #

Question

У меня есть несколько старых 32-битных DLL-библиотек C, использующих библиотеку прекомпилятора Oracle Pro C (proc.exe) для предоставления примерно сотни вызовов sproc / func еще более старому графическому интерфейсу VB6, который ссылается на эти функции через явные операторы типа объявления, такие как:

Declare Function ConnectToDB Lib "C:\windows\system32\EXTRACT32.DLL" (CXN As CXNdets, ERR As ERRdets) As Long

Все структуры в заголовочных файлах C тщательно копируются во внешнем интерфейсе VB6.По крайней мере, SQL предварительно скомпилирован.

Мой вопрос: стоит ли пытаться наложить интерфейс .Net (путем преобразования в сборку) на код C и обновить VB6 до C #, или вы думаете, что яследует просто отказаться от всего этого и начать с нуля.Как всегда, время имеет первостепенное значение, поэтому я обращаюсь к предыдущему опыту.Я знаю, что если я буду хранить объявления в .Net, мне придется добавить множество сложных декораций, которые я бы хотел избежать.

Мне никогда раньше не приходилось конвертировать C в .Net, поэтому мой главныйвопрос, если все остальное игнорируется, есть ли какие-либо ограничения портирования, которые делают это нецелесообразным?

Answer 1

... По крайней мере, SQL предварительно скомпилирован.

Это единственная причина, по которой у вас есть код на C? Если это так, мой совет - отказаться от этого и просто переписать все это на C # (или даже на VB6, если это то, для чего написано ваше приложение) ... если вы не профилировали его и не можете доказать ощутимую разницу, вы не получить какие-либо преимущества от использования вызовов sql / sproc в C. Вы получите только увеличенные затраты на обслуживание из-за сложности обслуживания этого моста взаимодействия.

Answer 2

Вы должны продолжать использовать DLL в .NET, создавая сборку вокруг объявлений. Эта одна сборка, вероятно, будет проходить немного быстрее в VB.NET, чем C #. Затем добавьте ссылку на свой новый пользовательский интерфейс. Как только вы это сделаете, вы потратите время на преобразование кода C в .NET. Вы делаете это, первоначально сохраняя сборку и заменяя объявления новым .NET-кодом. Вскоре вы замените все и сможете изменить его на другой дизайн.

Убийца времени - нарушение поведения . Чем ближе вы сможете сохранить поведение исходного приложения, тем быстрее будет преобразование. Помните, что нет ничего плохого в ссылках на традиционные библиотеки DLL. .NET построен на многих уровнях API, которые в конечном итоге сводятся к традиционным библиотекам DLL, которые продолжают использоваться Windows. Опять же, когда у вас работает .NET UI, у вас появляется больше времени для работы с ядром и переноса всего в .NET.

Answer 3

Если вы переходите с VB6 на VB.net или C #, отбросьте код C и используйте соответствующие классы ODP.net или LINQ для доступа к этим хранимым процедурам. Поскольку уровень C (насколько я понимаю) не имеет никакой логики, кроме предоставления хранимых процедур, он больше не используется после переключения. Делая это, вы получаете (по крайней мере) намного лучшую обработку исключений (т.е. вообще исключений вместо магических кодов возврата), удобство сопровождения и т. Д.

См. Также: Автоматически создавать классы-оболочки C # вокруг хранимых процедур

Answer 4

I всегда советуйте с особой осторожностью , прежде чем отправлять что-либо переписывать. Если вы используете приличный инструмент для обновления VB6 до .NET, он автоматически преобразует операторы Declare, так что не стоит слишком сильно беспокоиться о них!

Это распространенная ловушка - начинать оптимистично переписывать большую часть программного обеспечения, добиваться хороших успехов на раннем этапе, исправляя некоторые из известных недостатков старой архитектуры, а затем увязнуть в функциональности, которую вы только что взяли. как должное в течение многих лет. В этот момент ваше руководство начинает нервничать, и все может стать очень неудобным. Я был там, и это не весело. Похоже, ваши пользователи уже раздражительны, что является плохим знаком.

... и вот сообщение в блоге от Microsofty, которое соглашается со мной :

Многие компании, с которыми я работал в первые годы .NET, сначала смотрели на переписывание, отчасти вызванное сильным желанием улучшить базовую архитектуру и структуры кода одновременно с переходом на .NET. К сожалению, многие из этих проектов столкнулись с трудностями, а некоторые так и не были завершены. Проблема, которую они пытались решить, была слишком большой

... и некоторые официальные рекомендации от Microsoft UK относительно перехода с VB6 на .NET

Выполнение полной перезаписи на .NET гораздо более затратно и трудно сделать хорошо [чем преобразование] ... мы бы рекомендовали этот подход только для небольшого числа ситуаций.

Может быть, ваша программа небольшая, и вы прекрасно понимаете проблемы, которые она решает, и вы прекрасно умеете оценивать и отслеживать свои проекты, и все будет хорошо.