Від VB 6.0 до Visual Studio. NET, HTML, XML, DHTML, Інтернет-технології, статті

Випустивши в листопаді 2000 р. бета-версію Visual Studio. NET, корпорація Microsoft публічно показала, як вона збирається реалізовувати на технологічному рівні свою нову архітектуру. NET, яка до того представлялася на рівні досить загальних концепцій. Цілком природно, що реакція громадськості була двоїстої – поряд із схваленням мала місце і критика.


Особливо бурхливо нововведення. NET обговорювалися в співтоваристві VB-програмістів. Представлений варіант VB.NET не залишив сумнівів у тому, що перехід на нову версію VB буде досить складним і болючим. Вперше за десять років існування VB порушилася сумісність програмного коду “знизу вгору”, що робить автоматичне перенесення додатків з VB 6.0 в VB.NET принаймні дуже проблематичним. Крім того, і це найістотніше, змінилася логіка і концепції розробки (див. також статтю “В очікуванні Visual Studio. NET”, “BYTE / Росія” № 1 / 2001).


Здавалося б, у Microsoft VB.NET нарешті було виконано давнє вимога VB-програмістів – максимально наблизити їх інструмент до можливостей “справжніх” мов програмування, таких, як C / C + +, зокрема, прибравши численні обмеження і реалізувавши повноцінний режим об’єктно-орієнтованого програмування. Але, як це часто буває в житті, у медалі виявився і зворотний бік, а достоїнств супроводжували серйозні недоліки. Перш за все для освоєння оновленого інструменту потрібні чималі зусилля. Проблема посилюється ще й тим, що величезна (що налічує за різними оцінками від 2 до 4 млн) армія VB-програмістів дуже неоднорідна по кваліфікації й характеру вирішуваних завдань. Саме це зумовило розкол VB-спільноти на дві частини по відношенню до нового інструменту. Прихильники VB.NET підкреслюють, що новий VB дає можливість створювати додатки масштабу підприємства, в тому числі Web-і серверні додатки. Противники говорили про серйозну загрозу стабільності величезної бази існуючого VB-коду і значних витратах на перенавчання програмістів.


Учасники дискусії керувалися суто практичними інтересами – всі розуміли, що реалізація нововведень VB.NET може серйозно вплинути на їх особисту долю. Адже перехід від нинішньої архітектури Windows до майбутньої. NET може виявитися таким же болісним, як і перехід від DOS до Windows на початку 1990-х.


Поява в червні 2001 року Visual Studio. NET Beta 2 підвело риску під жаркими дискусіями – стало очевидно, що Microsoft не збирається йти на скільки-небудь радикальні поступки у відповідь на критику нововведень VB.NET (правда, і раніше ілюзії з цього приводу були тільки у людей, слабо знайомих з бізнес-стратегією дітища Білла Гейтса). Саме тоді VB-розробники повинні були серйозно задуматися над питанням – як жити далі?


В пошуках відповіді на це питання ми в минулому році опублікували цикл статтею “А ти готовий до VB.NET? Поради тим, хто збирається працювати з новою версій VB”. Зараз, через рік, ми підводимо підсумок цього обговорення, причому в нових історичних умовах – VB 6.0 більше не продається і не підтримується, на зміну йому прийшов …


Поспішай не кваплячись


Сформулюємо основний принцип міграції: вона повинна виконуватися поступово, без поспіху і суєти, але в той же час досить впевнено – важливо не втратити час. Повторимо ще раз: перехід від Windows к. NET відбудеться зовсім не миттєво, швидше за все, переломний момент настане через пару років (про це говорять простий ретроспективний аналіз і здоровий глузд, такі ж оцінки дають і провідні аналітичні агентства). Зараз архітектура. NET проходить фактично стадію дослідної експлуатації, за підсумками якої її концепція і конкретні рішення можуть бути піддані певного коригування. Про усталеному її варіанті можна буде говорити після появи версії. NET Framework 2.0 (а ще краще – 3.0).


Послідовність переходу на нові інструменти для різних категорій розробників зазвичай виглядає наступним чином.


На етапі бета-тестування сам постачальник технології та його найближчі партнери випускають зразково-показові програми в маркетингових цілях. Різні незалежні експерти (у тому числі журналісти та письменники) намагаються встигнути видати “гарячу” інформацію. Численні любителі поспішають пограти з новими “штучками”, особливо якщо у них є вільний час. Розробники додаткового інструментарію для програмістів включаються в гру – потрібно випередити конкурентів.


Після виходу офіційної версії в справу вступають розробники “важких” рішень для корпоративного сектора, але плоди їхньої реальної роботи з’являться лише через пару років. Ще через рік-два підключаються розробники, створюють внутріфірмові корпоративні рішення. Ще пізніше з’являються замовні рішення, що виконуються для (або всередині) малих і середніх підприємств.


З урахуванням усього сказаного можна дати два попередніх ради. По-перше, не поспішайте видаляти свою нинішню версію VB. Швидше за все, вона знадобиться для підтримки значної частини наявних у вас програм до закінчення їх життєвого циклу. Хоча VB.NET має робочий номер версії 7.0, але було б правильніше назвати пакет VB.NET 1.0. Для VB-програмістів міграція на. NET буде більш складною, ніж перехід від 16-розрядних версій Windows до 32-розрядним, не кажучи вже про заміну VB 5.0 на VB 6.0. Масштаб змін більш порівняємо з переходом з DOS Basic на Visual Basic, але зараз перехідний період скоротиться до 2-3 років.


По-друге, не відкладайте надовго розставання зі “старим добрим” VB. Пам’ятайте про часи 10-річної давності, коли небажання переходити від функціонально більш потужного Basic PDS 7.1 до “примітивного” і незвичного VB 1.0 обернулося необхідністю міняти професію для достатньо досвідчених програмістів. Не повинно бути ніяких ілюзій з приводу того, що Microsoft буде хоча б якийсь час продовжувати підтримку VB 6.0 (його продажі припинилися 1 червня). Відповідно, починати на ньому розробку нових серйозних програм навряд чи має сенс. А от маленьких … Напевно, на них якраз зручніше освоювати нові системи.


Куди бідному VB-програмісту діватися?


Є кілька відповідей на це питання. Найрадикальніший варіант – змінити професію (як це зробили багато програмістів за часів переходу від DOS до Windows і ще раніше – від ЄС ЕОМ до ПК). Якщо ж ви не збираєтеся цього робити, розробіть чітку стратегію розвитку – для самого себе і для своїх продуктів. Краще було б зайнятися цим ще півтора року тому, але і зараз ще не пізно *.


Однак потрібно мати на увазі, що мова насправді йде не про те, якою мовою писати програми, а про те, на якій операційній платформі ви збираєтеся працювати. Якщо ви не хочете мати справу з. NET і володієте потрібну кваліфікацію, варто подумати про перехід на C + +. З його допомогою ви зможете створювати продуктивні рішення, використовуючи традиційні методи розробки програм (робота з об’єктними модулями, а не тільки з об’єктними бібліотеками), не обмежуючи себе “керованим” кодом і забезпечуючи собі можливість “міжплатформову” міграції, наприклад, в бік Java.


Але якщо говорити про створення програм не системного, а прикладного рівня, то вибір потрібно робити між. NET і Java 2 Platform (раніше уже зазначалося, що порівняння окремих мов, наприклад, C # і Java, некоректно, так як вони є невід’ємні компоненти відповідних платформ, і порівнювати потрібно платформи в цілому). Стратегія вибору, напевно, не повинна визначатися конкретними технологічними деталями. У даному випадку важливо, хочете ви мати справу з платформеними технологіями від одного постачальника або від спільноти постачальників. І той і інший варіант має свої плюси і мінуси.


Якщо ви вирішили робити ставку на Microsoft. NET, то реальний також перехід з VB 6.0 на C #, який має більш гнучкі можливості в порівнянні з VB.NET. Думаю, Microsoft свідомо зберегла певні функціональні відмінності між VB.NET і C #, керуючись в основному маркетинговими міркуваннями типу “розділяй і володарюй”. Втім, потрібно також відзначити, що C # створювався “з чистого аркуша” спеціально під. NET, а при модернізації VB.NET корпорація все ж була змушена враховувати проблему успадкованого коду.


Однак, перш ніж вибрати варіант з C #, потрібно гарненько подумати. Адже розширені функції C # можуть бути просто неактуальними для вас, а синтаксис VB виглядає (у всякому разі для мене) більш чітким і наочним. Принаймні, звичним.


Я впевнений, що абсолютна більшість прикладних завдань будуть вирішуватися за допомогою набору функцій, які підтримуються і в C #, і в VB.NET, тому тут головним чинником стане ступінь володіння тим чи іншим синтаксисом. До того ж ви зможете легко реалізувати технологію змішаного програмування, працюючи на VB.NET і створюючи якісь функції на C # у разі потреби.


Таким чином, найбільш ймовірна послідовність міграції VB-програміста (як індивідуума) виглядає наступним чином:



  1. Вивчення VB.NET і підготовка до переходу на нього (або: вивчення принципів розробки. NET-додатків на прикладі VB.NET).
  2. Первинне освоєння C # на простих прикладах – як знайомі VB-програми реалізуються в C # (і навпаки – тоді ви зможете легко використовувати методичні матеріали по C # для роботи з VB.NET).
  3. Освоєння розширених можливостей C # (відсутніх в VB.NET) і використання їх в проектах в режимі змішаного програмування.
  4. Далі – можливість переходу на C + + або Java.

Міграція VB-програм


У плані розробки нових додатків в середовищі. NET ситуація досить прозора. Краще почати з створення прототипів невеликих некритичних додатків, але при цьому бажано вести такі розробки для широкого кола завдань, щоб вивчити технологію з різних сторін.


Але що робити з критичними додатками? Основна проблема полягає в тому, що при переході з VB 6.0 на VB.NET не зберігається сумісність коду. У зв’язку з цим потрібно відзначити наступні моменти.


Розробляючи сьогодні програми на VB 6.0, потрібно враховувати майбутні проблеми міграції, щоб мінімізувати витрати по перетворенню коду. Саме ці питання розглядалися в торішньому циклі статей “А ти готовий до VB.NET?”.


До складу VB.NET входить майстер Update Wizard, який автоматично перетворює старий VB6-код. Але робить він це не на 100%. А раз так, то будь-яку серйозну програму все одно потрібно буде переглядати, аналізувати і коригувати вручну. Слід пам’ятати, що далеко не у всіх випадках Wizard чесно вказує код, який він не зміг конвертувати. Дуже небезпечні ситуації, коли майстер завершує роботу без видимих проблем, а насправді проблеми є. У будь-якому випадку всі перетворені додатки доведеться заново ретельно тестувати.


Update Wizard працює тільки при завантаженні старого VB-проекту цілком. Якщо ж ви захочете довантажити в. NET-проект окремий модуль, написаний на VB 6.0, то ніяке перетворення взагалі не буде виконуватися. Аналогічно, коли ви простим копіюванням через буфер обміну вставляєте фрагменти вихідного тексту програм з якогось сховища (наприклад, Code Librarian), програма не виконує жодного контролю і автоматичного перетворення, так що ймовірність, що один і той же код буде працювати в VB 6.0 і в VB.NET, дуже невелика (знову ж – варіант, коли він просто не буде працювати, не найгірший).


Для ілюстрації сказаного вище розглянемо простий приклад міграції.


Створіть у VB 6.0 новий додаток типу Standard. На формі встановіть командну кнопку і напишіть для неї такий код:






Private Sub Command1_Click()
Dim NowTime As Long
NowTime = Timer
MsgBox NowTime
End Sub

Зверніть увагу – це код всього модуля форми. А тепер завантажте цей проект в VB.NET і подивіться, що у вас вийшло в результаті роботи Migration Wizard (лістинг 1). Блоки Windows Form Designer generated code і Upgrade Support – чисто службові (правда, незрозуміло, навіщо вони взагалі з’являються у вікні коду), але навіть якщо їх закрити, то відмінності в новій програмі досить помітні:






Option Strict Off
Option Explicit On
Imports VB = Microsoft.VisualBasic
Friend Class Form1
Inherits System.Windows.Forms.Form

Private Sub Command1_Click _
(ByVal eventSender As System.Object, _
ByVal eventArgs As System.EventArgs) _
Handles Command1.Click
Dim NowTime As Integer
NowTime = VB.Timer()
MsgBox(NowTime)
End Sub
End Class


Зверніть увагу, що за замовчуванням VB.NET встановлює режим Option Strict Off, хоча варто було б On.


Щоб показати проблеми, що виникають при автоматичному перетворення коду, створіть у VB 6.0 програма, яка складається з одного BAS-модуля Module1 з простим програмним кодом, що формує список файлів кореневого каталогу:






Sub Main()
“Формуємо список файлів каталогу C: ReDim arrFile $ (100)
ReDim arrF(100) As String
Dim CountFile As Integer
Dim PathName As String

PathName = “C:*.*”
Call FileCount(PathName, CountFile%, arrFile$())
MsgBox “Кількість файлів =” & CountFile%
End Sub

Public Sub FileCount(PathName$, MyDirCount%, arrPath$())
Dim MyDir$
MyDirCount% = 0 “лічильник файлів
MyDir $ = Dir (PathName $, 0) “перший пошук
Do While MyDir$ <> “”
MyDirCount% = MyDirCount% + 1
arrPath$(MyDirCount%) = MyDir$
MyDir $ = Dir “наступний пошук
Loop
End Sub


Тепер, відкривши новий проект в VB.NET, спробуємо для початку підключити до нього модуль Module1.bas. Якщо завантажити модуль “як є”, без перетворення коду, відразу буде видно синтаксичні помилки, проект просто не запуститься.


Після цього відкриємо старий VB-проект в VB.NET цілком. Тепер Update Wizard спрацює, і ми побачимо перетворений код (лістинг 2). Запустимо проект. Синтаксичних помилок не виявлено, але на стадії виконання буде видана помилка An unhandled exception of type “System.InvalidCastException” occurred (неописане виключення типу). У чому ж причина?


Зверніть увагу, що рядки VB-коду

ReDim arrFile$(100)
ReDim arrF(100) As String


в VB.NET прийняли такий вигляд:

Dim arrFile(100) As Object
Dim arrF(100) As String

Другий масив зберіг свій початковий тип, а перший поміняв String на Object (я спеціально включив опису невикористаного масиву arrF, щоб показати це розходження). І це при тому, що у всіх інших місцях Update Wizard правильно відпрацював використання суфіксів для визначення типів даних – в тому числі у процедурі FileCount, де опис arrFile $ () змінилося на arrFile () As String.


Помилка ж, природно, відбувається через невідповідність типів даних. І тут вже виникають додаткові питання не до майстра оновлення, а до самого пакету VB.NET: чому така невідповідність фіксується не на етапі компіляції, а лише на стадії виконання, і чому видається така плутана діагностика?


Вибір оптимальної стратегії


Отже, перенесення VB-програм в VB.NET – зовсім не тривіальна задача. А раз так, варто подумати – чи є взагалі сенс у міграції? За оцінками компанії Gartner, лише 30-40% існуючого сьогодні VB-коду можна буде перевести на платформу. NET, решту доведеться переписувати і перепроектувати.


Таким чином, найкраще вже зараз визначитися зі своїми поточними розробками, які можна розділити на три категорії:



В останню категорію найдоцільніше віднести Web-додатки (VB.NET має тут явні переваги перед VB 6.0) та нові серверні додатки. Що стосується клієнтських додатків, то тут ключовим стає питання – перейшли Чи вже ваші клієнти на виконавчу середу. NET?


Один з найбільш актуальних шляхів використання старого VB-коду в. NET-додатках – його перетворення в COM-об’єкти. Пакет. NET Framework включає спеціальний механізм COM Interop, який забезпечує взаємодія COM-і. NET-компонентів. Ця взаємодія може бути двостороннім – “з. NET в COM” і “з COM в. NET”. У першому випадку використовується спеціальна оболонка RCW (Runtime Callable Wrapper), представляє COM-об’єкт як. NET-об’єкт. У другому випадку діє оболонка CCW (COM Callable Wrapper), що виконує аналогічну трансформацію. NET-об’єкта (малюнок). В принципі при роботі цього механізму не повинно виникати ніяких проблем, хоча є і цілий ряд цікавих нюансів, які можна розглянути в окремій статті.

Схема роботи механізму COM Interop.







Лістинг 1. Результат роботи Migration Wizard VB.NET

Option Strict Off
Option Explicit On
Imports VB = Microsoft.VisualBasic
Friend Class Form1
Inherits System.Windows.Forms.Form
#Region “Windows Form Designer generated code ”
Public Sub New()
MyBase.New()
If m_vb6FormDefInstance _
Is Nothing Then
If m_InitializingDefInstance Then
m_vb6FormDefInstance = Me
Else
Try
“For the start-up form,
” the first instance created is
” the default instance.
If System.Reflection.Assembly.
GetExecutingAssembly.
EntryPoint.DeclaringType _
Is Me.GetType Then
m_vb6FormDefInstance = Me
End If
Catch
End Try
End If
End If
“This call is required by the
” Windows Form Designer.
InitializeComponent()
End Sub
“Form overrides dispose to clean up
“the component list.
Protected Overloads Overrides _
Sub Dispose(ByVal Disposing As Boolean)
If Disposing Then
If Not components Is Nothing Then
components.Dispose()
End If
End If
MyBase.Dispose(Disposing)
End Sub
“Required by the Windows Form Designer
Private components As _
System.ComponentModel.IContainer
Public ToolTip1 As _
System.Windows.Forms.ToolTip
Public WithEvents Command1 As _
System.Windows.Forms.Button
“NOTE: The following procedure is
“required by the Windows Form Designer
“It can be modified using
“the Windows Form Designer.
“Do not modify it using the code editor.
<System.Diagnostics.DebuggerStepThrough()>
Private Sub InitializeComponent()
Me.components = New _
System.ComponentModel.Container()
Me.ToolTip1 = New _
System.Windows.Forms.ToolTip _
(Me.components)
Me.Command1 = New _
System.Windows.Forms.Button()
Me.SuspendLayout()

“Command1
Me.Command1.BackColor = _
System.Drawing.SystemColors.Control
Me.Command1.Cursor = _
System.Windows.Forms.Cursors.Default
Me.Command1.ForeColor = _
System.Drawing.SystemColors.ControlText
Me.Command1.Location = _
New System.Drawing.Point(50, 40)
Me.Command1.Name = “Command1”
Me.Command1.RightToLeft = _
System.Windows.Forms.RightToLeft.No
Me.Command1.Size = _
New System.Drawing.Size(151, 41)
Me.Command1.TabIndex = 0
Me.Command1.Text = “Command1″

“Form1
Me.AutoScaleBaseSize = _
New System.Drawing.Size(6, 15)
Me.ClientSize = _
New System.Drawing.Size(312, 208)
Me.Controls.AddRange _
(New System.Windows.Forms.Control() _
{Me.Command1})
Me.Location = _
New System.Drawing.Point(4, 28)
Me.Name = “Form1”
Me.Text = “Form1”
Me.ResumeLayout(False)

End Sub
#End Region
#Region “Upgrade Support ”
Private Shared _
m_vb6FormDefInstance As Form1
Private Shared _
m_InitializingDefInstance As Boolean
Public Shared _
Property DefInstance() As Form1
Get
If m_vb6FormDefInstance _
Is Nothing OrElse _
m_vb6FormDefInstance.IsDisposed _
Then
m_InitializingDefInstance = True
m_vb6FormDefInstance = New Form1()
m_InitializingDefInstance = False
End If
DefInstance = m_vb6FormDefInstance
End Get
Set
m_vb6FormDefInstance = Value
End Set
End Property
#End Region

Private Sub Command1_Click _
(ByVal eventSender As System.Object, _
ByVal eventArgs As System.EventArgs) _
Handles Command1.Click
Dim NowTime As Integer
NowTime = VB.Timer()
MsgBox(NowTime)
End Sub
End Class

Лістинг 2. Результат перетворення коду прикладу 2

Module Module1

Public Sub Main()
“Формуємо список файлів каталогу C: Dim arrFile (100) As Object
Dim arrF(100) As String
Dim CountFile As Short
Dim PathName As String

PathName = “C:*.*”
Call FileCount _
(PathName, CountFile, arrFile)
MsgBox _
(“Кількість файлів =” & CountFile)
End Sub

Public Sub FileCount _
(ByRef PathName As String, _
ByRef MyDirCount As Short, _
ByRef arrPath() As String)
Dim MyDir As String
MyDirCount = 0 “лічильник файлів
“UPGRADE_WARNING:
“Dir has a new behavior.
“Click for more:
“ms-help://MS.VSCC/commoner/redir/
redirect.htm?keyword=”vbup1041”
MyDir = Dir (PathName, 0) “перший пошук
Do While MyDir <> “”
MyDirCount = MyDirCount + 1
arrPath(MyDirCount) = MyDir
“UPGRADE_WARNING:
“…
MyDir = Dir () “наступний пошук
Loop
End Sub
End Module

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*