Jérémy Jeanson's blog
chasseur de bugs depuis .net 1.0

Attention, spoilers : cet article va tordre le cou à une fausse idée sur les limitations d’ASP .net classique (.net Framework).

Oui, utiliser NPM et Gulp dans une application ASP .net classique, c’est possible. La mise en place est même très simple.

Intérêt

L’intérêt est multiple :

• Utiliser des librairies récentes (parfois indisponibles via Nuget).
• Simplifier la gestion de ses fichiers client (fini les dossiers Content, Scripts… contenant des fichiers parfois mal organisés se mêlant à nos propres fichiers).
• Réduire le nombre de fichiers déployés avec l’application web.
• Réduire le temps de démarrage d’une application .net Framework (du fait de ne plus avoir à regrouper, minifiez les fichiers client).

Comment faire?

Premièrement, il faut réorganiser son application web. Mon habitude est de créer deux dossiers

• wwwroot (comme pour une application .net core. Il servira à contenir les fichiers à déployer sur le serveur).
• www (ou _www, il servira à contenir le code spécifique à l’application).

Chaque dossier contient quatre dossiers :

• css
• js
• fonts
• images

Ensuite, on supprimera les packages Nuget des librairies clients (scripts, css, fonts). Il faut aussi en profiter pour supprimer les habituels dossiers Content, Fonts, Scripts qui sont devenus inutiles.

On peut ensuite ajout les fichiers pour NPM et Gulp.

• package.json (après édition, Visual Studio téléchargera automatiquement les librairies… comme pour une application .net core)
• gulpfile.js (après édition, les tâches seront visibles dans le task runner. Comme pour une application .net core, on peut utiliser le binding pour qu’une tâche soie lancée lors de la build du projet)

Important : contrairement à une application .net core, les fichiers générés par Gulp ne seront pas intégrés automatiquement au projet. Il faut demander à Visual Studio d’afficher la totalité des fichiers du projet et demander ensuite l’intégration des fichiers au projet. Il faudra ensuite changer les propriétés de ces fichiers pour les définir comme étant des contenus à copier en sortie de build (Type : Content).

Conclusion

Après la mise en place de ce type de solution, on se rend vite compte que son application est plus facile à maintenir. Si en plus on peut utiliser une librairie inaccessible jusqu’ici, on est 100% gagnant.

Petite astuce : on peut continuer à utiliser les bundles System.Web.Optimization (sans minification) pour référencer les fichiers produits par Gulp. L’intérêt est de continuer à avoir une URL qui changera en fonction du hash du fichier exposé (pratique pour éviter les problèmes de caches client).