Create Chocolatey package

[cd21h]

Please add Chocolatey distribution package. https://chocolatey.org

[vancem]

Can you describe the value of doing so? What can I now do that is cool?

[cd21h]

Easy to install and receive updates.

I use chocolatey to create workstation setup scripts. E.g.
choco install nuget.commandline -y choco install 7zip -y choco install jmeter -y ... ...
would be great to have an ability to install perfview the same way

Thanks

[welwood08]

To save duplicating work, it's probably worth mentioning that a package already exists. It's not been updated for a while, but see jivkok/Chocolatey-AutomaticPackages#17.

[nzbart]

I think that the requirement from my perspective is really to be able to install the product via a common package manager from the command-line.

Given the movement to command-line and automatic management of systems (infrastructure as code), some kind of installer that doesn't require clicking in a GUI and downloading via a browser would be great. Microsoft has recognised in the past the value of such a product via their OneGet or PackageManagement product, but unfortunately that initiative seems to be dead in the water. Currently, the only viable Windows package manager is Chocolatey, which is probably why the original poster created the issue with this title.

Our developer machines are built using a PowerShell script, so the result of not having an installer accessible via a common package manager is that they don't have this product installed on their machines unless they download it themselves, which restricts the spread and popularity of PerfView within our organisation.

[jzabroski]

OneGet was renamed PowerShellGet. It can still do generic nuget repositories, but the code quality is low and good luck getting Microsoft to fix bugs in it, even when you point out the exact lines of code that are broken. Ultimately, I hope PowerShellGet dies a sweet death and someone who understands how Yumm/Rpm or Synaptic package manager works builds it correctly. So far, the only intelligently designed package manager for Windows is paket. NuGet is finally improving but missing much of the genius of paket's dependancy model (the bug in 3.3 where they returned a non-zero exit code inexplicably on a successful run is just the tip of the iceberg with my frustration with Nuget, or the fact NuGet Restore would barf on nested solutions, etc..).

…

On Sun, Sep 2, 2018, 7:13 PM nzbart ***@***.***> wrote: I think that the requirement from my perspective is really to be able to install the product via a common package manager from the command-line. Given the movement to command-line and automatic management of systems (infrastructure as code), some kind of installer that doesn't require clicking in a GUI and downloading via a browser would be great. Microsoft has recognised in the past the value of such a product via their OneGet or PackageManagement product, but unfortunately that initiative seems to be dead in the water. Currently, the only viable Windows package manager is Chocolatey, which is probably why the original poster created the issue with this title. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#562 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAbT_f5sqPgXWLShA4cLn7xLzPMDGj3tks5uXGYQgaJpZM4SEdq8> .

[vancem]

I truly don't understand the nuances of package managers. Indeed in Chocolatey seems to have competitors like paket and oneget. But from my perspective, I don't actually care to pick a winner. It is enough to support thing that people want.

This is clearly something that that community that cares about it should be doing. I would assume that making a Chocolatey package (or updating the one referenced above) is pretty easy for someone to 'just do'. They may not need any change at all from this repository (other than updating the docs to point people at the package).

In short, I am OK with SMALL, obviously otherwise non-impactful pull requests to help make package managers work with PerfView. What I need however is someone who ACTUALLY uses these package managers to take the lead and come up with at design, vet it here, and submit any PRs that are needed. My expectation is that it would take only a day or so of work.

So if people want this, there is nothing stopping you. Please vet what you intend here before investing significant effort, but that should be a formality. If you need information from me just ask.

[jzabroski]

I think that the requirement from my perspective is really to be able to install the product via a common package manager from the command-line.

I truly don't understand the nuances of package managers.

Pretty much all Windows package managers speak nuspec as a common language, and differ only in what "helper files" to run to install the package. For example, OctoPack requires PostDeploy.ps1, Chocolatey requires ChocolateyInstall.ps1, etc.

So if people want this, there is nothing stopping you. Please vet what you intend here before investing significant effort, but that should be a formality. If you need information from me just ask.

I think for your application, there are a couple of discrete tasks:

1. If I do the following, I believe it will allow silent install:

 .\PerfView.exe abort /LogFile:dummy.log /AcceptEula

This is required to write: cinst Microsoft.PerfView -y or cinst Microsoft.PerfView --accept-license

I suppose it would be good to have an integration test to ensure this behavior stays that way.
Is there a way I can undo /AcceptEula to write such a test?

2. Create the nuspec file and write a simple ChocolateyInstall.ps1

3. Consider posting as part of the release a checksum on the two exe's and PDB files, to avoid possible man-in-the-middle attacks. (You should probably do this anyway.)

[vancem]

Thanks @jzabroski for the discussion.

Yes, the command

     .\PerfView.exe abort /LogFile:dummy.log /AcceptEula

will accept the Eula, but you could also simply skip it and simpy copy the EXE. There is no 'installation' it is just that the behavor of the app is slightly different the first time you run it. There is a pitfall for users that what to script PerfView (they have to remember to use /AcceptEula), but arguably there is no 'installation' necessary for perfview.

Create the nuspec file and write a simple ChocolateyInstall.ps1

Sounds easy enough for anyone to create a PR (presumably they go in src\PerfVIew)

Consider posting as part of the release a checksum on the two exe's and PDB files, to avoid possible man-in-the-middle attacks. (You should probably do this anyway.)

Note that if the PerfVIew is deployed by a nuget package, we now sign all of our packages (which would include this new one). I can make sure that this new package gets signed and uploaded go Nuget.org when updates happen (we already do this for the TraceEvent nuget package.

So I am asking somone who cares about this to make a PR to make the nuspec and chocately file and test that it works locally, as well as update to the *.md files so we can document how to use it (I will also need this to test the end-to-end).

[vancem]

Just FYI (although I would recommend simply not having an 'install' at all.

Is there a way I can undo /AcceptEula to write such a test?

There is a command in the GUI 'File -> Clear User Config' that does that. You probably wanted a non-gui way of doing it. If you delete the directory %APPDATA%\PerfView you will remove all config associated with PerfView.

[jzabroski]

There is no 'installation' it is just that the behavor of the app is slightly different the first time you run it.

I'm just describing the bare minimum required to be compliant with pretty much any package manager. Here is the user story:

As a system administrator using Boxstarter to configure clean,consistent User Desktop deployments of Windows within my company, I want to be able to silently install software and accept all licenses on behalf of the user.

Note that if the PerfVIew is deployed by a nuget package, we now sign all of our packages (which would include this new one). I can make sure that this new package gets signed and uploaded go Nuget.org when updates happen (we already do this for the TraceEvent nuget package.

So I am asking someone who cares about this to make a PR to make the nuspec and chocately file and test that it works locally, as well as update to the *.md files so we can document how to use it (I will also need this to test the end-to-end).

Checksuming the final nupkg ("compiled archive" zip) is an external checksum, but not a checksum on the individual components. A nuspec file can take a download URL to get the final package from, as in an "online installer", similar to how Visual Studio installs/upgrades on your machine today. I probably anonymously report, under my pseudonym, more man-in-the-middle attacks of this variety than any other attack vector I report. I'm also guilty of it myself: https://github.com/jzabroski/chocolatey-packages/blob/master/appfabric.caching/chocolateyInstall.ps1 - This example code also shows you why simply signing the NuGet package with NuGet package signing is not sufficient, as the nuspec file is just a shell for metadata whereas the ChocolateyInstall.ps1 is where the meat and potatoes is.

[vancem]

I'm just describing the bare minimum required to be compliant with pretty much any package manager. Here is the user story:
As a system administrator using Boxstarter to configure clean,consistent User Desktop deployments of Windows within my company, I want to be able to silently install software and accept all licenses on behalf of the user.

I imagine this is one of these policy issues that is part of an 'arms race'. EULA by design are supposed to be 'in your face' for legal reasons. I would suggest that we side-step the issue by not trying to auto-accept for now, and get that 'goodness' to users, and then treat as a separate issue whether the last step can be done by Microsoft (we can't stop people outside Microsoft from doing lots of things, but we have to at least obey our own rules (and I don't know what they are in this case, some research is needed)).

On the issue of checksums: Note that PerfView.exe is also digitically signed itself (as is PerfVIew64.exe). The page https://github.com/Microsoft/perfview/blob/master/documentation/Downloading.md tells you how to check the signature manually using windows explorer or signtool, but I have no illusions that people will actually do this.

[jzabroski]

I imagine this is one of these policy issues that is part of an 'arms race'.

No, it's really just that with a lot of machine building tools, any application that pops up can cause the whole process to hang.

Auto-accept is a misnomer, anyway. It's really "I know what the license says and I don't have time to re-read it, so please just let me install this." Msiexec.exe already supports this feature implicitly through /quiet Windows [Standard Installer Command-Line Options(https://docs.microsoft.com/en-us/windows/desktop/msi/standard-installer-command-line-options), but I get your legalistic reasons for working on an open source project a Microsoft and wanting to clear things through legal (or not wanting to deal with it at all).

[ilabutin]

PerfView 2.0.26 is now available on Chocolatey: https://chocolatey.org/packages/perfview
@vancem I think you can close this issue now.

[vancem]

I am going to close the issue. PLease reopen and restart the discussion if you feel the need.