Vous souhaitez que les applications de contexte de coque aient de petites empreintes. Cela exclut le code managé au moins pour l'instant. Cela peut parler un peu en faveur de win32asm, bien que les bibliothèques C++ ne soient pas vraiment grandes par rapport à l'environnement d'exécution .NET (moins d'un Mo, tout compte fait, n'est pas si grand ces jours-ci)!
Vous souhaitez que les applications de contexte shell soient stables, sinon les utilisateurs les expulseront pour sauvegarder leurs processus explorer.exe. Cela parle fortement contre win32asm. Si vous savez seulement que vous aurez toujours l'application, et que vous avez de grandes compétences en assembleur, win32asm peut fonctionner, même si je ne le ferais pas moi-même. Vous devez encore implémenter des interfaces COM, ce qui est un mal de tête assez important sans ajouter les complexités du codage d'assemblage. J'aurais opté pour VC++ avec le support ATL, sans plus y penser, mais avec des tests unitaires sérieux et des sauvegardes contre les fuites de ressources. Mais si vous n'êtes pas à l'aise avec C++ et les gabarits, cela peut représenter une route difficile pour vous. Sur le plan positif, vous aurez un ensemble de code source beaucoup plus petit à maintenir, et vous aurez beaucoup plus de facilité à trouver d'autres personnes pour vous aider ou prendre le contrôle. Vous avez peut-être également amélioré un ensemble de compétences utiles et pertinentes.