Discussion :

[Yannick038]

Bonjour à tous,

J'essaye de faire un prototype .net d'un progiciel édité par ma boite pour migrer de vb6 à .net

Actuellement je découvre donc la joie de VS2005...

Ma question est somme toute une question de gros newbie :
- L'application est découpée en neuf petites applications (9 exe)
- Je voudrais pouvoir créer une solution .net qui contiendrait une partie Noyau (toutes les fonctions de base des 9 modules, IHM, controle & validation, fonctions de communication avec les SGBD, ...)

Je suis un peu perdu sur la manière de procéder puisque si je créer des NameSpaces Application1 et Core, je peux appeller les fonctions du NameSpace Core que si il est "inclus" dans la WindowsApplication "Application 1", si j'essaye de créer un second projet de type "Librairie de classes (dll)" et que déplace le code source du namespace Core dedans, alors je ne peux plus y accéder depuis la windowsApllication "Application1".

L'instruction "using Core.AudioListener" renvoie :
Le type ou le nom d'espace de noms 'Core' est introuvable

J'ai essayé de mettre une dépendance du projet "Application1" sur le projet "Core" mais aucun changement.

L'idée au final est double :
- Organiser un peu l'expliraeur de solutions pour ne pas avoir 150 fichiers listé dans le projet "Application1" (je suppose qu'on peut aussi créer des repertoires dans l'IDE ?)
- Pourquoi pas imaginer de livrer le core sous forme d'un DLL commun à toute l'application (aux neuf modules) ? Je précise que je ne veux pas à avoir à faire des DLL import sous Visual Studio pour accéder aux fonctions. Je voudrais que ca soit gérer de manière autonome.

----------

J'aimerai donc avoir vos retours, avis & conseils, vous qui avez certainement déjà créer de mutliples projets peut être d'envergure. J'ai essayé de me renseigner sur le net mais même la MSDN n'est pas clair sur les assemblys à fichier multiples.

Donc si vous pouvez m'aider à voir plus clair... Merci d'avance !

[Inverse]

C'est assez simple.

Dans ton application, tu cliques sur référence, puis ajouter, puis l'onglet projet, puis sélectionne le projet correspondant à une bibliothèque.

Une fois que tu as réalisé cette opération, tu peux y accéder normalement en faisant par exemple:

ClassLibrary1.Class1.Message( "Woot !" );

A noter que toutes les classes que tu souhaites exposer publiquement à l'application doivent être précédées de public, exemple:

namespace ClassLibrary1
{
public class Class1
{
// blah blah blah ..
}
}

[Yannick038]

C'est assez simple.

Dans ton application, tu cliques sur référence, puis ajouter, puis l'onglet projet, puis sélectionne le projet correspondant à une bibliothèque.

Une fois que tu as réalisé cette opération, tu peux y accéder normalement en faisant par exemple:

ClassLibrary1.Class1.Message( "Woot !" );

C'est ce que je pensais mais justement ca ne marche pas!
Le compilateur me dit que l'espace de noms Core est introuvable !

[notalp]

Il faut que tu ajoutes les reférences et les dépendances entre projets (ordre de compilation)

[Yannick038]

Il faut que tu ajoutes les reférences et les dépendances entre projets (ordre de compilation)

Comme dis dans mon premier message : J'ai essayé de mettre une dépendance du projet "Application1" sur le projet "Core" mais aucun changement.

En fait c'est comme si le NameSpace Core n'éexistait pas. Intellisense ne l'affiche pas et c'est sur le using que ca plante, donc c'est bien que le compilateur C# ne sait pas ou se trouve la référence....

Sinon quelqu'un peut-t'il se proposer de m'envoyer un mini zip contenant une solution à deux projets (dont un en lib de classe dll) avec juste une ou deux fonctions exemple inside pour voir comment le tout communique ?

[notalp]

Ok mais as tu ajoutés la reference (image jointe)
Tu dois prendre la ref dans ton projet, ca devrais résoudre ton problème
Et apres tu met les using ...
si ce n'est tjs pas ca je te fais uen mini solution

[Yannick038]

Ok mais as tu ajoutés la reference (image jointe)
Tu dois prendre la ref dans ton projet, ca devrais résoudre ton problème
Et apres tu met les using ...
si ce n'est tjs pas ca je te fais uen mini solution

ha ha une nouvelle piste!
Ou je peux trouver cet écran de références (je pensai betement que ca allait être automatiquement rajouté via les dépendances) mais en fait les dépendances ont l'air de plus correspondre à une sorte de ANT file pour créer l'ordre de génération des projets, c'est cela ?

[Yannick038]

Ok mais as tu ajoutés la reference (image jointe)
Tu dois prendre la ref dans ton projet, ca devrais résoudre ton problème
Et apres tu met les using ...
si ce n'est tjs pas ca je te fais uen mini solution

Bon ben non ca marche pas mieux en fait :'(
J'ai bien le projet qui est référencé sous l'écran référence mais toujours pas de possibilité d'utiliser using !

Help !

[notalp]

A ta demande ...
Mais bon ... c simplissime ...
Et pas de commentaire sur le nomage des variables !!!
Made by "A l'arache . com"

[Yannick038]

A ta demande ...
Mais bon ... c simplissime ...
Et pas de commentaire sur le nomage des variables !!!
Made by "A l'arache . com"

soit c'est moi soit il manque un deuxieme csproj dans le zip

[Yannick038]

bon du coup j'ai repris mon projet pour voir et ca a marché du premier coup...

Alors je cherche pas à comprendre.

Venons au aux assemblys. Je cherche un pointeur ou des infos sur comment gère le .net framework les différentes versions de dll en cas de mise à jour, ect...

Vous pouvez peut être me renseigner ?

Dernière question, si je lance l'appli sans la dll ca plante forcement, y'a t'il moyen de detecter cette anomalie pour ne pas voir apparaitre la merveilleuse fenêtre du déboguage juste in time ?

Merci beaucoup

[notalp]

pour ce qui est du versionning (dll) tu as l'assembly tu as le n° de version ... conseil.
Fixe un grand maximum ... car si ton projet est partagé il faudrat que tous les n° de version de compilation concordent

[Yannick038]

pour ce qui est du versionning (dll) tu as l'assembly tu as le n° de version ... conseil.
Fixe un grand maximum ... car si ton projet est partagé il faudrat que tous les n° de version de compilation concordent

Décidément je suis un peu boulet je crois !

Ce que tu veux dire c'est que si ma DLL est utilisée dans disons une dizaine de modules :
- j'ajoute à chaque module (en fait une solution .net à part entière) le projet DLL
- si je compile chaque projet avec la même version du code source de la DLL dans ce cas pas de soucis.
- par contre si je compile un exe en ayant fait une modif dans la dll et que donne ce seul exe chez mes clients alors là catastrophe : le module recompilé marche mais pas les N autres ? (donc léger problème en cas de patch spécifique à un module (sauf que logiquement si c'est du spécifique c'est pas dans le noyau)

Tu me dis de fixer moi même le "...", mais comment on le fixe justement ?

[notalp]

tu remplaces
[assembly: AssemblyVersion("1.0.*")]
par
[assembly: AssemblyVersion("1.0.0")]

[Yannick038]

tu remplaces
[assembly: AssemblyVersion("1.0.*")]
par
[assembly: AssemblyVersion("1.0.0")]

Ah ok tu parles donc d'un "tag" pour mettre un numéro de version sur l'assembly moi je pensai au numéro de version de fichier (celui qu'on a dans les propriétés du projet en dessous d 'ailleurs du numéro de version de l'assembly), que je pense être le numéro de version de l'exe .

Quelle différence entre les deux ?

Ce que je comprends pas trop en fin de compte c'est que j'ai changé mon assembly version à 2.0.0 dans le programme et laissé à 1.0.0 dans la dll ca fonctionne, donc pas besoin d'avoir le même numéro non?

Dans quel cas exactement cela peut il merder ?

Une fois encore merci de prendre tout ce temps pour me répondre

[Yannick038]

Bon pas de réponse précise sur ma dernière question sur la gestion des Assemblies et la versionning. Toutefois je pense que le lien ci-dessous pourront donner des pistes aux gens qui se posent les mêmes questions que moi :

http://www.dotnet-tech.com/tutoriels/assemblies/

J'en profite pour mettre le tag résolu au topic.