UI Maker

Design, build, and run .NET desktop apps — without ever leaving VS Code.

UI Maker is an open-source Visual Studio Code extension that brings a drag-and-drop form designer, one-click build/run/debug/release buttons, and project scaffolding for .NET desktop applications (WPF and Windows Forms, C# and Visual Basic) directly into the editor. No more switching to full Visual Studio just to lay out a window.

Visual designer	Side panel

Why UI Maker?

The .NET CLI (dotnet) can create, build, and run desktop apps entirely from VS Code, but there has never been a good visual way to design the UI here. Editing MainWindow.xaml by hand is fine for experts — and a wall for everyone else.

UI Maker closes that gap:

Features

🧰 UI Maker side panel

Click the UI Maker icon in the activity bar (the window-with-controls glyph on the far left) to open the side panel:

• Actions — Open Project (point UI Maker at any .NET project folder on disk — no need to make it the VS Code workspace), New Project, Build, Run, Debug, Release, App Settings, Open Working Folder, and the built-in Guide, one click away. Run and Debug are toggles: a green play button while idle that becomes a red stop button while your app is running. The first row shows the Working Folder — the one project that Run/Build/Debug/Release/App Settings and every file list target. It follows the file you are editing and is per-project (like SFTP configs), so opening a parent folder full of projects never lets one project's action touch another. Click the row to switch projects.
• Recent Projects — every .NET project you open or create, tagged with its type (WinForms · .NET 8, WPF · .NET Framework 4.7.2, …); click one and it becomes the working folder (Run, Build, and the file lists switch to it) without touching your open workspace. Hover a project for one-click Open in New Window, Open Folder in File Explorer, and Remove.
• XAML Windows and WinForms Forms — every designable file in the working project, C# (*.Designer.cs) and Visual Basic (*.Designer.vb) alike; click one to open it straight in the visual designer. Use the + button on a group to add a new window/form, or a row's Duplicate action to copy an existing one (new class name, registered in the project, opened in the designer). The lists update automatically as files change. When the opened folder contains several projects, nothing is listed wholesale — the panel asks you to choose a working folder first, and build output / caches (bin, obj, packages, .vs, node_modules) are never scanned. Files with no visual surface (App.xaml, resource dictionaries, Designer.cs files without InitializeComponent) skip the designer and open straight in the code editor.
• Project Files — everything else in the workspace, sorted into solution-explorer-style categories: Code, Images & Icons, Resources, Data & Config, Project & Solution, and Other, with real file icons and click-to-open. The categories have inline ＋ buttons: New Class File (a .cs or .vb stub matching the working project's language, registered in the project), Add Image, and Add Resource — files are imported into Resources/, registered in Properties/Resources.resx with the right CLR type (Bitmap, Icon, String, or byte[]), and exposed through a regenerated Resources.Designer.cs, so Properties.Resources.name just works.

🎨 Visual Designer for XAML

Open any .xaml window in the UI Maker Designer:

• Toolbox with a search box and Visual Studio's sections. WPF: Button, Label, TextBox, TextBlock, CheckBox, RadioButton, ComboBox, ListBox, DataGrid, Image, ProgressBar, Slider, Border, GroupBox, DatePicker, ContentControl, Frame, Viewbox, UniformGrid, and more, including Ellipse and Rectangle shapes — plus a 24-entry Modern (Styled) section of Apple-ish, dependency-free controls: ToggleSwitch and iOSToggle; ModernButton, SuccessButton, DangerButton, OutlineButton, LinkButton, and RoundIconButton (FAB); ModernTextBox, SearchBox, and ModernSlider; ModernProgressBar, iOSProgressBar, and a Spinner whose ring really rotates (storyboard) — on the canvas too; StatusDot, Badge, PillBadge, and Chip; TitleText and SubtitleText; Card, GlassCard, GradientPanel, and SectionDivider. These are plain WPF elements dressed by a Style/ControlTemplate that UI Maker writes into Window.Resources the first time you drop one (shared templates are injected once) — no NuGet packages, restyle them freely, and the canvas previews the looks. Each instance can have its own colors: toggles get friendly OnColor / OffColor rows in the Properties panel, buttons/badges recolor via Background/Foreground, progress bars via Background (track) and Foreground (fill). The toolbox itself has ▤ Categorized / A–Z sort buttons like the Properties panel, plus the search box. WinForms mirrors the VS toolbox: Common Controls (Button, Label, LinkLabel, TextBox, MaskedTextBox, RichTextBox, CheckBox, RadioButton, CheckedListBox, ComboBox, DomainUpDown, ListBox, ListView, TreeView, PictureBox, ProgressBar, TrackBar, NumericUpDown, DateTimePicker, MonthCalendar, HScrollBar, VScrollBar, WebBrowser, PropertyGrid), Containers (GroupBox, Panel, FlowLayoutPanel, TableLayoutPanel, SplitContainer, Splitter, TabControl), Menus & Toolbars, Data (DataGridView, BindingSource), Components, Dialogs, and Printing (PrintDialog, PrintDocument, PrintPreviewDialog, PageSetupDialog). Drag a tool onto the form or double-click it to add one at a default spot.
• Right-click context menus everywhere — on any control: Cut / Copy / Paste / Duplicate / Delete, Bring to Front / Send to Back, Select Parent, wire the default event, and jump to Properties/Events. Per-type verbs match VS: Add Tab / Remove Tab on TabControls and tab pages, Add Item / Edit Items… on MenuStrip/ToolStrip/StatusStrip, and Edit Items… on ListBox, ComboBox, CheckedListBox, and DomainUpDown (one line per item, written back as Items.AddRange). Right-click the form or the component tray for their own menus.
• Collapsible, resizable side panels — the ⮜ / ⮞ chevron in the Toolbox and Properties headers folds either panel into a thin strip, giving the canvas the full editor width; click the strip to bring the panel back, or drag the splitter between a panel and the canvas to resize it. The designer remembers both choices while the tab stays open.
• Your theme, on the canvas — the designer reads the project's App.xaml (and its merged resource dictionaries): {StaticResource} brushes, implicit styles (TargetType without a key), BasedOn chains, gradient brushes, and template corner rounding all apply, so a dark-themed app previews dark — the canvas matches the running app instead of showing default gray chrome. Toggle-switch templates are recognized too: a CheckBox (or ToggleButton) whose Style/ControlTemplate is a rounded track with a sliding thumb previews as a real switch in the template's own colors, whether the style lives in the window, App.xaml, or a merged dictionary.
• Design canvas that mimics a real window (title bar, client area) with snap-to-grid placement, drag to move, 8-point resize handles — and grips on the window's own edges to resize the form/window itself. Everything is draggable in XAML too: any Grid child moves (centered/stretched children are pinned to Left/Top + Margin on the first drag, exactly like Blend, and keep their Grid cell), children of StackPanel/WrapPanel/DockPanel drag-reorder with a live insertion marker, and a drag can carry a control into a different panel — pull a CheckBox out of a WrapPanel and drop it anywhere in the Grid, or into a Canvas, and the right layout attributes are rewritten for the new parent (target panel highlights while you hover). Multi-select moves as a group (Ctrl/Shift+click, then drag any member), arrow keys nudge the whole selection (Shift = one grid step), and the alignment/distribution toolbar now works for XAML multi-selections as well as WinForms. Multi-select property editing too: with several controls selected the Properties panel shows their shared properties (VS's intersection rule) and every edit — colors, fonts, enums, sizes — applies to the whole group as one undoable change. Zoom with the toolbar dropdown or Ctrl+scroll (25%–300%) — plain scroll pans vertically, Shift+scroll horizontally, matching Visual Studio; the status bar shows the current percentage and clicking it resets to 100%.
• Properties window, Visual Studio style — properties grouped under collapsible categories (Accessibility, Appearance, Behavior, Data, Design, Focus, Layout, Window Style) with a Categorized / A–Z toggle and a description pane at the bottom. Enums and booleans are dropdowns with their defaults shown — in both WinForms and WPF/XAML — colors get a swatch that opens the native color picker plus named-color autocomplete, fonts get curated family and size suggestion lists (WinForms keeps the familiar Segoe UI, 9pt, style=Bold format), and WinForms Anchor is edited with Top/Bottom/Left/Right toggle buttons. WPF brush rows (Background, Foreground, BorderBrush, Fill, Stroke) accept a color name, hex, or {StaticResource} text, and Background has a 🖼 button that imports an image and writes an ImageBrush — so a picture background is two clicks. Color and font rows use editable combos with live previews: every color choice shows a swatch square (your {StaticResource} brushes listed first), font families render in their own face, sizes at their actual size, and weights/styles as themselves — while the text box still accepts bindings and resources. Explicitly-set values render bold, and clearing a value removes it from the file — exactly like VS.
• Images and icons — Image, BackgroundImage, and the form Icon (.png/.jpg/.gif/.bmp/.ico) are picked with a file dialog and imported the way Visual Studio does it: copied into Resources/, registered in Properties/Resources.resx, exposed through a regenerated Resources.Designer.cs, and referenced as Properties.Resources.name in the form code. Placement and scaling are full VS: ImageAlign, TextImageRelation, BackgroundImageLayout, and PictureBox SizeMode — all previewed live on the canvas. WPF gets the same treatment: Image.Source has a … picker, backgrounds accept an ImageBrush via the property grid, imported files are registered as <Resource> build items, and both render as real images on the canvas.
• Events panel — type a handler name (or accept the default) and UI Maker sets the XAML attribute and generates the C# method stub in the .xaml.cs code-behind.
• Double-click a control to wire its default event, exactly like classic designers.
• Multi-select and alignment tools — Ctrl/Shift+click controls, drag the group, then use the toolbar to align edges, match sizes, or distribute evenly. ⇥ Tab Order overlays TabIndex badges; click controls in sequence to re-number them (WinForms).
• Rename controls safely — edit (Name) in the grid and, when the C# language service is installed, UI Maker performs a solution-wide symbol rename just like VS (with a safe Designer/code-behind fallback). Visual Basic renames are case-insensitive and update Handles clauses in the code-behind. Handler names and user-visible strings are kept.
• Component tray — Timer, ToolTip, ContextMenuStrip, NotifyIcon, BackgroundWorker, ImageList, ErrorProvider, HelpProvider, BindingSource, FileSystemWatcher, Process, the file/color/font/folder dialogs, and the printing components drop into a tray below the form, VS-style, with their own properties and events (WinForms). Components that need extra NuGet packages on modern .NET (SerialPort, EventLog, PerformanceCounter, ServiceController, MessageQueue) are left out on purpose so generated code always compiles.
• Menus & status bars — MenuStrip, ToolStrip, and StatusStrip with an Items editor (one line per item) that generates the ToolStrip item classes in the Designer.cs; docked strips push each other for space like the real layout engine, and TabControl drops with two ready pages.
• Keyboard support: arrow keys nudge, Shift+arrows move by grid, Delete removes, Ctrl+D duplicates, Ctrl+X/Ctrl+C/Ctrl+V cut, copy & paste — including onto a different form, and even into a designer in a different VS Code window/project (the copy rides the Windows clipboard). Structural containers/items are guarded from shallow Cut/Duplicate operations until deep cloning can preserve their children. Esc closes menus and clears the selection.

↔️ Split Design / Code view

The View Code button opens the raw XAML beside the designer. Edits flow both ways: change the markup and the canvas refreshes; move a control and the markup updates.

⌨️ XAML IntelliSense in the text editor

Prefer typing markup by hand sometimes? The plain text editor now understands XAML too — no Visual Studio, no extra extensions:

• Element completion — type < and get the whole WPF catalog (panels, controls, shapes, menus, Grid plumbing) with one-line descriptions. Containers insert an open/close pair, leaf controls self-close. Type </ and the innermost still-open tag closes itself.
• Attribute completion — inside a tag you're offered exactly what that element supports: its own properties, the common layout set (Margin, HorizontalAlignment, Grid.Row, DockPanel.Dock, …), and its events. Attributes already on the tag aren't offered twice.
• Value completion — inside the quotes, enums list their members (Visibility → Visible / Hidden / Collapsed), booleans offer True/False, and brush properties offer all 141 named XAML colors with a preview swatch.
• Code snippets — type a prefix and expand a ready block: window (full Window skeleton), grid2x2, gridrows/gridcols, stack, dock (menu + status bar + content shell), button, labeltext, combo, listbox, datagrid, tabs, menu, groupbox, scroll, image, style, buttonrow (OK/Cancel), statusbar, and contextmenu — with tab stops on the parts you'll want to rename.
• Hover documentation — hover any element or attribute for a plain-English description, its type, and the allowed values.
• Inline color swatches & picker — every Background, Foreground, BorderBrush, Fill, Stroke, … value shows a color chip right in the code; click it to open VS Code's native color picker. Picking a color writes the hex back (or the friendly name when one matches exactly).

Everything is scoped to .xaml files only and can be switched off with the uimaker.xamlIntelliSense setting.

🔨 Build, Run, Debug, Release buttons

Status-bar buttons (and editor-title shortcuts) drive the .NET CLI for you:

• Build — builds with errors reported in the Problems panel.
• Run — builds and launches your app; the button turns into a red Stop while it runs and flips back when the app exits.
• Debug — builds, then attaches the right .NET debugger (coreclr for modern .NET, clr for .NET Framework — uses the C# extension when installed; falls back to plain run otherwise).
• Release — publishes a Release build, then jumps you to the output folder. Settings under UI Maker › Publish turn this into a real installer-free distribution: Single File (one .exe), Self Contained (bundles the .NET runtime so the target PC needs nothing installed), and the target Runtime (win-x64 / win-x86 / win-arm64).
• Multi-target projects — Run, Debug, and Publish ask for the active target framework once and reuse it for the session; build/output discovery and the debugger all use that same TFM.

Builds are protected so they work on any dev machine: projects targeting .NET Framework without the reference assemblies installed (error MSB3644) get an offer to add the Microsoft.NETFramework.ReferenceAssemblies build helper, and classic non-SDK projects are built with Visual Studio's MSBuild (found via vswhere) since the dotnet CLI cannot load them. Apps whose manifest requests administrator rights are detected too — Run builds them and launches the exe through a UAC prompt instead of failing with "requires elevation".

🚀 Project scaffolding

UI Maker: New .NET Desktop Project asks for a template (WPF, Windows Forms, or Console), a language (C# or Visual Basic), a target framework, a name, and a folder — then generates a ready-to-run app and offers to open it.

🛠️ Project Properties page

Project Properties (side panel → Actions) is Visual Studio's Application tab inside VS Code: output type, target framework (offering the SDKs actually installed on your machine), assembly name, default namespace, startup object, application icon and manifest (with Browse… pickers), plus the package/assembly info (version, authors, product, description, copyright) for SDK-style projects. Changes are written straight into the .csproj — an existing property is updated in place, a cleared one is removed so the SDK default applies again.

Old-format projects get a Convert to SDK style button right on this page — see below.

📦 NuGet package manager

NuGet Packages (side panel → Actions) is the Manage NuGet Packages window: it opens on Browse, pre-filled with nuget.org's most popular packages, and searches as you type (with an include prerelease toggle). Installed lists the project's PackageReferences with one-click uninstall, and Updates checks every installed package against the latest stable release. Install/update/uninstall run dotnet add|remove package, so the project file and restore stay consistent.

🧩 Custom controls & Control Library

Your own C# / VB controls work in the designer like the built-in ones:

• Project Controls (automatic) — every class in the working project that derives from a control base (UserControl, Button, Panel, any WinForms control — including chains like FancyButton : RJButton : Button) and every WPF UserControl (.xaml with x:Class) appears in a Project Controls toolbox section. Drag one onto a form and the generated code uses the full type name (this.rjButton1 = new CustomControls.RJButton();), the field is declared with the right type, and the canvas renders the control with the look of its designer base. The section has a ↻ rescan button, and the list also refreshes whenever a designer tab regains focus.
• Custom Library (registered) — controls that live in a NuGet package or a referenced DLL (Guna.UI2, ReaLTaiizor, Krypton, …) can't be found by a source scan, so register them once in the Control Library panel (side panel → Actions): full type name, which base they look like, and a default size. They then show up in a Custom Library toolbox section for every form. Entries are stored in the uimaker.customControls workspace setting, so the whole team gets them via .vscode/settings.json.
• Forms that already use custom controls open fine: unknown types render as a neutral placeholder (or as their base's look once known), and moving, resizing, renaming, events, and deleting work like any other control.

⬆️ Convert classic projects to SDK style

Old .NET Framework projects use a project format modern tooling can't load — C# Dev Kit shows “The project file is in unsupported format”. UI Maker: Convert Project to SDK Style rewrites the .csproj as a minimal SDK-style project with the same target framework, names, icon, manifest, and build events; packages.config entries become PackageReferences; framework references become implicit; Settings.settings/Resources.resx keep their designers. The original file is kept as <name>.csproj.legacy.bak, so undoing the conversion is a two-file rename.

⚙️ App Settings editor

App Settings (side panel → Actions) is the Visual Studio Project Properties → Settings page, inside VS Code: a grid of settings your built app remembers — name, type (string/int/bool/double/long/DateTime), User or Application scope, and a default value. Saving writes the same Properties/Settings.settings + Settings.Designer.cs pair Visual Studio generates, so the project stays fully compatible with VS. In your app:

var name = Properties.Settings.Default.PlayerName;   // read
Properties.Settings.Default.PlayerName = "Ada";      // change (User scope)
Properties.Settings.Default.Save();                  // persist per user

📖 Built-in guide

New to .NET desktop apps? Guide — How to Build an App (side panel, the book icon, or the Command Palette) opens an illustrated walkthrough: the workflow from empty folder to shipped .exe, the full file tree of a WPF and a WinForms project, which files are required / optional / generated, and what every single file is for.

Getting started

1. Install the .NET SDK (8.0 or newer recommended).
2. Install UI Maker (from source, see below — Marketplace listing planned).
3. Run UI Maker: New .NET Desktop Project from the Command Palette (Ctrl+Shift+P), or open a folder that already contains a .csproj.
4. Click the UI Maker icon in the activity bar and pick a window under XAML Windows — or right-click a .xaml file → Open With… → UI Maker Designer (or click the designer icon in the editor title bar).
5. Drag controls from the toolbox, set properties, wire events.
6. Hit ▶ Run in the status bar.

Running from source

git clone <this repo>
cd uimaker
npm install
npm run compile

Before packaging or submitting a change, run the complete local gate:

npm run check

Open the folder in VS Code and press F5 — an Extension Development Host window launches with UI Maker loaded.

Commands

Settings

How it works

• The designer is a Custom Text Editor bound to *.xaml. It parses the XAML into a document model, renders an HTML approximation of each control on a canvas, and writes changes back as plain text — so the .xaml file stays the single source of truth and normal git diffs still work.
• Controls are positioned the same way Visual Studio's designer does it: HorizontalAlignment="Left" VerticalAlignment="Top" Margin="x,y,0,0" inside the root Grid (or Canvas.Left/Canvas.Top when the root panel is a Canvas).
• Build/Run/Release are thin, transparent wrappers over the dotnet CLI — nothing proprietary, no lock-in, and everything it runs is visible in the terminal.

A note on WPF vs. Windows Forms

Files like MainWindow.xaml belong to WPF (or WinUI), the markup-based way to build Windows desktop UIs. Windows Forms stores its layout in generated code (*.Designer.cs in C#, *.Designer.vb in Visual Basic) instead — and UI Maker designs all of them: open a .xaml window, a Form.Designer.cs, or a Form.Designer.vb file in the designer and get the same drag-and-drop canvas, properties panel, and event wiring. WinForms edits are surgical — only the affected this.control.Prop = …; / Me.Control.Prop = … statements change, so diffs stay clean, and generated code follows the file's own dialect (Me. vs this., qualified vs. implicit namespaces, VB literals like True and 9.75!).

Visual Basic events work the VB way: wiring an event writes a Private Sub … Handles Button1.Click into the code-behind (creating the stub if needed), the events panel reads existing Handles clauses live, and clearing an event removes just its Handles target — handler code is never deleted.

Known limitations

• Nested layouts (Grid rows/columns, StackPanel, DockPanel, TabControl, UniformGrid, Viewbox, ScrollViewer, …) render faithfully, and any element can be selected, dragged (Grid children position, flow-panel children reorder or re-parent), resized, and edited in the panels. Note that dragging a centered/stretched Grid child pins it to Left/Top + Margin (Blend's behavior) — its layout stops following window resizing until you restore the alignment in the Properties panel.
• Styles and brush resources resolve from the document and App.xaml (one level of merged dictionaries); a template's first Border CornerRadius is approximated. Triggers, bindings, and full ControlTemplate visuals are ignored in the preview.
• Images assigned in old projects as local form resources (resources.GetObject(...) with base64 in the form's .resx) render on the canvas when they are plain image bytes; BinaryFormatter-serialized ones cannot be previewed. Newly assigned images always use project resources.
• Strip Items editing covers one level — nested sub-menus and per-item icons/events still need the code view (roadmapped).
• Structural WinForms containers can be deleted safely, but deep Cut/Copy/Duplicate of containers, generated menu items, and grid columns is intentionally disabled until every nested object can be cloned losslessly.
• Without the C# language service, control rename falls back to the Designer.cs/code-behind pair; project-wide references then need a manual rename.
• Visual Basic parity is complete: the WinForms designer (*.Designer.vb round-tripping), Add Form/Window, Duplicate, New Class, Handles-based events, control rename, the App Settings editor (My.Settings), classic→SDK conversion, and image/resource import with My.Resources accessor generation.
• The classic-project converter deliberately stops before writing when it finds custom imports/targets, conditional target frameworks, framework profiles, or package install-script/content semantics it cannot migrate safely.
• Custom controls render with the look of their designer base (an RJButton : Button draws as a Button) — the canvas cannot execute your OnPaint code, so rounded corners and custom chrome only show at Run.
• Saving from the designer normalizes the XAML formatting (like most visual designers).
• The visual preview is an approximation — always confirm with Run.
• Windows-only targets (WPF/WinForms are Windows frameworks).

Roadmap

• [x] Windows Forms visual designer (*.Designer.cs round-tripping)
• [x] Nested layout rendering (StackPanel / DockPanel / Grid rows & columns / TabControl)
• [x] Visual Studio-style categorized property grid (Anchor/Dock, colors, fonts, full form properties)
• [x] Images & icons imported as project resources, with VS placement/scaling options
• [x] Control renaming that safely updates the code-behind
• [x] MenuStrip / ToolStrip / StatusStrip designers and a component tray (Timer, ToolTip, ContextMenuStrip, dialogs)
• [x] Multi-select, alignment & distribution tools, tab-order view, copy/paste across forms
• [x] Docked controls that push each other for space; TabControl and tab-page drops
• [x] Visual Basic WinForms designer (*.Designer.vb round-tripping, Handles-based events, VB scaffolding)
• [x] Remaining VB parity: App Settings editor, classic→SDK conversion, My.Resources image import
• [ ] Sub-menu (nested menu item) designing and item icons
• [x] Drag-reordering inside StackPanel / WrapPanel / DockPanel children, drag re-parenting between panels, group move, XAML align tools
• [x] "Modern (Styled)" toolbox section — ToggleSwitch, rounded buttons, cards, badges via injected styles
• [x] "Create an Installer" for multi-file releases (Inno Setup script generation)
• [x] Custom controls in the toolbox: automatic project scan + a Control Library for NuGet/DLL controls
• [ ] Style/resource editing and live theme preview
• [ ] Marketplace publishing and prebuilt VSIX releases

Beyond 1.0 — premium ideas (v2.0)

The long-term vision is a complete build-and-release studio, with a premium tier on top of the free core:

• Third-party UI library packs — design-time support for modern control suites like Guna UI, Telerik UI for WinForms, Krypton, and MaterialSkin: their controls in the toolbox, rendered previews, and the right NuGet references added automatically.
• Themed chrome presets — one-click looks such as Office-2007-style ribbons and menus, dark mode, and rounded "modern app" styling.
• One-click releasing — installer builds (Inno Setup), code signing, version bumping, and update feeds, from the same Release button.

Contributing

Issues and pull requests are welcome. The codebase is intentionally small and heavily commented — src/ holds the extension host code (TypeScript), media/ holds the designer webview (plain JS/CSS).

License

MIT — see the LICENSE file.