Question

Nous avons récemment rencontré des problèmes d'enfer avec les .dll pour nos clients, donc je me demandais si les installations SxS des .dll et .ocx requis étaient une bonne idée.J'ai lu des articles à ce sujet et j'ai réussi à déployer notre application alors qu'au moins certaines de ses dépendances étaient prises en charge via un manifeste, mais est-ce toujours la méthode de déploiement recommandée, ou est-ce une mode de ces dernières années et maintenant progressivement abandonnée ?

Était-ce utile?

La solution

Je ne vois pas pourquoi ce serait une mode.Le problème dans VB6 est qu'il n'y a jamais eu de mise à jour des outils pour le prendre en charge directement, bien que VB6 SP6 ait amélioré la prise en charge et que XP SP2 ait fourni une implémentation plus complète.

Nous l'utilisons tout le temps ici, même si nous avons constaté que certains contrôles tiers ne sont pas correctement écrits et ne peuvent pas fonctionner avec.De nombreux éléments de vbAccelerator semblent être "cassés" de cette manière, par exemple.

C'est un cas rare où nous ne le faites pas déployez en utilisant COM sans enregistrement maintenant, même si nous enveloppons le tout dans un package MSI.Être isolé des mauvais installateurs d'autres produits (la source de beaucoup d'enfers de DLL) est un gros plus, et Windows parvient à mieux se défendre en termes de composants système, ce qui aide un parcelle en soi.

L’astuce consiste à trouver un bon support pour les outils.Je n'ai jamais eu la patience de travailler sur l'application du support sommaire de Microsoft via les outils SDK, mais je pense que d'autres l'ont fait.Il existe au moins un produit commercial pour ce genre de chose.Nous utilisons nos propres outils développés en interne.

Mode?Nous le considérons avantage compétitif.Cela facilite également la production de logiciels portables en VB6 !Contrairement à certaines boîtes à outils de chargement et de piratage de bibliothèques d'exécution que nous avons vues d'une source allemande, vous n'avez pas non plus besoin d'ajouter beaucoup de codage fastidieux à vos programmes.Tout simplement, les vieux programmes VB6 fonctionnent bien.

L'autre chose qu'il permet est le déploiement par utilisateur, ce qui facilite la création de packages MSI qui s'installent pour un utilisateur sans droits d'élévation.Notre objectif principal n'est pas de produire des logiciels furtifs, mais les clients sont parfois confrontés à de hauts murs au sein de leur organisation, ce qui leur permet d'installer les produits que nous proposons et de poursuivre leur travail.Étant donné que nous ne touchons pas au registre ou aux zones protégées du système de fichiers, les commentaires négatifs des types d'administrateurs ont été presque nuls.Windows 7 a amélioré ceci :

Création d'un package unique pour le contexte d'installation par utilisateur ou par machine dans Windows 7

La même technique fonctionne sur Vista mais vous n'obtenez pas paquet unique Fonctionnalité.Construire les applications isolées rend le processus encore plus facile.

Bien sûr, SxS signifie bien plus que COM et l'isolation sans enregistrement, mais en termes VB6, c'est probablement ce dont vous parliez.DotNet l'utilise, le système d'exploitation l'utilise.Je ne sais pas pourquoi cela pourrait sembler une "mode". Peut-être que beaucoup de gens sont devenus silencieux sur le sujet grâce à la frustration des outils, un passage de VB6 à autre chose, ou parce que l'économie est très compétitive en ce moment.

Autres conseils

J'ai expérimenté SxS dans le passé, mais j'ai arrêté de l'utiliser après avoir rencontré des problèmes sur un certain pourcentage de machines Windows XP sur lesquelles l'application était censée s'exécuter.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top