Version imprimable
Salut à tous, et bienvenue sur mon 1er post!
je viens de finir de développer un petit logiciel en vb.net.
Le soft à était développer avec visual studio 2008 sur vista, de plus il fonctionne parfaitement sur Win7 (sur lequel se trouve aussi visual 2008), mais il ne fonctionne apparemment pas sur winXP.
Est-ce que installer le framework 2.0 sur un poste avec winXP sera suffisant pour y faire tourner l'application?
Merci
Bien que tu puisse choisir le framework cible, par défaut sous VB2008 les logiciels sont développés pour le framework 3.5
Si tu n'as rien préciser pour ton projet, c'est probablement donc le framework 3.5 qu'il faut que tu installe.
Merci pour ta réponse sevyc64, suite à celle ci je suis allé fouiller du coté de la config de mon projet sous VB2008, je suis tombé sur l'onglet references (VB2008 en english :-) où sont référencés les dll (et leur version framework).
J'y ais remarqué la colonne copy local, contenant un booléen et j'ai essayé de tous les mettre à vrai. Après avoir rebuildé la solution les dll sont biens intégrés au dossier contenant la solution (../bin/debug), mais après un autre test le soft ne fonctionne toujours pas sur xp.
Le fait d'intégrer les dll rend t'il superflu l'installation du framework sur le client?
Non, c'est même une mauvaise idée pour ce qui est des assemblies standards, ça ne ferait que dupliquer inutilement les fichiers sur le disque.Citation:
Le fait d'intégrer les dll rend t'il superflu l'installation du framework sur le client?
Sois tu installe le framework 3.5 sur les machines, sois tu configure ton projet pour fonctionner sur le framework 2.0 (Menu Projet/propriété/Onglet Compiler/Options Avancées/Framework cible) mais il faudra tout de même que le framework 2.0 soit installé sur la machine
Merci pour cette réponse qui répond à ma prochaine question... Je viens de configurer le soft pour n'utiliser que le 2.0 (qui s'installe sans connexion web).
J'ai également remis le copy local à false pour toutes les références, mais la compilation fait vraisemblablement encore appèle au 3.5:
Donc, sachant que ça ce compile avec succès, est-ce que jpeux espérer que le soft fonctionne sur winXP (avec framework 2.0)?Citation:
------ Build started: Project: MComplaint, Configuration: Debug Any CPU ------
C:\Windows\Microsoft.NET\Framework\v3.5\Vbc.exe /noconfig
vbc : warning BC40057: Namespace or type specified in the project-level Imports 'System.Xml.Linq' doesn't contain any public member or cannot be found. Make sure the namespace or the type is defined and contains at least one public member. Make sure the imported element name doesn't use any aliases.
MComplaint -> D:\Projets VS\MComplaint\MComplaint\bin\Debug\MComplaint.exe
========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped ==========
C'est parce que tu fais appel à Linq, qui est une des nouvelles fonctionnalités introduite par le framework 3.5.
LE framework 2.0 ne connais pas Linq.
Soit tu te passe de Linq (et réécrit une partie de ton programme), soit tu es obligé de conservé le framework 3.5 comme cible et donc de l'installer sur les machines cibles.
Effectivement, j'avais bien oublié quelques imports system totalement superflus. Par contre aucun d'eux n'était System.Xml.Linq, ni ne faisait référence à un xml ou un linq. Après les avoir retirés j'obtiens une compilation propre:
toutefois je remarque dans les propriétés de la solution, dans l'onglet references, ce trouve des imported namespaces, j'y retrouve le system.xml.linq, qui est d'ailleurs sélectionné même si la compilation ne dit rien à son sujet.Citation:
------ Build started: Project: MComplaint, Configuration: Debug Any CPU ------
MComplaint -> D:\Projets VS\MComplaint\MComplaint\bin\Debug\MComplaint.exe
========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped ==========
Est-il nécessaire de retirer toutes les références pour être sur d'éviter les conflits entre framework?
Tu clique sur le bouton "Références inutilisées", ça t'enlèvera toutes les références qui ne sont effectivement pas utilisées dans ton code.
Ça te fera un projet plus "propre", sans choses inutiles.
Normalement si elles ne sont pas utilisées, elles ne sont pas inclues dans l'exécutable, mais il est vrai que parfois ça peut perturber les fonctions de générations des pack de déploiement (même si c'est quand même rare)
Pense aussi, lorsque ton projet est finalisé, avant de faire le pack de déploiement, de passer en configuration Release et de refaire quelques tests.
Les projets devraient être toujours déployés en configuration Release et non pas en Debug comme je vois trop souvent