search

microsoft / vssetup.powershell

PowerShell module to interact with Visual Studio Setup
MIT License
233 stars 41 forks source link

upgraded out of date nuget packages #69

Closed milarso81 closed 2 years ago

milarso81 commented 3 years ago

updating nuget packages

milarso81 commented 2 years ago

@heaths the goal here is to make sure any third party packages are on the latest possible version to be in compliance of our security policies for things we ship or make available to customers. I am going to take one pass to make sure only third party packages are updated, and the setup packages are not.

heaths commented 2 years ago

Having the latest package doesn't make it secure, nor would I expect the security policy to state you should just use the latest without regard for any known CVEs.

The concern here is that you are upgrading to a new major version, which for a semver-versioned package (which this is) means breaking changes. Have you verified that output isn't adversely affected? If both the binary output and nupkg are still versioned correctly then it's probably a safe change.

There are also build validations that need to be fixed. Seems to just be having to fully qualify namespaces to satisfy the linter (must be a new linter).

heaths commented 2 years ago

I'm not sure what's wrong with the build. The NuGet package provider is still valid, but the "oneget" mention in the build log is outdated. The platyPS package is still available via the NuGet package provider as well. I wonder if it'd work if you just replace these two lines:

https://github.com/microsoft/vssetup.powershell/blob/65a71775b367aedc5eef9bfeb6e07b014325223c/build/build.yml#L26-L27

With just Install-Module -Name platyPS -SkipPublisherCheck -Force -Confirm:$false

It could also be that the PowerShell installed on that windows-2016 agent is just too old. I know that OneGet was deprecated a while ago, and that older instance might be all it has. Perhaps changing the pipeline to install a more recent version of PowerShell (Core) would help.

heaths commented 2 years ago

/azp run Microsoft.vssetup.powershell

azure-pipelines[bot] commented 2 years ago
Azure Pipelines failed to run 1 pipeline(s).
heaths commented 2 years ago

Pipeline is failing to run. According to docs the pwsh task is indeed valid (I thought it was, but wasn't 100% sure when I suggested it - might've been mixing it up with GitHub Actions). We'll have to take a look.

heaths commented 2 years ago

/azp run Microsoft.vssetup.powershell

azure-pipelines[bot] commented 2 years ago
Azure Pipelines successfully started running 1 pipeline(s).
heaths commented 2 years ago

Saw that server-2016 agents are going out of support, though I think our current agent vs2017-server2016 is custom. Still, we can't pull a server-2019 container image on a server-2016 agent, so the agent probably needs to be upgraded. According to https://docs.microsoft.com/azure/devops/pipelines/agents/hosted#software the windows-2019 image does have VS2019 which should work to build both vssetup.powershell and vswhere (recommend using the same agents and dockerfiles to easy of troubleshooting and sharing test environments), and the agent OS matters less for this repo anyway (fully-managed).

FWIW, the only issue I had building vswhere on a machine with VS2019 and VS2022Preview installed (never had VS2017, IIRC) was during a DEBUG build, but should be easy to resolve if it happens on agents:

cl : Command line error D8016: '/ZI' and '/guard:cf' command-line options are incompatible [C:\Users\heaths\src\vswhere\src\vswhere.lib\vswhere.lib.vcxproj]