Bonjour,

J'ai quelques questions en suspens concernant ma compréhension du fonctionnement d'un assembly.

Je vous remercie beaucoup d'avoir la gentillesse de m'aider à y répondre.

1-Je lis la définition suivante

Assembly version information is stored in the assembly MANIFEST and is used with the assembly name and culture to derive the assembly identity"

Je ne comprends pas ce que signifie le terme "culture" dans l'expression "and is used with the name and culture"


2-

Je lis dans cette même phrase que les informations relatives à la version de l'assembly sont stockées dans l'assembly nommé MANIFEST .

Au niveau d'une solution, j'ai trouvé un fichier nommé " AssemblyInfo.cs" et non un fichier nommé MANIFEST.

Ce fichier " AssemblyInfo.cs" contient bien les informations relatives à la version de l'assembly.
S'agit -il du même fichier nommé MANIFEST mais qui porte un autre nom ici.

3-Concernant le numéro de construction (Build number) de l'assembly, s'agit-il d'un numéro de série?

4-Concernant le numéro de révision, s'agit-il du numéro de mise à jour?

5-Pour ce qui est du numéro de version majeure , s'agit-il de la version la plus récente de l'assembly ?

6-Pour ce qui est du numéro de version mineure , s'agit-il de la version la plus ancienne de l'assembly ?

7-Pour ce qui est de l'utilitaire Ngen.exe, qui permet de précompiler des assemblys en images qui contiennent du code machine  que l'on peut executer au lieu d'utiliser la compilation just in time.

Normalement un assembly contient déjà du code précompilé(MSIL), pourquoi créer des images de ce code?

A quel moment sont créées ces images natives?
Au même moment qu'à la compilation just in time?

Quand est-il préférable d'utiliser cet utilitaire pour procéder à la compilation ?

8-Concernant le Strong Name Tool(sn.exe), il inclut des commandes pour créer une nouvelle paire de clés.
Cela signifie-t-il que le contenu  de l'assembly sera chiffré avec la clé publique par celui qui veut l'envoyer sur un réseau , puis déchiffrée par celui qui le recevra?
Cela permet alors de vérifier le contenu exact de l'assembly.

Son rôle ne ressemble t-il pas à celui de l'utilitaire Certification Creation tool(Makecert.exe)?

9-Concernant les fichiers de type .csproj, il est dit qu'ils stockent des informations tel que le "output path for the build output and the target platform"
Que signifie output path for the build output and the target platform?

S'agit-il par exemple des infos suivantes que l'on trouve dans dans la fenêtre "sortie" quand on génère un projet telles que

StressTest Unit Test Project -> C:\Program Files\Microsoft Learning\10266\Labfiles\Lab 7\Ex3\Starter\StressTest Unit Test Project\bin\Debug\Module 7 Unit Test Project.dll


Si ce n'est pas exact, je vous remercie de bien vouloir me donner un exemple.

10-Les fichiers de type .suo: ils stockent tous les paramètres modifiés pour personnaliser l'environnement de développement.
Je vois qu'il n'est pas possible de visualiser un tel fichier.

Pouvez-vous me dire si, par exemple, il stocke les informations relatives à l'ajout d'un point d'arrêt au niveau d'un fichier pendant l'activation d'un projet qui contient ce fichier?

En quoi cela est-ce utile?


11-Pour ce qui est de la fonction "restart"(CTRL+SHIFT+F5), il est écrit qu'elle est utile si on souhaite tester un code qui s'exécute quand une application  s'exécute pour la première fois(first runs) ou pour tout code exécuté seulement une fois quand une application  est utilisée.
Je ne comprends pas le terme "first runs"
Cela signifie t-il "quand une application s'exécute en premier", ou "au début de l'exécution d'une application"




12-Conversions implicites:
Pourquoi n'est il pas possible de convertir implicitement une variable de type sbyte en ushort ou uint ou ulong alors qu'il est possible de la convertir en short, int, long,double, decimal
Idem pour le type int, non convertible en ulong,

Pour ce qui et du type char, il est possible de la convetrtir en type ushort, int, utint,long,ulong,float,double, decimal.
Est-ce uniquement dans le cas où le caractère est un chiffre ou pas ?

Je vous remercie beaucoup de bien vouloir m'aider sur ces différents points.

Bien cordialement.

curieuse_prog

1) La culture, c'est la langue dans laquelle ton assembly a été compilée.

2) Le manifest est un truc créé à la compilation. Le compilateur se base sur le contenu de AssemblyInfo.cs pour générer ce manifest. C'est indirectement pareil mais AssemblyInfo.cs contient moins de trucs qu'un manifest.

Pour voir tout ce que peut contenir un manifest, il te suffit d'ajouter un nouvel élément => Application manifest file. Par exemple, un que je ne pense pas configurable via AssemblyInfo.cs, c'est le niveau de droits utilisateurs requis par un exécutable. Avec un manifest, tu peux forcer ton programme à s'exécuter avec un compte d'administrateur.

3, 4, 5, 6)Ce sont des informations comme une autre. Ces informations apparaîtront sous Windows, après compilation, lorsque tu affiche les propriétés, onglet détails, d'un fichier dll ou exe. Libre à toi de donner un sens spécifique à ces valeurs.

Par défaut, elles indiquent juste un numéro de version. Dans les entreprises, chaque composante de cette version correspond (souvent) à un process de développement donné pour un produit donné. Exemple arbitraire : Le noyau de Windows 8 serait en version majeure 8. Depuis Windows 8.1 et l'update 1, la version mineure de Windows 8 serait passé de 0 à 1 puis à 2. La révision pourrait être le n° de révision de la dernière mise à jour affectant le noyau et le numéro de build serait le n° affecté à la dernière compilation du noyau effectuée chez Microsoft, juste avant que celui-ci ne passe du stade de test au stade de produit commercialisé.

7) Information à prendre avec des pincettes...Mais là comme ça, je dirais que tes images natives sont directement le code natif généré depuis un code IL, comme s'il c'était le compilateur JiT qui faisait le taff. Le but de la manoeuvre est de gagner en performances (probablement au détriment du poids des binaires générés). Cette conversion est effectuée au moment où tu appelle ngen. Lors de l'exécution, ce sera plus rapide puisque le CLR n'aura plus besoin de faire appel au compilateur JiT pour faire fonctionner ton code.

Je pense que c'est utile quand tu vises des plateformes peu puissantes mais pouvant disposer de "grosse" capacité de stockage. De tous les projets .NET que j'ai pu faire, je n'ai jamais eu à me servir de ce type de génération.

8)Il n'y a aucun notion de chiffrement du binaire avec les noms fort. Un nom fort est une garantie d'attacher à un binaire .NET un nom unique et sécurisé. De même, il n'y a pas de vérification effectuée quand à l'authenticité de ce nom fort (sauf cas particulier comme un assembly déployé dans le GAC par exemple). Si tu veux faire un binaire avec garantie d'authenticité, peu importe la situation, utilise plutôt Authenticode.

makecert est juste là pour générer des certificats, rien d'autre. sn peut générer des noms fort à partir de certificat et les rattacher à une assembly.

9) Entre autre oui. Un csproj, c'est tout ce que ton projet est. Son nom, ses chemins de sortie de compilation, ses références utilisées, ses fichiers de code source.... C'est un peu comme un fichier make façon Microsoft (Linux -> Un fichier de configuration make contient tout ce qu'il faut pour permettre à automake d'appeler le compilateur dans le bon ordre avec les bons paramètres...Windows -> Un csproj est le fichier de configuration de l'outil msbuild.)

10) Je ne sais plus trop. Il me semble que oui, ce .suo sauvegarde les informations des points d'arrêt. A confirmer.

11) Aucune idée.

12) sbyte -> ushort/uint/ulong, tu peux perdre des données (le signe de ta valeur numérique). sbyte -> short/int/long/double/decimal, la conversion est implicitement possible car tu passes d'un format numérique signé de petite taille vers un format signé plus grand, sans pertes de données (le signe est conservé et les valeurs min/max d'un sbyte peuvent être contenues dans un short, int, long, double ou decimal).

Pareil pour int -> ulong : Tu passes d'un 32 bits signé à un 64 bits non-signé, tu risque de perdre le signe de ta valeur numérique.

Pour char vers le reste, un caractère en .NET est un caractère unicode, codé sur 16 bits (2 octets). Le signe n'a aucun sens puisqu'on parle de caractères et non pas de valeur numérique. Potentiellement, un char est implicitement convertible vers n'importe quel type numérique faisant plus de 2 octets, sans pertes de données possible. En revanche, il n'existe pas de relation directe entre le caractère codé et sa valeur numérique (le chiffre 1 ne va pas forcément coder le caractère '1'). Cette relation est définie dans les pages de codes Unicode que tu utilises. A noter que suivant la page de code utilisée, le caractère codé peut ne plus être un caractère alphanumérique standard (ça peut devenir un pictogramme egyptien, japonais, coréen ou autre symboles bizarre comme des smileys, des carrés, des angles droits...)

7 - Ngen, Cela permet d'avoir de meilleures performances car pas de JIT mais il y a des techniques avancées comme l'introspection et du codage dynamique qui ne sont plus possible. Généralement, on utilise NGEN au moment de l'installation du programme sur une machine car cela permet d'avoir une compilation parfaitement adaptée à la machine où on installe le logiciel.

10 - je confirme, avec plain d'autres choses, comme la disposition des fenêtres etc...