This is a summary of nightmares and preferences. This is a C# ASP.NET MVC Core project.
The do not list
1. Do not assume that because it builds locally, it will build and deploy from the VSTS services.
- The items below are breakdowns of the issues.
2. Do not assume that the file path selector in the VSTS configuration tool knows how to work correctly.
- When I had to pick the path to my package.json file, the selector allows me to actually pick the file, which then gets added to the path. This results in VSTS to look for the file under [my project name]/package.js/package.js. How stupid is that.
3. Do not assume that VSTS will use the right version of NuGet.
- I don’t know what version the build is defaulting to, but I had to add a task to install 4.5.1 to get the build to work.
4. Do not assume that VSTS will use the right version of NodeJs
- I had to specify download of Node 6.x or later to get Gulp to work.
5. Do not assume that VSTS will know how to execute your gulp script.
- I had to specify the task names, because it defaults to ‘default’ if you don’t specify one.
6. Do not assume that your 3rd party developer is doing their job right.
- I found several 3rd party NuGet packages claimed to be core, but yet had strong dependency on framework
- I ended up creating another root solution folder called DependancyLibraries. These projects are the source code of the 3rd party projects that caused build issues. So I force the build to be compatible with what I need. I then go to my deploy project and just point to these dependencies to pull from rather than from NuGet.
My Execution Pattern
- Set Use Node to 6.x
- Use NuGet to 4.5.1
- npm install
- gulp execution This helps to make sure that I have no NuGet dependencies in my gulp builds.
- NuGet restore
- Build solution
- Publish Symbols
- Publish Artifact
- Azure App Deploy
Closing notes
I am not looking forward to converting this project over to using WebPack. I am terrified as to what new issues I am going to run across.
