Discussion :

[Basicnav]

Bonjour,

je souhaite developper une appli pour mon boulot (gestion et suivi des visites médicales)

sachant que j'utilise parfaitement excel et vba, et de bonnes connaissances acces, je m'interresse au vb.net.

est-il le choix que je dois priviliégier ? je devrais y implanter une base de données apprendre plein de choses...alors est insurmontable pour un débutant en programmation mais à l'aise avec vba ?
une fois developpé sur mon poste personnel, puis-je compiler facilement pour le mettre sur un poste à mon boulot (genre .exe) sans y ajouter un tas d'appli pour le faire tourner ???

merci de votre aide !!

[sevyc64]

Bonjour,

je souhaite developper une appli pour mon boulot (gestion et suivi des visites médicales)

sachant que j'utilise parfaitement excel et vba, et de bonnes connaissances acces, je m'interresse au vb.net.

est-il le choix que je dois priviliégier ? je devrais y implanter une base de données apprendre plein de choses...alors est insurmontable pour un débutant en programmation mais à l'aise avec vba ?

Insurmontable non.
VB.Net est quand même bien différent de VB6 et VBA. Contrairement à ce que a voulu faire croire Microsoft à sa sortie, il est à considéré comme un nouveau langage et non pas comme une nouvelle version de VB6/VBA.
Tu retrouve les mêmes mots clés du langage VB mais la philosophie est différente. Si tu as un peu de temps devant toi tu peux te lancer, tu as de nombreux tuto et ressources sur DVP

une fois developpé sur mon poste personnel, puis-je compiler facilement pour le mettre sur un poste à mon boulot (genre .exe) sans y ajouter un tas d'appli pour le faire tourner ???

Il te faudra de toute façon l'IDE pour développer soit Visual Studio (avec tous les langages) payant soit la version allégée Visual Basic Express (un IDE par langage) gratuit. L'IDE te permet de compiler et de créer donc l’exécutable.

Pour le faire tourner sur une autre machine, il faudra que le framework .Net dans la version correspond à ton executable soit installé sur la machine.

[Basicnav]

Un grand merci !

tes explications sont claires et vont beaucoup m'aider à faire mon choix.
pour le moment, je me dirigerai vers access car le temps n'est pas à l'apprentissage d'une nouvelle philosophie comme tu dis

Mais je vais m'y plonger côté perso pour les prochains projets pro...

merci merci merci!

[BenoitM]

VB.Net sera légérement plus facile pour toi car tu connaitra une petite partie de la synthaxe.
Part contre, ca t'encouragera certaines malfaçon hérité du VB6/VBA (je crois qu'elles sont un peu plus rendu difficile que la version 1 et 2 mais bon).

Le C# te semblera plus complexe au début (rah c'est foutu ; en fin de ligne) mais :
1) Tu trouveras plus d'exemple sur le Net
2) Tu sera moins enclin à utiliser ton passé de VB6
3) le C# est plus rechercher dans les profils que le VB.Net

[Sehnsucht]

Part contre, ca t'encouragera certaines malfaçon hérité du VB6/VBA (je crois qu'elles sont un peu plus rendu difficile que la version 1 et 2 mais bon).

Je comprendrais décidément jamais cet argument ; on ne déconseille pas C++ à ceux qui veulent en faire sous prétexte qu'ils peuvent faire des cast comme en C alors que c'est pas la façon de penser C++ mais avec VB oui.

[humour]c'est pas parce qu'il y a Basic dans le nom que les gens qui s'en servent le sont forcément[/humour]

Je remets pas forcément tous les arguments en cause non plus

Cordialement !

[sevyc64]

Part contre, ca t'encouragera certaines malfaçon hérité du VB6/VBA (je crois qu'elles sont un peu plus rendu difficile que la version 1 et 2 mais bon).

Pour ça c'est simple, il suffit de systématiquement désactiver l'import du namespace Microsoft.VisualBasic

[Sehnsucht]

Même là je suis pas d'accord (désolé ) le namespace à éviter c'est Microsoft.VisualBasic.Compatibility (qui me semble totalement obsolète et plus supporté depuis les dernières versions du framework, et c'est pas un mal )tout ce qu'il y a dans Microsoft.VisualBasic c'est du pur .Net managé voir ici et le passage important

And though the new Visual Basic Runtime provides similar facilities as its predecessors, it is entirely managed code (developed in Visual Basic .NET) that executes on the common language runtime. Furthermore, the Visual Basic Runtime is part of the .NET Framework, so it is never something separate that your application has to carry or deploy.

Many of the methods in the Visual Basic Runtime actually use methods and properties from the System namespace (for example, Len() returns String.Length).

Cordialement !

[sevyc64]

Même là je suis pas d'accord (désolé ) le namespace à éviter c'est Microsoft.VisualBasic.Compatibility (qui me semble totalement obsolète et plus supporté depuis les dernières versions du framework, et c'est pas un mal )tout ce qu'il y a dans Microsoft.VisualBasic c'est du pur .Net managé voir ici et le passage important
Cordialement !

Oui c'est du pur .Net mais ça reste uniquement pour des raisons de compatibilités avec les anciens VB. D'ailleurs c'est clairement dit dans l'extrait que tu cite :

And though the new Visual Basic Runtime provides similar facilities as its predecessors, it is entirely managed code (developed in Visual Basic .NET) that executes on the common language runtime. Furthermore, the Visual Basic Runtime is part of the .NET Framework, so it is never something separate that your application has to carry or deploy.

Many of the methods in the Visual Basic Runtime actually use methods and properties from the System namespace (for example, Len() returns String.Length).

Rien de ce qui se trouve dans Microsoft.VisualBasic n'est indispensable. Tout ce qui se trouve dans cette librairie existe ailleurs dans les autres classes et dans l'esprit OO. Cette librairie n'est là que pour maintenir des pratiques datant des anciens VB non .Net. Ces pratiques doivent être considérées comme obsolètes car elle te maintiennent dans des pratiques loin d'être les meilleures en programmation objet et t'éloignent justement de cette philosophie de la programmation objet.
Ça fait 10 ans que je développe en .Net après avoir fait plusieurs années de VB6. Ça fait (quasiment) 10 ans que je bannie cette librairie et je ne l'ai que très très rarement trouver de manque. Et quand c'est le cas, elle peut de toute façon être toujours référencée explicitement dans le code. Mais c'est explicite et ça se voit, donc on sait pourquoi on le fait.


Et perso, lorsque je dois analyser (officiellement) du code, je refuse d'analyser les codes qui importe cette librairie au niveau projet ou fichier et les codes qui n'ont pas options Explicit et Strict à ON

[Sehnsucht]

J'ai jamais dit qu'elle était indispensable non plus, je précisais juste la distinction entre ce qui est officiellement obsolète (reliquats VB6) et le reste, après, personnellement, je m'en sers également peu, uniquement parce qu'à force de jongler entre les différents langages .Net je n'y pense pas (faire UBound ou Array.Length par exemple).

Par contre tout ce qui se trouve dans cette librairie est OO (pour rappel tout le Framework .Net est OO même cette librairie) ce n'est pas parce que ça parait être une fonction libre que c'en est une (dans le cas évoqué c'est un appel à Microsoft.VisualBasic.Information.UBound).

Je ne dis pas tout ça pour promouvoir ces pratiques on est d'accord que visuellement pour un débutant voir une "fonction libre" peut être déroutant et risque d'induire en erreur sur l'apprentissage et le paradigme objet.

C'est la raison pour laquelle j'essaie d'être exhaustif sur l'explication. C'est pour moi du même ordre d'idée que le débutant C++ qui fait ces cast à la C [(type)variable] plutôt que de la manière dont il faudrait le faire en C++ [static_cast<type>(variable) par exemple] les deux marcheront pareils (en gros) mais l'un est "mieux" que l'autre.

Cordialement !

[Pol63]

Part contre, ca t'encouragera certaines malfaçon hérité du VB6/VBA

Je rejoins Sehnsucht, je viens de vb6 et en commancant vb.net j'ai appris avant de coder
le problème n'est pas d'enchainer vb6 et vb.net, mais de ne pas se poser de question entre les 2
si quelqu'un passe de vb6 à c# sans se poser de question il codera n'importe comment aussi

Ces pratiques doivent être considérées comme obsolètes car elle te maintiennent dans des pratiques loin d'être les meilleures en programmation objet et t'éloignent justement de cette philosophie de la programmation objet.

là aussi je rejoins un peu Sehnsucht, Microsoft.VisualBasic n'est pas le diable réincarné en DLL
écrire split(unstring, délimiteur) n'est pas plus moche que unstring.split(délimiteur), et ca fait le même travail

[BenoitM]

écrire split(unstring, délimiteur) n'est pas plus moche que unstring.split(délimiteur), et ca fait le même travail

1) Je trouve débile de devoir faire des efforts intellectuelles quand tu dois convertir quelque chose.
Parfois je trouve du code exemple, je fais un copier coller et ca marche mais si utilise des spécifité du langage VB.Net, tu dois réfléchir pour trouvé ce que ca fait et le convertir en C#
2) Split(string,string) est anti POO vu que ca sort de nulle part

Pour ça c'est simple, il suffit de systématiquement désactiver l'import du namespace Microsoft.VisualBasic

Je ne sais pas si c'était possible en 2005 et ca me semblerait plus logique qu'on faisse l'inverse devoir activé l'import, désactivité le strict mode , et le explicit mode :p

Bon la prochaine fois je dirai qu'il suffit activité/désactivé ces options si on bien débuté avec le VB.Net

[Jean-Marie Grave]

Bonjour à tous.

Je puis vous assurer par expérience personnelle qu'il est possible de passer du Vb6 au Vb.net, même à l'âge de 72 ans. Mais c'est long, car il faut adopter (un peu à la fois), la tournure d'esprit adéquate (encouragé par mon vieux pote Socrate, je n'irai pas jusqu'à parler de philosophie).

Par ailleurs, je pense qu'il est toujours inélégant de renier ses anciennes amours, en programmation comme ailleurs.

Cordialement.

[Pol63]

1) Je trouve débile de devoir faire des efforts intellectuelles quand tu dois convertir quelque chose.
Parfois je trouve du code exemple, je fais un copier coller et ca marche mais si utilise des spécifité du langage VB.Net, tu dois réfléchir pour trouvé ce que ca fait et le convertir en C#
2) Split(string,string) est anti POO vu que ca sort de nulle part

1) ok, on emmerde les c#iens, mais c'est pas bien grave
de plus un c#ien lambda n'avouera jamais partir d'un code vb.net

2) certaines méthodes shared sont anti POO aussi, certes ca range la méthode dans ce avec quoi elle a rapport, mais ca n'est lié à rien non plus, elle serait ailleurs qu'elle fonctionnerait de la même manière
if sort de nulle part non plus, c'est un mot clé du langage, on peut très bien se dire que split serait un mot clé du langage servant à découper un string, c'est une fonction de base comme une autre ...
à moins que tu n'aurais préféré écrire TestCondition.If(Condition, Action) pour être lié à une classe

PS : ca faisait longtemps qu'on avait pollué un topic ^^

[sevyc64]

de plus un c#ien lambda n'avouera jamais partir d'un code vb.net

SI, sans problème.

JE code aussi bien en C# qu'en VB.Net et aussi en VB6 (même si c'est très dur d'y revenir quand on a gouté au .Net) ainsi que d'autres langages.

Je convertis aussi du C# en VB que du VB en C#. Ce qui est faisable dans l'un est faisable dans l'autre (pas toujours simplement pour quelques cas particuliers)

Je ne sais pas si c'était possible en 2005 et ca me semblerait plus logique qu'on faisse l'inverse devoir activé l'import, désactivité le strict mode , et le explicit mode :p

C'est possible depuis VB2005 au moins.
Et c'est ce que dit plus de 90% de la communauté des dev .Net, mais on en est à la 5ème version avec VS2010* et Microsoft s’entête toujours à rester sur ces positions sur ces points là, et bien qu'un pas ait été fait avec VB2010 puisque l'assistant de conversion des projets VB6 n'existe plus.

* 6ème version avec VS2012, mais je ne l'ai pas encore testé, je ne sais pas ce qu'il en est sur ce point