AdvancedHMI Upgrade: Why Do Forms Break Between Versions?

You open the new AdvancedHMI solution, add your old form, press F5, and the Error List fills with hundreds of entries — most of them the same three or four messages repeated across every control on the screen. The form still looks right in the designer, or it refuses to open in the designer at all. Nothing is wrong with your HMI logic. The designer file is describing controls and properties that the new version's assemblies no longer expose in the same shape.

What the error list is actually telling you

Every WinForms form in an AdvancedHMI project is three files on disk, not one:

File	Contains	Who writes it
MainForm.vb	Your event handlers and custom code	You
MainForm.Designer.vb	InitializeComponent — every control, every property assignment, every driver instance in the component tray	Visual Studio, automatically
MainForm.resx	Embedded images, icons, localized strings	Visual Studio, automatically

The designer file is generated code that hard-codes property names and type names against the version of the AdvancedHMI assemblies you had at the time. Rename a property, move a class to a different namespace, or change a property's type between releases, and every line in InitializeComponent that touched it fails to compile. That is why the error count scales with the number of objects on the form rather than with the complexity of your application.

The 3.5 release is the sharp edge. Upgrading a pre-3.5 project to any post-3.5 version produces a large number of errors purely from property changes, and no import technique avoids them — the properties genuinely moved. Version jumps inside the 3.9.9 family (for example 3.9.9t to 3.9.9yBeta36) also produce a substantial error list, but the errors are highly repetitive and clear quickly.

Which symptom points at which cause?

What you see	Cause	Fix
Same error text repeated on dozens of lines in *.Designer.vb	Property renamed or retyped between versions	Search and Replace across the file, one pass per distinct error
Form opens as code only; designer refuses to load	InitializeComponent will not compile, so the designer cannot instantiate the surface	Clear all compile errors first, then reopen the designer
Imported form has no controls at all	You multi-selected several .vb files in one Add; only the selected files came across, not their .Designer.vb and .resx	Delete, re-add one form per Add operation
Prompted repeatedly to replace existing files while adding MainForm	Expected — the blank project already contains a MainForm trio	Accept the replacement (at least three prompts)
Type or namespace errors on controls you wrote yourself	Custom controls and components were not carried over, or project references are missing	Add the control source files and re-add the references
Dataset-related errors; .xsd will not open as it did in the old project	Typed datasets carry generated designer partial classes and connection settings that do not survive a plain file import	Recreate the dataset in the new project rather than importing it

Two upgrade paths — how do they differ?

Both paths start the same way: install the new AdvancedHMI version to its own folder, open the blank project that ships with it, and confirm it builds and runs before you touch it. From there you either pull forms in one at a time through Add Existing Item, or you copy a whole folder of your own files in through Windows Explorer and include it in the project. This is a Visual Studio behavior, not an AdvancedHMI feature — the folder trick works on any VB.NET solution.

Criterion	Add Existing Item, one form per Add	Copy folder + Include In Project
Prerequisite	None — works on any legacy project	Your forms must already live in a dedicated subfolder, and references must be present
Effort for 1-3 forms	Minutes	No real saving
Effort for 100 forms	100 separate Add operations	One copy, one right-click
Brings companion files	Yes — selecting Form1.vb pulls in the Designer and resx automatically	Yes — everything in the folder comes across
Handles custom controls/components	Only what you explicitly add; usually needs manual fixing	Included if they are in the folder, but references and namespaces still need checking
Handles typed datasets	Poorly	Poorly
MainForm collision	Prompts to overwrite (expected)	Avoided if your MainForm stays outside the folder
Failure mode	Predictable, repetitive compile errors	Can produce a much larger error burst if references or namespaces do not line up

Which one should you use?

Use Add Existing Item, one form per Add, as the default. It is the path that works regardless of how the old project was organized, it is the path that still applies across the 3.9.9 letter releases, and its errors are the predictable kind that Search and Replace clears in a few passes. On a single-form application — one MainForm.vb and its two companions — it is over in under a minute.

Use the folder method when the project was built for it: your forms, your helper classes, and your custom controls already sit in a folder you own, and the new project's references match. That is a design decision made months before the upgrade, not a technique you can apply retroactively. When the folder method throws a wall of errors on a project that was not structured that way, fall back to per-form import rather than fighting it.

An upgrade service is also sold through the AdvancedHMI store if the project is large enough that the conversion labor outweighs the fee.

Procedure: importing forms one at a time

1. Open the blank project shipped with the new AdvancedHMI version. Build it once, unmodified, so you know the baseline compiles.
2. In Solution Explorer, click Show All Files. The .Designer.vb and .resx files are hidden by default, which is why some users only see two files per form.
3. Right-click the AdvancedHMI project node and select Add → Existing Item.
4. Browse to the old project folder and select one file: the .vb whose name matches the form. Do not select the file with Designer in the name, and do not multi-select several forms in a single Add. Selecting Form1.vb alone brings all three Form1 files across; multi-selecting brings only the .vb files and strips every form of its layout.
5. Repeat step 3 and 4 once per form.
6. When you add MainForm.vb, Visual Studio prompts you to replace existing files at least three times. Accept every prompt — you are overwriting the blank project's placeholder MainForm.
7. Re-add any project references the old solution used, and copy in your own helper classes and custom controls.
8. Build. Work the Error List from the top down.

Clearing the error list without going line by line

The errors are repetitive by construction — a renamed property generates one identical error for every control that used it. Read the first error, identify the old token and the new token, then use Find and Replace with the scope set to Entire Solution to fix all instances in one pass. Rebuild after each replacement so the next distinct error surfaces; the count typically drops in large steps rather than one at a time.

Order of attack that saves the most time:

1. Fix errors inside *.Designer.vb first. Until InitializeComponent compiles, the designer will not open and you cannot verify the visual layout.
2. Fix driver and component errors next. Driver instances such as EthernetIPforSLCMicroCom and ModbusTCPCom are serialized into the designer file with their configured properties; a property change on the driver shows up as an error per instance, so three drivers means three identical errors.
3. Fix your own event-handler code last. It usually compiles unchanged, because it references your subroutine names rather than AdvancedHMI internals.
4. Rebuild any typed datasets natively in the new project. Importing the dataset files carries over generated partial classes that do not match, and the designer will not open them the way it did in the original project.

Mixing driver types on one form is not a source of upgrade errors. Three EthernetIPforSLCMicroCom instances plus a ModbusTCPCom instance pointed at a Siemens controller coexist normally — each driver is an independent component with its own connection and its own poll cycle, and controls bind to whichever one they name. The ModbusTCP driver in particular has received fixes across the 3.9.9 letter releases, which is often the reason to upgrade in the first place.

How do you make the next upgrade cheaper?

The expensive part of an upgrade is never your logic — it is the generated designer code you do not control. Two habits shrink it:

Keep event handlers thin. Put one call in the handler and the actual work in a subroutine that lives in a separate file. That file compiles against your own code, not against AdvancedHMI properties, so it moves between versions untouched:

' MainForm.vb - handler only, one line of body
Private Sub HmiObject_Clicked(sender As Object, e As EventArgs) Handles Button1.Click
    MyCustom_HmiObject_Clicked(sender)
End Sub

' MyProjectCode.vb - portable, survives the upgrade unchanged
Friend Sub MyCustom_HmiObject_Clicked(sender As Object)
    ' all real work here
End Sub

Keep your files in your own folder. Forms, helper modules, and custom controls in a single subfolder turn the next upgrade into a copy-and-include instead of an Add-per-form marathon. This only pays off above a handful of forms, and only if the new project's references match what your code expects.

Verifying the upgrade before it goes to the panel

1. Build with zero errors and zero warnings you did not already have in the old project.
2. Open every imported form in the designer. A form that compiles but will not render means the designer is still choking on InitializeComponent.
3. Select each driver component in the tray and confirm its properties survived — IP address, target processor path, and poll settings are serialized values that a botched Search and Replace can silently blank.
4. Run the project offline first and confirm the forms open, navigate, and close without unhandled exceptions.
5. Connect to the live controllers and confirm every control shows live data, not the last design-time value. A tag that reads correctly proves the driver instance, the tag string, and the control binding all reconnected.
6. Exercise one write from each form — a button, a setpoint entry — and confirm the value lands in the controller. Read-back on a display element bound to the same address is the check that closes the loop.

Frequently Asked Questions