[VS2005] Plantage Release / Debug

**Nico28** · 10/07/2008, 09h44

Bonjour à tous.

J'ai un soucis qui devient vraiment agaçant :
En VS2005, j'ai de gros projets (dans le sens beaucoup d'objets et de Forms), dont certains, étant utilisés par plusieurs projets, sont situés dans d'autres répertoires et intégrés dans la solution en tant que lien.

Mon soucis est que Visual Studio se plante (sablier infini) lorsque je passe de la configuration Release vers Debug.

Même une ré-install complète de Visual studio n'a rien changé au problème.
Qqun a t il une idée sur l'origine du problème ?

**tomlev** · 10/07/2008, 09h48

Ton architecture est à revoir je pense... si tu as des classes utilisées dans plusieurs projets, crée une DLL qui contient ces classes, et référence la dans les projets qui en ont besoin

**Nico28** · 10/07/2008, 09h50

Envoyé par tomlev

Ton architecture est à revoir je pense... si tu as des classes utilisées dans plusieurs projets, crée une DLL qui contient ces classes, et référence la dans les projets qui en ont besoin

Penses-tu donc que c'est le coté "lien" qui fragilise mes solutions ?

**tomlev** · 10/07/2008, 10h11

possible... enfin, bien sûr ce n'est pas normal que ça plante à cause de ça, mais tu aurais peut-être moins de problèmes avec une architecture plus "propre"

**Nico28** · 10/07/2008, 10h21

Dans le cas d'une architecture telle que tu la décris, comment faire pour utiliser Dotfuscator ou un outil équivalent pour planquer un peu le code ?

J'ai lu qqpart qu'il y a moyen de générer du code réellement "exe" mais je trouve plus où !!

**tomlev** · 10/07/2008, 10h27

J'ai jamais utilisé dotfuscator, mais je vois pas pourquoi ce serait différent avec cette architecture... il suffit d'obfusquer aussi la DLL si besoin.

Générer du code exécutable natif, c'est ce que fait le CLR quand il exécute du code MSIL ("assembleur" .NET)... le code natif produit est mis en cache, et réutilisé si le code MSIL n'a pas changé. Si tu veux générer à l'avance ce code natif, tu peux le faire avec ngen.exe, mais ça ne te donnera pas un exe que tu pourras livrer à la place de ton programme .NET, ça mettra simplement le code natif correspondant en cache (pour accélérer la première exécution du programme). Bref : si tu veux livrer du code natif, développe en C

**Nico28** · 10/07/2008, 10h28

Envoyé par tomlev

J'ai jamais utilisé dotfuscator, mais je vois pas pourquoi ce serait différent avec cette architecture... il suffit d'obfusquer aussi la DLL si besoin.

C'est différent parce que le nom des fonctions est recodé !!