Better handle dependency mismatch between host and core tools

[ejizba]

originally posted by @Francisco-Gamino in https://github.com/Azure/azure-functions-core-tools/pull/2987#issuecomment-1069406086

The Core Tools build for Integration testing was failing for sometime because the Host referenced Microsoft.ApplicationInsights version 2.20.0 while the Core Tools referenced version 2.18.0. The workaround was to create a new branch and update Microsoft.ApplicationInsights to 2.20.0.

Going forward, would it make sense to have a similar script like https://github.com/Azure/azure-functions-core-tools/blob/v4.x/validateWorkerVersions.ps1 with all the packages that are referenced in the Host and the Core Tools, and run it every so often to keep the packages updated? Thoughts?

Reply by me:

Tbh, as a non-.NET developer I'm not that familiar with how nuget and dependencies are handled. I've heard of "nuget dependency hell", but I have not had much experience with it until now.

In Node.js, people normally specify ranges of a dependency by default instead of a specific version. I'm pretty sure dotnet/nuget supports ranges, though, right? Any issue if I changed "2.20.0" to "2.*"? We care about the worker versions (why the script is necessary), but do we really care which minor version we get for app insights? For some reason, I don't see people use ranges a lot in .NET and I'm not sure why.