Archives de catégorie : Développement

Histoire d’une migration en .Net Core – Partie 4

Avec la disponibilité de VS2017, la prise en charge des projets .NET Core et .NET Standard a été grandement améliorée.

Courant Août sont sortis « .NET Core 2.0 » et « .NET Standard 2.0 » apportant pas mal d’améliorations. Vous trouverez les annonces officielles sur ces pages:
https://blogs.msdn.microsoft.com/dotnet/2017/08/14/announcing-net-core-2-0/
https://blogs.msdn.microsoft.com/dotnet/2017/08/14/announcing-net-standard-2-0/

J’ai donc décidé de convertir le projet SwissEphNet en projet VS2017 pour avoir une meilleure prise en charge et supprimer les « bidouilles » mises en place. Je vous renvoi au premier article de la série pour plus d’informations.

Continuer la lecture de Histoire d’une migration en .Net Core – Partie 4

[ASP.NET Core] Tester si une vue existe

Depuis la version d’ASP.NET Core (MVC 6) les anciens codes pour tester l’existence d’une vue ne fonctionnent plus du tout.

En recherchant un peu sur Internet on trouve essentiellement des tests d’existence des fichiers dans le dossiers « ~/Views » de l’application. Toutefois le système de vue utilise les File Providers pour obtenir les fichiers de vue. C’est notamment mon cas dans un projet où des vues sont « incorporées » dans les DLLs il faut donc ajouter des « EmbeddedFileProvider » (voir mon post précédent).

Par conséquent le test de fichier ne fonctionne pas dans ce cas.

Ma technique est tout simplement de demander au moteur de vue si la vue existe.

Continuer la lecture de [ASP.NET Core] Tester si une vue existe

[ASP.NET Core] Editer les vues Razor embarquées dans une librairie

En ASP.NET Core on a la possibilité de modulariser son application Web en créant des librairies permettant de partager le code (les contrôleurs, modèles, etc.).

Nous avons également la possibilité d’incorporer des ressources (fichiers script, images, vues Razor) auxquelles on peut ensuite accéder via le fournisseur de fichier EmbeddedFileProvider. En enregistrant ce fournissant dans le moteur Razor, on peut ainsi accéder aux vues qui sont embarquées dans la librarie.

Toutefois une difficulté ce pose, VS2017 n’est pas capable de prendre entièrement en charge l’édition des vues Razor, un ensemble d’erreurs s’affichent et certains fonctionnalités IntelliSense ne sont pas disponibles.

Continuer la lecture de [ASP.NET Core] Editer les vues Razor embarquées dans une librairie

VSTS – Construire une librairie .NET Standard avec VS2017

Depuis la sortie de VS2017, nous avons la possibilité de développer plus facilement des librairies .NET Standard (ce qui remplace les PCL désormais).

Si on a l’intention de faire de l’intégration continue avec VSTS (Visual Studio Team Services) pour générer notre librairie (pour la tester ou l’empaqueter par exemple), on fait face à différentes erreurs qui provoque un échec de la compilation.

Pas de panique, Yanos est là 😉

Continuer la lecture de VSTS – Construire une librairie .NET Standard avec VS2017

[xUnit] Après une mise à jour des packages, les tests ne sont plus détectés par Visual Studio

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 à jour tous les packages Nuget.

Je lance les tests unitaires pour vérifier que rien n’a changé et là … aucun tests n’apparaît dans l’Explorateur des tests de Visual Studio 2015 !!!!

Bon j’ai cherché pendant un bon moment, sans trouver de réponse satisfaisante, et j’ai trouvé la solution en recréant mon projet de test de 0, et là tout fonctionne. Alors j’ai fait quelques tests et j’ai trouvé:

La solution miracle: Modifier le projet de tests pour qu’il utilise le Framework .Net 4.6 🙂

A bientôt

Yanos

Nouveautés de C# 7.0

Avec la sortie de Visual Studio 20017, nous avons eu également le droit à une nouvelle
version du C#, le C# 7.0, avec son lot de nouveautés.

Alors ne vous attendez pas à une révolution, mais plutôt à un ensemble d’ajouts pour
améliorer l’écriture et l’exécution du code.

Faison un rapide tour de tout ça.

Continuer la lecture de Nouveautés de C# 7.0

UWP: Erreur « APPX3210 » lors de la génération des packages

Lorsque l’on veut publier une application Universelle, on doit générer les packages.

Une fois générés, ces packages passent par une « pré-validation » qui, si vous n’avez pas touché à votre manifeste, va détecter que vous n’avez pas modifié les images par défaut.

Donc vous faites de jolies icônes, mais comme il y en a une liste impressionnante avec les différentes tailles, certains d’entre vous (devrais-je dire nous 😉 ) se contentent du minimum syndical, c’est-à-dire qu’on ne fait pas toutes les images.

Et là lors de la génération des packages, vous vous prenez un erreur « APPX3210 » vous indiquant que le manifeste fait référence à une image qu’il ne trouve pas, alors que cette fameuse image est bien présente dans votre projet.

Continuer la lecture de UWP: Erreur « APPX3210 » lors de la génération des packages

Débutons avec .NET Core

Suite à mes articles précédents sur la migration d’une librairie en .NET Core , j’ai reçu des remarques de lecteurs concernant le coté un peu obscure de .NET Core dans mes explications.

J’en convient, j’ai fourni des liens sur des explications généralistes, mais finalement pas vraiment d’explications « techniques » sur ce nouveau framework.

Qu’à celà ne tienne, allons à la rencontre de notre nouvel ami.

Continuer la lecture de Débutons avec .NET Core

Histoire d’une migration en .NET Core – Partie 2

Histoire d’une migration en .Net Core – Partie 2

Dans la première partie nous avons effectué la migration de la librairie en elle-même.

Maintenant nous allons travailler sur les tests unitaires qui vont nous permettre de valider notre librairie (et découvrir quelques blagues).

Continuer la lecture de Histoire d’une migration en .NET Core – Partie 2