Durée d'exécution commune?

Question

Quelque chose que je ne sache pas clarifier, je comprends bien qu'il existe des différences entre C # et VB.NET (principalement en ce qui concerne l'utilisation de pointeurs), mais pourquoi, si les deux ont un CLR commun, XNA (par exemple) ne fonctionne-t-il qu'avec C # et non pas VB.NET, ou est-ce que les ajouts à Visual Studio ont été conçus pour C # plutôt que pour VB.Net, et en réalité, les extensions de langage fonctionnent dans les deux

Désolé si c'est une question évidente, je pensais que je poserais

Answer 1

Le CLR a été porté sur différentes plates-formes, qui ne sont pas toutes égales. La XBox 360 CLR, par exemple, ne possède pas Reflection.Emit ni même tous les ops IL que le CLR complet fait . Par conséquent, un compilateur différent peut émettre des codes IL qui sont légaux sur le CLR complet, mais illégaux sur le Compact CLR.

L'autre problème est la disponibilité des bibliothèques de classes. La BCL complète inclut l’espace de nom Microsoft.VisualBasic , qui est automatiquement référencé par le compilateur VB.NET. Ceci contient les compatibilité VB6 , la < a href = "http://msdn.microsoft.com/en-us/library/microsoft.visualbasic.myservices.aspx" rel = "nofollow noreferrer"> Mon espace de nom , ainsi que certaines fonctionnalités fonctions auxiliaires du compilateur , est communément appelé le VB. Runtime NET.

Chaque fois que le CLR est porté, certains assemblys le sont et d'autres pas. Pour la XBox, Microsoft.VisualBasic n'a pas été porté. Cela signifie que vous ne pouvez rien référencer de cet espace de noms. Bien qu'il soit assez facile de ne pas faire référence à la compatibilité ou à Mes espaces de noms, les services du compilateur peuvent être insérés dans l'IL compilé sans que vous ne les appeliez explicitement.

Dans VB.NET 8, vous pouvez transmettre un non documenté et non pris en charge -novbruntimeref basculez vers vbc.exe pour l’empêcher de faire référence à Microsoft.VisualBasic.dll. Malheureusement, cela causerait parfois des erreurs de compilation impairs. Dans VB.NET 9, il est devenu documenté, pris en charge et renommé / vbruntime .

Le troisième cas est celui des compléments et du support de Visual Studio. Cela dépend des paquetages individuels, de savoir s'ils supportent les templates, le code gen, etc. pour chaque langue. Je pense que certaines tierces parties ont publié des modèles VB.NET pour XNA, bien que ce soit pas officiellement pris en charge .

En résumé, j’imagine que c’est un mélange de problèmes techniques (ports CLR, disponibilité du BCL, sortie IL du compilateur) et de support (tests, financement et addins pour d’autres langues).

Answer 2

C’est l’ensemble d’outils qui définit le support linguistique. XNA, par exemple, a simplement effectué tout son travail avec C # et n’a fourni que le support correspondant. Vous pouvez toujours écrire une application dans VB.NET et la compiler manuellement à partir de la ligne de commande. Tant que votre application ne compilera pas en IL illégal (opcodes non pris en charge par XNA), elle sera toujours exécutée. Le principal problème concerne les ressources: ils ne disposent pas de la main-d'œuvre nécessaire pour développer et tester intégralement toutes les langues. Ils en ont donc choisi une.

Answer 3

De tous les comptes, VB.NET et C # sont équivalents à 99,9999 en ce qui concerne le CLR. Mais il y a quelques légères différences qui peuvent vous mordre. De plus, je me souviens avoir lu sur un blog de Microsoft que le CLR peut effectuer certaines tâches qui ne sont pas (encore) programmables par VB.NET ou C # et qui doivent être effectuées par IL. Intéressant en effet.