Dans le cadre du projet SwissEph.Net j'ai eu des retours d'utilisateurs indiquant une différence de résultat dans les calculs entre la librairie .NET et les DLLs C originales.
Comme je n'ai pas eu de retour de la part des utilisateurs concernant le code utilisé et les différences trouvées, j'ai pris un peu de temps pour créer un projet afin d'obtenir des tests de comparaison de valeurs entre les différentes versions: https://github.com/ygrenier/SwissEphNet.TestsAndCompare.
Une fois les tests effectués, il s'avère qu'il y a bien une différence de calcul sur les flottants en .NET, mais pas entre du code C et .NET, mais entre la version 32bits et 64bits du code .NET.
J'ai récemment ressorti de la naphtaline un vieux projet (librairie en .Net 4.0), avec une vieille version de xUnit.
Comme je devais améliorer la lib, en profite pour la passer en 4.5, et je met à jou...
Si vous êtes un fidèle de Visual Studio pour faire du développement d’application ASP.NET, vous utilisez certainement l’une des fonctionnalités très intéressante "BrowserLink" qui couplée aux "Web Essentials" rend le développement Web extrêmement pratique.
Si maintenant vous vous lancez dans le développement "ASP.NET Core" le futur du développement Web de Microsoft, vous pouvez constater avec regret que cette fonctionnalité n’a pas l’air d’être disponible.
Pas de panique Yanos est là :)
Bonjour,
Pour ceux que ca intéresse la librairie SwissEph for Net est passée à la version 2.5.1.14, et elle est compilée en .NET Core.
Pour les besoins d’un petit projet j’ai recherché une solution de base de données légère, trouvant que "SQL Express" était surdimensionné pour le besoin. Et c’est là que m’est revenu un nom du fin fond de mes souvenir de développeur Delphi: Firebird.
Lorsqu’on utilise P/Invoke avec une DLL native (via l’attribut DllImport), nous devons forcer la compilation de notre application dans la plateforme de la DLL (32 ou 64 bits). Toutefois on peut avoir la DLL dans les deux plateformes (par exemple Lua 5.3) et vouloir compiler notre application en "Any CPU" et que la DLL soit chargée dans sa bonne version. Ce qui n’est pas possible directement avec DllImport().
Depuis sa version 4.0, le Framework .Net nous fourni une nouvelle librairie pour gérer les documents XML: System.Linq.XDocument.
Cette librairie et plutôt conçue pour fonctionner avec LINQ (comme son espace de nom nous l’indique).
Elle permet de créer plus rapidement des documents, de parcourir avec des requêtes LINQ. En revanche on perd le standard DOM ainsi que le XPath.
L’une des particularité de XDocument est que l’on peut lui transmettre des objets comme contenu et il s’occupe de les convertir en valeur de noeud ou d’attribut. L’inverse est également vrai, on peut obtenir une valeur depuis un noeud ou un attribut directement en transtypant. Ces mécanismes nous permettent de sérialiser/désérialiser rapidement un fichier XML quand on ne peut pas utiliser les mécanismes de sérialisation XML du .Net.
LINQ est un language de requêtage intégré au language C# ou VB.Net, le propros de cet article n'est pas d'expliquer LINQ en lui-même mais son comportement avec les énumérables. Pour plus d'informations sur LINQ je vous renvoie à la documentation officielle.
Alors à la fin de la première partie, j'en ai déjà entendus qui ronchonnaient : "bon s'il faut qu'on se cogne un énumérateur à chaque fois qu'on veut un truc particulier, on est pas sorti des ronces". C'est pas faux (côtelette power ;) ) ! En même temps c'est notre boulot :)