Mads Kristensen

Why I built Home Automation Cookbook, and how I keep it useful

test@example.com — Thu, 17 Sep 2026 22:34:22 GMT

Home Automation Cookbook collects practical patterns for making a home helpful without making it harder to use.

I have written about home automation on this blog for years. In 2019, I published a collection of home automation ideas that worked well for my family. The important part was never a particular hub, protocol, or brand. It was the logic behind each idea and whether it quietly made everyday life easier.

That original post kept growing in my head. A long list of ideas is useful for inspiration, but it is not a great format for explaining everything that makes an automation dependable: what triggers it, which conditions matter, how someone overrides it, and what happens when a sensor or service fails.

That is why I built Home Automation Cookbook. It gives each household job enough room to become a reusable recipe rather than a platform-specific trick.

The problem I wanted to solve

Most smart-home content begins with technology. It starts with a hub, a product, or a feature and then looks for something to do with it. I wanted to reverse that.

The Cookbook starts with an ordinary burden:

Remembering to move laundry after the washer finishes.
Checking whether the garage door was left open.
Adjusting the thermostat when a window is open.
Reaching for a light switch while carrying something through the house.

Only after the job is clear does the recipe discuss sensors, switches, platforms, or products. This makes the idea easier to adapt, and it prevents the site from becoming a catalog of gadgets looking for a purpose.

The other problem is that an automation can work perfectly for the person who created it and still be bad for everyone else. My family is the real QA team. Kids, guests, and anyone who did not configure the system should still be able to use the house without learning an app or remembering special rules.

A useful automation should remove work without removing control.

The wall switch is part of the design

One principle appears throughout the site: the physical control should keep working.

If motion turns on a light, the wall switch should still behave like a wall switch. If the hub is restarting, the internet is unavailable, or the automation made the wrong decision, nobody should be trapped behind the technology.

I learned this through normal household use. An automatic bathroom light that turns on a fraction too late can collide with muscle memory. Someone reaches for the switch just as the automation turns on the light, and their tap immediately turns it off again. The rule technically worked, but the experience did not.

The fix was not to explain the automation more carefully. It was to move the sensor and make the response fast enough that the room behaved naturally.

This is also why the site emphasizes local execution where a platform supports it. Cloud services and voice assistants can be useful extras, but basic household behavior should degrade gracefully when they are unavailable.

A recipe makes the decision path and the ordinary fallback explicit.

Recipes instead of walkthroughs

I have personally used Amazon Echo with Alexa, SmartThings, and Hubitat. Hubitat is what I use today. Those experiences inform the site, but the core recipes remain platform-neutral.

A typical recipe describes:

The trigger that begins the automation.
The conditions that must also be true.
The action the house should take.
Any wait or timeout.
The condition that stops or reverses it.
The manual override.
The likely failure modes.

That structure is deliberately close to plain English. A reader can understand the behavior before translating it into a Hubitat rule, a SmartThings routine, an Alexa routine, or another system.

Platform notes are supporting material rather than the recipe itself. I also distinguish between firsthand experience and technical fit. For example, I have not personally run Home Assistant, so the site does not present Home Assistant guidance as a hands-on walkthrough.

How the site is built

The implementation is intentionally simple. Home Automation Cookbook is a static Jekyll site made primarily from Markdown, HTML, CSS, JavaScript, YAML data, and shared layouts.

Visual Studio is my workshop

I built the site in Visual Studio. That may sound like an unusual choice for a Jekyll site, but it gives me one workspace for the entire project: Markdown recipes, Liquid layouts, YAML data, CSS, JavaScript, images, and Git history. I can make a site-wide change, review the diff, run the site locally, and push it without switching between a collection of specialized tools.

Visual Studio is not a requirement for contributing to the site, and it is not part of the production runtime. It is simply the workshop I prefer. Jekyll turns the source into static pages, and GitHub Actions deploys them to GitHub Pages after I push to the main branch.

The source is public in the Home Automation Cookbook GitHub repository. A push to the main branch runs a GitHub Actions workflow, builds the production site with Jekyll, and deploys the result to GitHub Pages.

Static generation is a good fit for this project. The pages are fast, the content is easy to review in a pull request, and the repository contains the history of how the guidance changes. There is no application server or database to maintain just to publish a recipe.

The site currently contains 49 automation recipes across lighting, climate, safety and security, appliances, notifications, entertainment, and daily routines. Shared Jekyll layouts keep those pages consistent, while structured category data powers the recipe directories and starting points.

The automation directory is organized around the reader's goal rather than the implementation. Instead of asking which integration someone uses, it asks whether they want to stop checking an appliance, move through the house more easily, reduce repeated adjustments, or coordinate a household transition.

Recipes begin with a household job, then describe the trigger, checks, and action without tying the idea to one platform.

Writing the failure before calling it finished

The happy path is usually the easy part of home automation. The more useful questions are:

What if the sensor stops reporting?
What if its last known state is stale?
What if someone manually changes the device?
What if a guest behaves differently from the person who built the rule?
What remains available when the hub or internet is down?

Every substantive recipe includes failure modes because a rule is not complete until the household knows how it fails. A notification should not claim success when the final state was never confirmed. An unavailable contact sensor should not silently remain "closed" forever. A manual change should not immediately be undone by an overconfident automation.

This way of writing also improves the automations in my own home. Explaining a rule exposes assumptions that are easy to miss while looking at a visual rule editor.

The site is a cookbook, not a blueprint

A recipe is a starting pattern. Every home has different rooms, routines, tolerances, devices, and people. The goal is not to copy my house. It is to understand why a pattern works, identify the signals it needs, and adapt it without losing the fallback behavior.

I recommend beginning with one small, reversible win. Motion lighting in a hallway or a washer-finished notification is easy to observe and easy to override. Run it for a week. Watch how people actually use it. Change one assumption at a time.

That loop is how the site grows too. I started the repository in November 2025, and it has evolved through hundreds of small revisions to its recipes, navigation, safety guidance, platform notes, and visual design. The work is less about declaring an automation complete and more about making each explanation clearer and more dependable.

What I hope the site becomes

I want Home Automation Cookbook to be useful to someone before they buy a device and after the novelty of that device is gone.

Before buying, it should help define the household job and the capabilities required to solve it. After installation, it should help test the rule, preserve manual control, recognize failure, and adjust the behavior as the household changes.

Most of all, I want the site to keep the technology in a supporting role. The lasting benefit is not that a home contains more smart devices. It is that there is less to remember, fewer repeated checks and adjustments, and more confidence that ordinary controls will still work.

You can browse the recipes at homeautomationcookbook.com, or inspect and contribute to the source on GitHub.

Solution Colors: Telling Visual Studio Windows Apart at a Glance

test@example.com — Thu, 10 Sep 2026 18:08:54 GMT

When several Visual Studio instances are open, identifying the right one becomes a surprisingly repetitive task. Two windows showing different checkouts of the same solution can look almost identical. Reading the title works, but a small visual cue is easier to spot.

That's the problem behind Solution Colors. Inspired by the Peacock extension for VS Code and a Visual Studio feature request, it associates a color with a solution or folder without replacing your editor theme.

Give each solution a visual identity

Right-click the solution in Solution Explorer, choose Set Solution Color, and select a color. The predefined choices use the familiar document-tab color palette, and Custom... opens a color picker when you want something different. Open Folder workspaces are supported too.

The color can appear around the window, behind the solution name in the title bar, and in taskbar thumbnails. Taskbar icon overlays are also available, with the documented limitation that taskbar items need to be ungrouped. You can choose the surfaces that help you and leave the others alone.

Under Tools > Options > Environment > Fonts and Colors > Solution Colors, you can adjust border placement and thickness or enable automatic color assignment. Automatic mode selects from the palette using a hash of the solution path; explicitly saved colors take precedence.

A small extension with two kinds of integration

The project is an in-process VSIX built with the Visual Studio SDK and the Community Toolkit. Its ToolkitPackage registers commands and listens for solution and folder open/close events. The menu lives in a VSCT command table, while the color commands share a generic BaseCommand<T> implementation.

That is the conventional part. Coloring the existing window chrome is less conventional.

The implementation searches the WPF visual tree for named shell elements such as BottomDockBorder and PART_SolutionNameTextBlock. It changes brushes and border thickness rather than introducing a new tool window. For the title label, it also uses reflection to access the foreground property and Visual Studio's ColorUtilities.CompareContrastWithBlackAndWhite to choose black or white text.

This is an important tradeoff for extension authors: finding an element in the shell's visual tree is not the same as having a dedicated, stable extensibility contract for it. Names and structure can change. The lookup code is worth isolating, and these integrations need testing against the Visual Studio versions you support.

Decoration must not get in the way

One revealing detail is hit testing. The extension disables hit testing on the non-top borders it colors so they don't intercept mouse input. But it deliberately leaves the top element alone: MainWindowTitleBar contains interactive UI, and disabling hit testing there would also block menu interaction.

That distinction is easy to overlook when the feature appears to be "just a border." Decorative changes still participate in layout and input routing.

Timing matters too. Package initialization does not guarantee that every shell element is ready. The startup path makes a bounded series of colorization attempts, with delays between them. UI changes switch to the main thread, while Git branch file reads are dispatched to a background task.

Taskbar integration uses a different mechanism: WPF's TaskbarItemInfo, noninteractive ThumbButtonInfo entries, and an overlay image. There is no need to reach into the taskbar's visual tree.

Branch colors are a state problem, not just a brush problem

The settings offer one color across branches, a separate color per branch, or a combined gradient. Assignments are stored as simple branch:color lines in a color.txt file, normally under the solution's .vs directory. An option puts the file in the root instead. The parser also accepts the older single-color format.

There is a compatibility detail worth knowing: the implementation uses the literal key master for its shared/base color. That is an internal convention, not automatic discovery of a repository's configured default branch.

A recent fix illustrates why separating decisions from rendering helps. In per-branch mode, a branch with an explicit color should remain colored even when no base color has been assigned. The code now expresses the removal decision in ShouldRemoveColorization, with focused unit tests covering the different modes and automatic-color behavior.

That is a useful pattern beyond this extension: put the state rules in a testable method, then let the UI code apply the result. You shouldn't need to launch an experimental Visual Studio instance just to verify whether a missing base setting overrides a branch-specific one.

Try it, or borrow the ideas

If you regularly juggle Visual Studio windows, install Solution Colors from the Marketplace and give your solutions a visual identity.

If you're building extensions, browse the source on GitHub. Start with SolutionColorsPackage for the lifecycle, ColorHelper for the shell integration, and the tests for the branch-color rules. A few pixels of color turn out to be a useful case study in extending the IDE without getting in the user's way.

Lore for Visual Studio: Source control without leaving the IDE

test@example.com — Fri, 28 Aug 2026 20:54:50 GMT

Lore is a new source control system from Epic Games. It is designed for fast, distributed workflows, with local repositories that work offline and optional Lore servers when you need to collaborate.

Lore for Visual Studio brings that workflow directly into the IDE. It is also a practical example of what it takes to add a new source-control provider to Visual Studio: integrate onboarding, status, changes, commits, history, branches, authentication, and native diff and merge experiences into the places developers already use.

The extension lets you onboard a solution or folder, see file status in Solution Explorer, review changes, commit, manage branches, inspect history, and synchronize with a Lore server - all without dropping to a terminal.

A source-control provider that feels native

Visual Studio already provides the integration points a source-control provider needs to participate in the everyday development workflow. Lore for Visual Studio uses them to surface repository status in Solution Explorer, provide commands in solution and file context menus, and offer dedicated Changes and History tool windows. Rather than making developers learn a separate workflow, the extension makes Lore available alongside the IDE experiences they already know.

Start with a local repository

Open a solution or folder and select Add to Source Control in the Visual Studio status bar. Choose Lore, then create a local repository.

Local repositories are fully offline. You can commit, create branches, switch branches, and browse history while all content remains on your machine. When you are ready to collaborate, create or connect to a Lore server and push your work.

You can also clone an existing Lore repository directly from Solution Explorer. The extension checks that the server is reachable, clones the working tree, and records the remote configuration so push and pull are ready immediately.

Source-control status where you expect it

Once a solution is under Lore source control, status glyphs appear beside files in Solution Explorer. They refresh automatically as documents are saved, and the Lore Changes window provides a manual refresh command whenever you need one.

File context menus include the essentials:

Undo Changes to restore the committed version
Compare with Unmodified to view a native Visual Studio diff
Ignore and Untrack Item to add a file to .loreignore

Moves and renames performed in Solution Explorer are tracked automatically. The extension also uses Visual Studio's shared file-change service to detect changes made outside the IDE.

Review and commit changes

The Lore Changes window provides a dedicated commit experience modeled after Visual Studio's Git Changes window.

It presents changed files in a repository-root folder tree, including status badges for modified, added, deleted, renamed, and copied files.

You can select exactly which files belong in the next commit. Folder checkboxes are tri-state, the header checkbox selects everything at once, and your selection survives automatic refreshes while you write a commit message.

From the window, you can:

Commit selected files or commit and push in one operation
Amend the latest revision
Open native Visual Studio diffs for individual files
Discard a file's changes
Pull, push, and refresh from the toolbar

Browse history without touching the working tree

The Lore History tool window shows a read-only log for the repository associated with the open solution or folder.

History is paged, newest first, so even repositories with thousands of revisions remain responsive. Each revision shows its message, short hash, author, and local commit time. Select a revision to load only the files that it changed, then double-click a file to compare it with its direct parent in Visual Studio's native diff viewer.

The window stays in sync with the workspace and refreshes automatically after relevant Lore operations, such as commits, pulls, branch changes, and merges.

Branching and merging

The branch picker in the Lore Changes window lets you switch branches, create a branch from the current revision, and merge another branch into the one you are working on.

Lore is offline-first. When the needed content is already cached locally, switching and merging do not require a network round trip. If content has been evicted from the local cache, Lore fetches it from the configured server and clearly reports when the server is unavailable.

When a merge conflicts, Visual Studio's built-in three-way merge experience opens for each conflicted file. Resolve the conflicts, accept the results, and Lore completes the merge commit.

Sign in only when it matters

There is no separate sign-in command. If a server-backed operation such as cloning, pushing, or pulling requires authentication, Lore asks whether to sign in and opens the default browser. After sign-in completes, the original operation is retried.

That keeps the experience simple: work locally when you can, authenticate only when a server operation actually needs it.

Try it out

Lore for Visual Studio is available from the Visual Studio Marketplace.

The extension is open source, and contributions are welcome on GitHub. If you are building a source-control integration of your own, the project is also an example of how a provider can fit into Visual Studio's existing source-control workflow.

Building Max Line Length: Making EditorConfig Formatting Visible in Visual Studio

test@example.com — Wed, 19 Aug 2026 16:05:17 GMT

Line length is one of those conventions that teams agree on easily and enforce inconsistently. EditorConfig gives us a shared vocabulary with max_line_length, but Visual Studio does not natively draw a boundary for it or apply it during formatting.

That gap is what inspired Max Line Length. The extension makes the effective EditorConfig value visible in the editor and adds a carefully constrained reflow pipeline for formatting and Code Cleanup.

Starting with the effective EditorConfig value

The extension does not introduce a second configuration system. A repository can declare its convention as usual:

[*.{cs,vb}]
max_line_length = 120

For each text view, Max Line Length resolves the effective value for the document, including nested configuration files and matching sections. If the value is missing, invalid, or set to unset, the ruler is removed.

The interesting part is keeping the editor responsive when configuration changes. The adornment listens for refresh notifications, resolves file-based settings away from the UI thread, then switches back to the main thread before updating the view. A version counter prevents stale asynchronous results from replacing newer configuration values.

Drawing a ruler without interfering with editing

The ruler is implemented as a Visual Studio editor adornment. The extension obtains an IWpfTextView, creates an IAdornmentLayer, and owns a WPF Line element. Its horizontal position is calculated from the formatted line source, indentation, column width, and the resolved maximum length.

The adornment follows layout changes, so it tracks scrolling, zoom, font changes, and viewport updates. It is not hit-testable and does not intercept mouse or keyboard input. The extension also checks for Visual Studio's diff view role and does not display the ruler there.

Color customization uses Visual Studio's format map rather than a private option. The Max Line Length ruler format is exposed through Fonts and Colors, and the adornment reads the configured foreground brush when it redraws.

One reflow service for several editor commands

Formatting support began as command-specific logic, but that quickly creates inconsistencies. The extension now centralizes the decision in DocumentReflowService. It determines whether a content type can be reflowed, selects the appropriate engine, and applies the resulting text changes.

Visual Studio's MEF composition supplies the classifier service used for comment-aware languages. For C# and Visual Basic, the extension uses language-specific reflow engines for lists and expressions. For classified-comment content types such as JavaScript, TypeScript, C++, CSS, LESS, SCSS, and SQL, it asks the editor classifier for comment spans and limits changes to those spans.

Markdown and plain text use separate engines so that structural constructs remain intact. Markdown headings, tables, lists, block quotes, code fences, inline code, HTML, front matter, and hard line breaks are protected instead of being treated as ordinary prose.

Being conservative is a feature

Reflow changes source text, so the extension intentionally avoids transformations that could alter meaning. C# and Visual Basic string and character literals are left alone. Structured XML documentation elements, examples, lists, and preformatted content are preserved while ordinary documentation prose can be wrapped.

Formatter suppression markers provide an explicit escape hatch. The extension recognizes @formatter:off and @formatter:on in the relevant comment syntax and excludes the protected region from reflow.

Selection formatting is similarly constrained. It operates on complete selected lines or complete C# and Visual Basic syntax constructs rather than making partial edits that could produce surprising results.

Adding Code Cleanup without changing existing profiles

The Code Cleanup integration is opt-in. The fixer is exported through Visual Studio's ICodeCleanUpFixerProvider and exposes a localized fix ID named Reflow lines to configured maximum length.

When enabled in a cleanup profile, the fixer obtains the document path, resolves the same ReflowOptions used by the formatting commands, and sends the buffer through DocumentReflowService. This keeps document cleanup and manual formatting consistent.

The fixer is disabled unless the user explicitly adds it to a profile. That default matters: installing an extension should not silently change existing cleanup behavior. The integration supports document cleanup and cleanup on save, while project and solution cleanup are not intercepted.

Lessons for other Visual Studio extensions

Use the editor's effective configuration instead of creating a parallel options system.
Keep UI adornments lightweight and recalculate them from the current formatted line source.
Centralize behavior shared by commands, cleanup, and future entry points.
Use classifications and syntax-aware boundaries to avoid editing executable code accidentally.
Make automated cleanup opt-in when it can change source text.
Design asynchronous refresh paths so stale results cannot overwrite newer state.

Try it or inspect the implementation

Install Max Line Length from the Visual Studio Marketplace, or download the latest CI build from the Open VSIX Gallery.

The complete source is available on GitHub. The project is a useful example of combining editor adornments, EditorConfig resolution, MEF services, content classifiers, language-aware text transformations, and Code Cleanup integration in a focused Visual Studio extension.

Building Bookmark Studio: bookmarks that belong to the codebase

test@example.com — Tue, 11 Aug 2026 01:54:47 GMT

Visual Studio bookmarks are useful for marking a line and returning to it later. The problem is that a line number alone does not say why the location matters, how it relates to other locations, or whether the rest of the team should know about it.

Bookmark Studio treats a bookmark as a small piece of project knowledge. A bookmark can have a name, note, color, folder, and one of nine direct-navigation shortcuts. It can stay private in the .vs folder, live at the workspace level in source control, or be global across solutions.

That sounds like a straightforward feature, but it touches several distinct parts of Visual Studio extensibility: editor tags and glyphs, text-buffer tracking, commands, a searchable tool window, options, solution lifecycle events, and persistent storage. The interesting part is making those pieces behave like one feature rather than a collection of extension points.

Keep the editor layer fast

The visible bookmark in the editor margin starts with a MEF-exported IViewTaggerProvider. It creates an ITagger<BookmarkGlyphTag> for primary text document views, while an IGlyphFactory turns each tag into the colored square shown in the glyph margin. If a bookmark has a shortcut from 1 through 9, the number is drawn inside the glyph.

The tag also carries the bookmark label, note, color, and shortcut number. That gives the glyph factory enough information to build a useful tooltip and context menu without reading the bookmark file. A second tagger produces OverviewMarkTag instances so the same bookmarks appear as colored markers in the editor scrollbar.

A useful rule for editor extensions is to keep GetTags cheap. Visual Studio can ask for tags often, including while scrolling and editing. Bookmark Studio does not load JSON or filter the complete bookmark collection on every request. The shared session owns the current bookmark state, and each tagger caches only the bookmarks for its document. When the session reports a change, the tagger replaces that small cache and raises TagsChanged.

That separation is broadly useful: do I/O and normalization in a service, then give the editor a read-optimized snapshot.

A persisted line number is not an editor position

A bookmark must be serializable, so its stored location includes a document path and line number. An open text buffer is more dynamic. Insert three lines above a bookmark and the persisted number is immediately stale.

Bookmark Studio handles that mismatch with ITrackingPoint. While a document is open, each bookmark gets a tracking point anchored inside the line content. The editor moves that point as the buffer changes, which keeps the glyph attached to the intended code instead of the original numeric line. The tagger can still fall back to the stored line number when no tracking point exists.

There is an additional wrinkle: users can explicitly drag a glyph to another line. The tagger therefore distinguishes an editor-tracked move from an explicit bookmark move before deciding whether to preserve or rebuild the tracking point. The custom MouseProcessorBase implementation calculates the target editor line, displays a drop indicator, updates the bookmark, and refreshes the manager if it is open.

The lesson is that storage coordinates and live editor coordinates are different concepts. Persist a stable representation, but use the text model's tracking primitives while a buffer is active.

Reuse Visual Studio instead of recreating it

The Bookmark Manager is a WPF control hosted in a BaseToolWindow. Its surrounding experience comes from Visual Studio rather than custom imitations.

The package registers the window with ProvideToolWindow, docks it alongside Solution Explorer, and assigns a toolbar declared through VSCT to ToolWindowPane.ToolBar. Search uses the tool window's native search box by enabling SearchEnabled and implementing IVsSearchTask. Commands and keyboard bindings are also declared through VSCT, including direct navigation with Alt+Shift+1 through Alt+Shift+9.

This approach matters for more than appearance. Native command placement participates in Visual Studio's command routing, toolbar customization, keyboard system, and accessibility behavior. The same principle applies to the search box: using the host's search contract gives the tool window familiar behavior without building another search control.

Bookmark Studio also offers an opt-in bridge from Visual Studio's built-in bookmark gestures. VS.Commands.InterceptAsync handles commands such as toggle, next, previous, and clear-in-document. The first toggle can prompt the user, and the setting determines whether later commands stop in Bookmark Studio or continue to Visual Studio's native implementation. The extension adds its own direct gestures as well, so interception is a choice rather than a requirement.

Make sharing explicit in the storage model

Bookmarks are stored with System.Text.Json in .bookmarks.json. The file is a folder tree containing bookmark IDs, relative document paths, line numbers, labels, notes, colors, shortcut slots, and manual sort indexes.

There are three storage scopes:

Personal bookmarks live under the solution's .vs folder.
Workspace bookmarks live beside the solution or at the Git repository root and can be committed.
Global bookmarks live in %USERPROFILE%\.bookmarks.json and use absolute paths because they are machine-specific.

Workspace discovery walks upward from the solution directory and reuses the first bookmarks file it finds. This is important for repositories where the solution sits below the root. New workspace files record "documentPathRoot": "bookmarksFile", which tells the loader to resolve relative document paths from the bookmarks file itself. Existing files without that marker retain the older solution-relative behavior.

That small format marker avoids a common portability bug. A relative path is only meaningful when both writer and reader agree on its base directory. If a team-shared file may move higher in a repository, the base must travel with the format or be defined by it.

Naming can use the editor's understanding of code

When name prompting is enabled, Bookmark Studio does not have to settle for the current line as the label. A MEF service queries Visual Studio's classification system and ranks identifiers such as methods, properties, fields, and types. It supports view classifiers first, then projection buffers and tag aggregators as fallbacks.

The complete fallback order is pragmatic: selected text, classified identifier, word under the caret, file name, trimmed line text, and finally Bookmark. Duplicate labels receive a numeric suffix.

This is a good middle ground for editor tooling. The extension gets language-aware suggestions from classifications that Visual Studio already produces, without taking a dependency on a specific language compiler or syntax tree.

The extension points form one state machine

The package loads in the background for solutions, Open Folder workspaces, and the no-solution context because global bookmarks remain useful without a solution. Solution and folder events invalidate the cached path and refresh the shared session. Editor taggers, commands, and the tool window all observe or update that same session.

That shared state is the architectural center of Bookmark Studio. The editor should not own persistence, the tool window should not be the only source of truth, and commands should not need to know where JSON lives. Each surface delegates bookmark operations to services, then reacts to the resulting state change.

For extension authors, the reusable ideas are straightforward:

Keep taggers read-only and inexpensive.
Use tracking points for live buffers instead of treating line numbers as stable positions.
Prefer native tool window search, VSCT commands, and host chrome over look-alike WPF controls.
Define the base of relative paths as part of a shareable file format.
Put cross-surface state behind a service so commands, editors, and tool windows stay synchronized.

Bookmark Studio is available on the Visual Studio Marketplace. The complete source, including the editor providers, tool window, command table, storage format, and tests, is on GitHub.

Building CodeShot: turning Visual Studio editor state into a shareable PNG

test@example.com — Fri, 07 Aug 2026 19:07:37 GMT

Turning a code sample into an image sounds simple until the image needs to look like the code inside Visual Studio.

Copying text into a design tool loses editor colors and formatting. Taking a normal screen capture includes tabs, margins, toolbars, and whatever else happens to be visible. It also leaves no convenient way to emphasize an expression or cover a value before sharing the image.

CodeShot addresses that workflow inside Visual Studio. It takes inspiration from CodeSnap, but its implementation is shaped by the Visual Studio editor and shell.

Select code, open CodeShot, adjust the result, and copy or save the PNG without leaving Visual Studio.

Rebuilding the editor instead of photographing it

The basic workflow starts with an editor selection. CodeShot opens a tool window, creates a preview using the current syntax colors, and immediately copies the initial image. The preview can add line numbers, a title bar, backgrounds, padding, shadows, and a configurable export scale.

The important implementation detail is that the editor screenshot is not a bitmap of the editor. CodeShot reconstructs the selected text as WPF content.

It obtains the active IVsTextView through IVsTextManager, converts it to an IWpfTextView with IVsEditorAdaptersFactoryService, and reads the selected SnapshotSpan values. Common indentation can then be removed without changing the underlying document.

Syntax colors come from two MEF services:

IViewClassifierAggregatorService supplies the classification spans.
IClassificationFormatMapService maps each classification type to the colors currently used by the editor.

Rather than asking the classifier about every line, CodeShot classifies the enclosing selection once. It then walks the ordered spans and slices them into WPF Run elements for each selected line. Unclassified gaps use the editor's default foreground, while classifications can contribute their own foreground and background brushes.

This approach has two useful properties. The result follows the active Visual Studio color settings, and the capture surface can be laid out independently of the editor viewport. Long selections are not clipped just because the tool window is small.

The preview is reconstructed from editor text and classifications rather than cropped from the screen.

Rendering at an explicit scale

The completed WPF surface is rendered through a VisualBrush into a RenderTargetBitmap. Export scale is explicit instead of being derived from monitor DPI. That makes the same selection produce the same pixel dimensions on different displays.

There are practical limits around this step. CodeShot rejects dimensions above 16,384 pixels and caps the total pixel count before allocating the render target. The resulting BitmapSource is frozen before it crosses thread boundaries.

The clipboard also needs more care than a call to Clipboard.SetImage. Some paste targets discard alpha from the normal WPF bitmap format, so CodeShot places both the compatibility bitmap and an encoded PNG on the clipboard. The clipboard data is copied rather than referenced, allowing the image to remain available after Visual Studio closes.

There is an optional plain-text clipboard representation too. That keeps code searchable when an application prefers text over images. If the screenshot contains a redaction, CodeShot deliberately omits the original text so the clipboard cannot reveal what the PNG hides.

Annotations are part of the capture surface

Annotations are ordinary WPF elements layered over the preview. Rectangles, arrows, expression highlights, text notes, and opaque redactions share a controller responsible for drawing, selection, moving, resizing, and erasing.

Crop operations and annotations use the same bounded edit-history model. This keeps undo and redo predictable while preventing an editing session from retaining an unlimited number of image and geometry states.

Annotations are rendered into the exported image, with redactions also changing clipboard behavior.

Capturing a tool window is a different problem

Text reconstruction works well for editor selections, but it cannot capture Error List, Test Explorer, Solution Explorer, or a tool window containing Win32 or WebView content. Those surfaces have to be captured from the pixels currently displayed.

CodeShot adds a command to Visual Studio's docked-window context menu through VSCT. When invoked, it uses IVsMonitorSelection to find the current IVsWindowFrame and IVsWindowFrame4.GetWindowScreenRect to obtain its screen coordinates.

The command is attached to Visual Studio's native docked-window context menu.

Finding the content rectangle is only the beginning. A docked group may contain sibling tabs, rounded shell chrome, transparent corners, and content rendered outside the WPF visual tree.

CodeShot combines several mechanisms:

UI Automation locates the selected tab and its docking container.
The WPF visual tree supplies a mask for the rounded Visual Studio frame.
Graphics.CopyFromScreen captures the actual visible pixels, including Win32 and WebView content.
The mask removes sibling tabs and leaves pixels outside the rounded frame transparent.

Because UI Automation runs away from the UI thread, the target can change while its geometry is being inspected. Before copying pixels, CodeShot verifies that the selected COM frame, bounds, root window, and visibility still match the original target. Captures are serialized with a SemaphoreSlim so two commands cannot race over transient shell state.

This design has an honest constraint: pixel capture can only reproduce what is visible. The target must remain unobscured. That tradeoff is preferable to pretending every Visual Studio surface can be rendered reliably through WPF.

Menus and modal dialogs complicate threading

Menus, context menus, cascading flyouts, and modal dialogs are even more temporary. CodeShot starts a five-second countdown so the user can open the desired surface, then performs discovery and capture off the Visual Studio UI thread.

That last part matters for modal dialogs. A modal WPF or Windows Forms dialog owns the UI thread while it is open. Resuming the delayed operation on that thread would postpone capture until the dialog had already closed.

The capture code examines the foreground window and the window under the pointer. UI Automation identifies visible menu items and expanded flyouts, while Win32 window enumeration finds native #32768 menu windows. DWM extended frame bounds are preferred when available so shadows and invisible borders do not become part of the result.

Let Visual Studio own the command experience

The tool window itself uses BaseToolWindow from the Community Visual Studio Toolkit, but its toolbar, menus, context-menu command, icons, and keyboard bindings are declared through VSCT.

The tool window's persistence GUID also acts as a command scope. Combined with ProvideKeyBindingTable, this allows familiar shortcuts such as Ctrl+C, Ctrl+S, Ctrl+Z, and Ctrl+Y to operate inside CodeShot without replacing their global Visual Studio behavior.

That is a broadly useful extension pattern: when a feature belongs to Visual Studio chrome, use Visual Studio commands and command scopes instead of recreating the experience with WPF buttons and global key handlers.

Small boundaries make the extension easier to maintain

The first version concentrated substantial behavior in the tool-window control. As the capture modes grew, reusable pieces were extracted for selection normalization, PNG encoding, file naming, atomic saving, font discovery, capture sizing, and bounded history.

Those boundaries also made the non-Visual Studio portions testable with ordinary MSTest tests. Visual Studio integration remains in the package and capture layers, while geometry, naming, indentation, and state transitions can be exercised without launching an experimental instance.

The main lesson from CodeShot is that image encoding is the easy part. A Visual Studio extension like this lives at the boundaries between editor snapshots, MEF services, WPF layout, COM frames, UI Automation, Win32 windows, the clipboard, and the shell's threading rules. Treating each boundary explicitly makes the workflow feel simple even when the implementation is not.

You can install CodeShot from the Visual Studio Marketplace or inspect the complete implementation in the GitHub repository.

Schemastore.org: The journey of a quiet revolution

test@example.com — Mon, 09 Dec 2024 21:41:37 GMT

Let me take you back to a moment that might feel familiar: you’re staring at a JSON configuration file, wrestling with field names and structure, hoping you’ve gotten it right. Your IDE is offering no help, and documentation is scattered or nonexistent. Frustrating, right?

Years ago, I found myself in that exact spot one too many times. As I sat there, tweaking and testing, it hit me: there had to be a better way. Little did I know that moment of frustration would spark an idea that would evolve into what you know today as Schemastore.org.

The Problem

Back then, JSON schemas weren’t the ubiquitous helpers they are now. Sure, the technology existed, but it wasn’t easy to find schemas for the tools you were using. If you needed a schema for your project, you either had to dig through obscure documentation or—more often—roll up your sleeves and build it yourself.

It was a time sink. And worse, it was entirely avoidable.

The real problem wasn’t the complexity of schemas; it was the lack of a centralized place to find them. Developers were solving the same problems over and over, each in isolation, when a shared resource could have made all the difference.

The Turning Point

So, I decided to create that shared resource. The idea was simple: a public repository where anyone could find and contribute JSON schemas. It wouldn’t be fancy—just a straightforward way to save developers from hours of unnecessary frustration.

When I launched Schemastore.org, I didn’t have big expectations. I thought it might help a few people, but I never imagined how quickly it would resonate with the development community.

The Rise of a Community

What happened next was extraordinary. Developers from all over the world began contributing. They sent pull requests for schemas I’d never heard of fixed errors I hadn’t spotted, and offered suggestions that made the site better in ways I couldn’t have predicted.

It wasn’t just about the schemas anymore; it was about the community.

Over the years, Schemastore.org has grown into a critical resource, quietly powering tools like Visual Studio Code, GitHub Actions, IntelliJ IDEA, and many others. The stats are humbling: over 1500 contributors, 4000 pull requests, 1000 schema files, and millions of developers who’ve benefited from the work.

That results in 2 TB of schema files being served to IDEs, validators, and other system every single day to support JSON, YAML, and TOML files.

But the real story isn’t in the numbers. It’s in the ethos: a shared belief that open collaboration can solve even the most frustrating problems.

The Challenges Today

Of course, growth comes with challenges. Keeping Schemastore.org running smoothly requires time, effort, and resources. While it’s still volunteer-driven, the infrastructure and maintenance costs have grown alongside its popularity.

And here’s the thing: for-profit organizations are among the biggest beneficiaries of Schemastore.org. They use the schemas to validate configurations, streamline workflows, and, ultimately, save time and money.

The Ask

If you’re part of such an organization—whether you’re contributing schemas or relying on them—I have a request: consider sponsoring Schemastore.org.

Your support would help cover hosting, maintenance, and development costs, ensuring this resource remains free and open for the entire community. It’s a small way to give back to something that likely saves you (and your team) time and effort every day.

You can find sponsorship details on the site, or feel free to reach out to me directly.

The Resolution

Looking back, it’s amazing to see how far Schemastore.org has come. What started as a small project has grown into something much bigger – a shared resource, built by and for the community, quietly making life easier for developers everywhere.

This journey isn’t over. With your help, we can keep Schemastore.org thriving, growing, and helping developers for years to come.

Thank you for being part of this story, whether as a user, a contributor, or someone who simply appreciates the effort.

Here’s to solving problems – one schema at a time.

Receive a notification when the dishwasher finishes

test@example.com — Wed, 18 Mar 2020 20:25:05 GMT

At our house, we use home automation for a lot of different things. One of them is the ability to get a quick overview of the state of our appliances such as the washer, dryer and dishwasher. That way we don’t accidentally forget to turn over the laundry or empty the dishwasher.

A red tile on our dashboard means something is ready for us to take action on – in this case that would be emptying the dishwasher after it finishes. See earlier blog post on how I built the dashboard below.

There are lots of tutorials on how to hook a “dumb” washer and dryer up to any home automation system, but I haven’t found any for the dishwasher that doesn’t involve figuring out how to hook up a power meter to it.

So, after a bit of trial and error I was able to do a highly accurate reporting mechanism using only a $20 multipurpose sensor that I had lying around.

The sensor

You need one or more sensors capable of sensing tilt, acceleration and temperature. I used the $20 Samsung Multipurpose sensor which integrates seamlessly into my SmartThings home automation system.

Attach the sensor along the side of the dishwasher at a place where it doesn’t get in the way. My wife didn’t notice the sensor until I asked her to look several days later.

The key is that the sensor needs to be located such that it can measure the raise in temperature from inside the dishwasher as it runs through its heated drying cycle. For your dishwasher, it might be higher up or even underneath.

Then go into the configuration of the sensor and specify it to be used on a garage door.

All that does is to use the tilt sensor to determine if it’s open or closed instead of the magnet. That way, you must open the dishwasher door all the way down to horizontal level before it registers as open. That’s what we want.

The automation logic

I’ve created a virtual switch called Dishwasher that I use to store the state of the dishwasher cycles which is what I use for the dashboard. It’s turned on when the dishwasher finishes and turned back off once it’s emptied.

It uses the fact that a bit of vibration occurs early on in the cycle, and temperature rapidly dropping after it finishes. The name of the multipurpose sensor is Dishwasher Sensor. Here’s the logic:

Notice how it uses the variable isRunning to keep track on when the dishwasher is running.

That’s it. Pretty simple, but it may require a bit of trial and error on where to place the sensor on the dishwasher door.

Hiding electronics behind fake books

test@example.com — Sat, 01 Feb 2020 23:42:17 GMT

After showing some pictures of our smart home dashboard, questions started coming in about the cables going in behind the books. Where is the modem and what else is going on? Spoiler alert, the books are fake.

Here you see a couple of cables going in behind the books on the top shelve.

Removing the books reveal a tangled mess of cords, power bricks, a modem, and a home automation hub.

The fake books are hollow and can hold quite the amount of stuff, as you can see below. Looking at the books from above shows just how simple they’re built.

This is easy to make yourself if you can find some decorative books you like. You can also buy it (Covobox on Amazon) and customize the size (width) and the colors of the books. For reference, we got the 14 inch one and that is probably the smallest I would recommend.

We’ve had this for a couple of years, and it holds up great.

The dashboard for our smart home

test@example.com — Thu, 30 Jan 2020 18:18:23 GMT

I’ve had some questions lately about how we keep track of all the home automation devices spread across the house. So, I thought I’d share how our dashboard is set up. The dashboard is the web-based SharpTools that runs in Fully Kiosk Browser on an Amazon Fire Tablet HD 10 which is magnetically attached to the wall.

Since it hangs so close to shelving, the charging cable is nicely hidden, so we didn't need to install additional electrical outlets behind the tablet.

Though the tiles looked blue above due to lighting and old phone camera, all tiles are actually gray, and red is used for the ones that need our attention when certain events occur - like when the washer is done and we need to move the clothes to the dryer. This helps keep the visual noise to a minimum and the red is really easy to see from across the room.

The bottom row is half way below the fold and we utilize this for both navigation to other dashboard (the left 3 bottom tiles) and some infrequent commands. The calendar is well suited for being cut off since it easily scrolls to reveal future calendar entries without scrolling the whole screen.

The first sub-dashboard is for the lights around the house. We use orange as a neutral color instead of green/red or similar. That's because it is neither good nor bad if a light is on or off. So orange in this case just means that something is active or on.

The second sub-dashboard tell us the status of more security related information. It tells us what external doors and windows are open, if the door is locked, the cameras armed and who's home.

It also has a link to a sub-sub-dashboard for showing battery status of our various devices. This uses the Battery Tile and will change color as the battery levels get below 30% and again below 10%. None of my devices are low on battery - thanks to this dashboard.

The third sub-dashboard is temperature and weather information from around the house.

That’s it. I tried to keep it simple, but still containing all the information I need. What do you think?