Implement Better Get-Package Registry Key Interpretation

[Smorgan05]

From what I can gather Get-Package interprets information in the registry from the following keys:

• 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall'
• 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall'
• 'HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall'

These keys tell Get-Package what programs are installed on Windows. For example when one does the following:

This information is pulled from the following key:

The information is already present within the information pulled from Get-Package as shown here:

This means that proper interpretation has not been implemented by OneGet.

Now we can see that the Key has much more information than what is provided by Get-Package. What I want to see occur is this:

In order to accomplish we need to interpret what is already there with the following logic:

• Version Number: Use Regex to pull the number from the Display Name or the program information from the executable
• Architecture: Based off the Path of the Registry Key Path or PE Header
• Install Date: Based off the Last Write time for the Registry Key
• Install Size: Based off the EstimatedSize Key or the Install Directory Size
• Source: Based off the UninstallString Folder location

Install Date Logic: https://gallery.technet.microsoft.com/scriptcenter/Get-RegistryKeyLastWriteTim-63f4dd96

The problem with the existing system is that the Version Number can be blank. In order to have a dynamic package I need a version number that is 100% accurate. This will enable me to use OneGet to make a next gen package manager. I know these features can be added as I already have the PS Code that does this as shown here:

While we are at it can we add de-duplication to the Get-Package Command and a match based means to pull packages as seen in the picture above?

[edyoung]

Thanks Morgan.

At this point we don't have any resources to investigate this more deeply. If you or any other community member would like to propose a concrete implementation via pull request, we can look at that.

A couple of things to think about if you do want to pursue that.

Bear in mind that not all packages in Package Management are MSIs. It also covers multiple other package types. Try running "Find-Package * -ProviderName msu" to find Windows Updates for example. I believe most of the changes you're suggesting only apply to MSIs. Likely you would change the MSI package provider to implement this, and you'd need to ensure changes didn't break other package types.

I don't think trying to extract a version number from a display name is reliable enough to pursue.

[edyoung]

I am not saying anything against your proposal.

The most important thing I'm saying: sorry, but my team doesn't have time to work on it.

If you want it, submitting a pull request or forking the project is the best way to go.

The rest of my comments were suggestions on things to look out for while implementing changes.

On Tue, May 15, 2018 at 9:30 PM, Morgan Overman notifications@github.com wrote:

Edwin,

This would not break ANY package providers. All that is being done is providing more concrete information from OneGet. I will be frank here is there any reason not to implement these changes across the board? I don't see a reason why this can't be done because I would think that you guys would approve of having higher quality information provided by OneGet.

In regards to other package types perhaps you guys can implement standards which cover all Package Providers such that this basic information is provided no matter the Provider. The ideas in this proposal are basic information for installing any type of package. In what use case do you not want to see the Version information, Architecture, etc?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/OneGet/oneget/issues/359#issuecomment-389391049, or mute the thread https://github.com/notifications/unsubscribe-auth/AACyCq6xSaU3FhllqZl0L-E6hsry2iNBks5ty6tQgaJpZM4UAin4 .

[Smorgan05]

Edwin,

Ok, I'll meet you guys half way. Can you at least give me the logic diagrams for OneGet so I don't have to debug / reverse engineer it? I want to implement these changes but at the same time I don't want to spend days figuring out how Get-Package works on the back end.

I want to go ahead and make a stab at doing this. I have already forked the OneGet repository so I do intend to implement these changes. What's your best guess at the amount of changes that will have to be implemented to make these possible? Also why don't you guys have the time to implement these changes? Some of these changes would be trivial to implement.

[edyoung]

We don't maintain detailed class-by-class diagrams. Visual Studio can generate some and you might find the diagrams at https://github.com/OneGet/oneget/blob/WIP/readme.md helpful.

[Smorgan05]

Ok, there are no class-by-class diagrams. How much code rewrite / addition is this going to take? Furthermore, it looks to me like there is no interpretive logic layer for the Programs Provider. Can we simply add a new unified interpretative layer on the top side?

Basically, I still want to move forward on this but I want to do so wisely. I'm not going to move forward rashly until I have a good all around idea of the structure of OneGet. I don't want to duplicate existing logic meaning I want to get this right the first time. Also there has to be some sort of org chart for this project that details functionality. Where is it?

[Smorgan05]

Are there any more materials that you can give into order to properly integrate these features? It seems to me that there MUST be some documentation that is used to organize OneGet.

[edyoung]

We don't maintain any secret behind-the-scenes documentation - anything we have is available from GitHub and linked to from https://github.com/OneGet/oneget/blob/WIP/readme.md . I suggest creating a pull request for a small part of the changes you want (for example, filling in one property).

[Smorgan05]

Sorry for the delay been a bit busy. I plan to look into the software architecture property first. That said there is no native command to pull the registry key last modify time. Would it be possible for this to be implemented in the registry as a property for each key? From an auditing perspective it makes perfect sense to have this in place.

[edyoung]

https://blogs.technet.microsoft.com/heyscriptingguy/2014/01/02/leverage-registry-key-time-stamps-via-powershell/ might help

[Smorgan05]

Ok, from a forensics, security auditing, and functional perspective that is just absurd. There is no guarantee that the information will be there in terms of the InstallDate or LastWrite. I suggest we use the following script from a porting perspective:

https://gallery.technet.microsoft.com/scriptcenter/Get-RegistryKeyLastWriteTim-63f4dd96

In order to implement a property that uses Reflection in order to put this into PS. Is there a sub developer that I can work with in order to implement these changes? Also clarification with OneGet being open source I can publish my own documentation because of the lack of its existence without running into any legal issues right?

[edyoung]

You can freely publish documentation, articles, blog posts etc. If you want to change the existing documentation it is covered by an open source license and we can look at pull requests

[Smorgan05]

Ok, I accept that you guys suck at documentation which is being charitable. Now do you have anyone I can talk to in order to piece together an overarching diagram so I have an understanding of how OneGet Works? This project must have an architecture to facilitate it's modularity.

[edyoung]

You can see the tests we have in the same repository.

On Sat, Jun 16, 2018 at 1:22 AM, Morgan Overman notifications@github.com wrote:

Ok, We're doing the pull request. The Core Provider code is horrific. I don't even know how this passed unit testing. Did you guys do unit testing?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/OneGet/oneget/issues/359#issuecomment-397796827, or mute the thread https://github.com/notifications/unsubscribe-auth/AACyCh6VyRXJYOx-PkIPuhblqHdwlWnQks5t9MA1gaJpZM4UAin4 .

[darkmastermindz]

Up to the task of generating better documentation and cleaning up code!

[Smorgan05]

I've decided to flip my CheckModule to a public repository and moved the Program Provider source over to the same repository. In order to port the PowerShell version over to C#. The code comment style being used is overkill and at the same time lacking. There is another issue here which is that the Program Provider still has debugging libraries in use which slow down the execution of PackageManagement.

Public Repo link: https://github.com/Smorgan05/CheckModule

I've started slowly cleaning things up with the untested copy of my edits in the same repo. I plan to sketch out the logic for the entire code rewrite tomorrow for the Program Provder. Admittedly the original coder had the right idea but the current code is over engineered.

[Smorgan05]

Ok, I know it has been some time since I last replied to this thread but I was away. Anyways I've gone ahead and posted the draft design diagrams to move this forward. Any code rewrites are going to have these so that we have an easier time keeping up with changes. I'm very confused as to why the original code did not use Binary Search or rather frankly anything other than linear search.

Input is very much appreciated at this phase as I want to get this right. At the present time I am using Visio Professional in order to make these diagrams.

[Smorgan05]

@edyoung Can I possibly get some debugging instructions on the Core Provider? Thanks! I have that module referenced in a console application in VS but I need help on debugging it.

[ThomasNieto]

@Smorgan05 are you still interested in getting this feature? I maintain a replacement for the OneGet project called AnyPackage and have an idea on how to these properties easier for the package provider.