I’m working on a .NET desktop application that we distribute through an MSI installer along with our web service. We’re getting requests from several clients who want to rebrand our software with their own company logos and information.
Basically I need to customize these elements for different partners:
- System tray icons
- Desktop shortcuts
- Start menu entries
- Icon descriptions and tooltips
- About dialog and support contact info
Right now I can modify the system tray icon and about screen using configuration files since those load at runtime. But the desktop shortcuts and start menu items get created during installation so they stay the same.
I really don’t want to maintain separate code branches for each partner (we might have 10+ resellers eventually). I’m looking for a solution where we can either customize during installation or update the branding after the software is already installed.
Our application needs to work on Windows 2000, XP, Vista, 7, and some embedded systems. Has anyone dealt with this kind of white label customization before? What’s the best approach?
We did something similar with resource-based customization plus post-install updates. Make separate resource assemblies for each partner - put their icons, strings, and branding stuff in there. The main app loads the right resources at runtime based on a partner ID from the config. For desktop shortcuts and start menu entries, build a small utility that runs after install to update everything. You can call it from your app’s first run or make it a separate post-install step. The utility reads the partner config and recreates shortcuts with the right icons and descriptions. This scales really well since you keep one codebase and just separate the partner assets into different resource files. We’ve used this for three years across multiple Windows versions - no problems.
I dealt with this exact issue at my last job. Used a hybrid approach that worked great.
Set up a branding manifest system - each partner gets their own folder with assets (icons, strings, images) and a manifest file describing placement. Keep your main installer generic but include all partner folders.
At install time, the MSI reads a partner code from command line or a config file next to the installer. Then copies the right assets to app directory and creates shortcuts with correct branding.
For runtime stuff like system tray and about dialogs, your app reads the same manifest to know which assets to load.
Here’s the game changer: use file system watchers in your main app. When someone drops new branding assets into the partner folder, your app detects it and automatically recreates desktop shortcuts and start menu entries with new branding. No restart required.
This scales way better than config files - you can zip up a partner’s branding folder and send it for customization. They test locally and send it back.
Ran perfectly on all those Windows versions you mentioned. File watcher approach is rock solid and users love rebranding without reinstalling.
been there! we fixed this by making the installer read branding configs from a separate xml file during setup. works perfectly - just swap out the xml without touching any code. for shortcuts, recreate them programmatically on first launch. takes 2 seconds and users don’t even notice.
We had the same issue and dynamic branding through installer parameters solved it perfectly. We tweaked our MSI to take command line properties for partner branding and packed all partner assets right into the installer. When it installs, the MSI picks the right icons and text based on whatever partner parameter you pass in. For shortcuts that already exist, we built a background service that watches for branding changes and updates existing shortcuts automatically - no user action needed. The trick was handling branding at install time instead of runtime for the static stuff. This way we didn’t need any post-install utilities and everything stays within the standard Windows installer framework. Performance hit is basically nothing since branding selection only runs once during install.