Install-moduleFast seems to drop off trailing .0 in module directory when installing.

[AHelsby]

Used install-modulefast to install the connectwisemanageapi module. This is currently 0.4.15.0 but it got installed to 0.14.15 directory (with no trailing 0.
The module then (silently) fails to import
Importing the module with the full path, then generates the following.
import-module "C:\Users\me\AppData\Local\powershell\Modules\ConnectWiseManageAPI\0.4.15\ConnectWiseManageAPI.psd1"
Import-Module: The ModuleVersion key in module manifest 'C:\Users\me\AppData\Local\powershell\Modules\ConnectWiseManageAPI\0.4.15\ConnectWiseManageAPI.psd1' specifies module version '0.4.15.0' which does not match its version folder name at 'C:\Users\me\AppData\Local\powershell\Modules\ConnectWiseManageAPI\0.4.15'. Change the value of the ModuleVersion key to match the version folder name.

I renamed the folder to 0.4.15.0 and the module is now importable.

[JustinGrote]

Thanks for your submission! I thought I had fixed all occurrences of this bug, which have to do with the way [Version] normalizes compared to [SemanticVersion], but I'll investigate. Thanks for providing the specific package and API that is affecting you.

[ykuijs]

Hi @JustinGrote, do you have an ETA on when you are able to fix this issue?

Keep up this great work!

[JustinGrote]

Thanks for following up! I don't as I've been focused on a couple other projects but I hope to get to it sometime in the next month.

[JustinGrote]

OK, so I investigated this and it's a problem with the new Sleet-based pwshgallery backend and packages with 4 version parts that specifically end in .0

Sleet is dropping the trailing zero since that's not really a nuget package thing and PowerShell still supports it because....reasons.

This is not going to be an easy fix so for trailing zero packages I can't promise to get around to them anytime soon, however the Cloudflare-based backend works so try this as a workaround.

❯ imf -whatif 'ConnectWiseManageApi=0.4.15.0'
What if: Performing the operation "Install 1 Modules" on target "C:\Users\JGrote\AppData\Local\powershell\Modules".
                                                                                                                  
Name                 ModuleVersion Location                                                                       
----                 ------------- --------                                                                       
ConnectWiseManageAPI 0.4.15        https://pwsh.gallery/flatcontainer/connectwisemanageapi/0.4.15/connectwiseman… 
                                                                                                                  
                                                                                   ⏱ 0.027s
❯ imf -whatif 'ConnectWiseManageApi=0.4.15.0' -source old.pwsh.gallery
What if: Performing the operation "Install 1 Modules" on target "C:\Users\JGrote\AppData\Local\powershell\Modules".
                                                                                                                  
Name                 ModuleVersion Location                                                                       
----                 ------------- --------                                                                       
ConnectWiseManageAPI 0.4.15.0      https://www.powershellgallery.com/api/v2/package/ConnectWiseManageAPI/0.4.15 

I filed christaylorcodes/ConnectWiseManageAPI#72 to ask the upstream package maintainer to switch to x.y.z format which should solve it for this package specifically.

[ykuijs]

Currently I have implemented a workaround, which might be a solution here as well:

I am looping through the modules folder, reading the manifest PSD1 and retrieving the module version. Then comparing the module version with the actual folder name. If those do not match, I will correct the folder name:

$moduleFolders = Get-ChildItem -Path $targetModulesPath -Directory

foreach ($moduleFolder in $moduleFolders)
{
    $folders = Get-ChildItem -Path $moduleFolder.FullName -Directory
    foreach ($folder in $folders)
    {
        $manifestFilename = "{0}.psd1"-f $folder.Parent.Name
        $manifestFullPath = Join-Path -Path $folder.FullName -ChildPath $manifestFilename
        if (Test-Path -Path $manifestFullPath)
        {
            try
            {
                $manifestData = Import-PSDataFile -Path $manifestFullPath.ToString()

                if ($folder.Name -ne $manifestData.moduleVersion)
                {
                    Rename-Item -Path $folder.FullName -NewName $manifestData.moduleVersion
                }
            }
            catch
            {
            }
        }
    }
}

[JustinGrote]

@ykuijs this is the fix I would typically implement as well, unfortunately it kills performance having to read all the module manifests to determine if the version actually matches on the off chance there is a trailing zero problem.

Perhaps I'll implement it in a way that only triggers on versions with a trailing zero.

[ykuijs]

Absolutely agree with that, doing that for all the modules as part of the ModuleFast code doesn't make sense. You might change an intentional changed version number and break logic of an user.

My idea was to do this for just the modules that have been installed by ModuleFast. That would make more sense. Or maybe you can detect a potential trailing zero somewhere in your code and correct it when this is the case.

[JustinGrote]

So this issue is more pernicious than just the simple #99 fix:

1. We have no way of narrowing candidate modules, since 3.2.1.0 presenting as 3.2.1 is valid.
2. Even if we rename the folder, our initial module reconciliation doesn't read the manifest either (for the same slowness reasons mentioned earlier), it goes by the folder paths, so now subsequent install/updates won't detect the module is already installed. We also have no way of knowing what the nuget version was prior to installation.

To resolve this, we can probably drop a originalversion file into the module folder, and look for this file only on folders that have 4 parts to their version number, and use that for reconciliation purposes. The rest should occur as normal.

For the resolution, Import-ModuleManifest is pretty expensive, I'm pretty sure 99.999% of modules have ModuleVersion = 'x.y.z' on a single line so I'll write a StreamReader to do the same that, in the context of the parallel operations, should not impart much of a hit.

In addition, we should be able to notice when the requested module version (e.g. 4.5.1.0) differs from what the API returned.

For now I'll get out a release that lets you install once but will skip any modules that have 4 number versions for updates (to allow for CI scenarios) and fix the update part later.