SemVerPS 1.1 on Windows PowerShell ends with Unable to find type [Semver.SemVersion] about semverps HOT 10 CLOSED

Closing with

• Use version 1.0 with PowerShell Desktop
• Use version 2.0 with PowerShell Core with minimum version 7.0
• Version 1.1 is now removed.

from semverps.

Also wonder if compile into .NET Standard 2.0 (so .NET Framework 4.7.2+ and .NET (Core) 3.1) would not be an answer to the JIT *.CS file. Furthermore also noticed you changed you license from MIT to GPLv3...

from semverps.

Hi @Sarafian ... It could still be that I'm doing something wrong, but it is somewhat funny that SemVerPS new version 1.1 is not SemVer compatible for me/us - it breaks. Our workaround is Install-Module -Name SemVerPS -Repository PSGallery -MaximumVersion 1.0 for now...

from semverps.

Hi Dave,
It was pull request #5. What changed was that the inclusion of new source code (the functionality is copied from the semver nuget project) and mostly fixed the code for pester 5 (had big changes). I think the Dev made changes towards the .net standard and those precompile directives might be causing problems.

I think I had done a quick check for Windows poweshell.

To my knowledge and confirmed with the pester tests the functionality didn't change, so you can use the previous version.

When I return, I'll take a look. The manifest files need to be more correct.

from semverps.

Sorry for the late response but you are indeed right.

The way the module works is that it uses the Add-Type to import the C# classes from the referenced NuGet repo. This happens in the SemVerPS.psm1. The cshart code from @maxhauser uses precompile directives but from what I know they are only considered during compile time. To address the .NET standard related changes from @maxhauser, I did what the compiler does and added the precompiler directive in the beginning of the Semver.cs which is also what broke compatibility with Windows PowerShell. With the last update, the imported c# was refactored and although the nuget package didn't break compatibility, the module which has a raw dependency to the code did.

I remember well and understand your dependency with Windows PowerShell and I would like the module to maintain backwards compatibility. But the module is actully a cmdlet wrapper around the functionality from @maxhauser's repo and as his code evolves towards core/standard so does the module move towards the core of powershell. So, I'm looking into how this could be possible.

I'm considering checking the powershell version and depending on the version add the directive or not. This would probably work. The problem I have is how does the AppVeyor CI make sure it works for Windows Powershell as well. I couldn't find much and therefore there is a new question on stackoverflow. Since you work with the Windows PowerShell maybe you have some insight to share.

In any case, I don't expect a fast response.

from semverps.

Thanks for looking into this @Sarafian! Technically it is already broken in v1.1 but y slightly increasing your platform support to .NET 4.7.2, you get access to NET Standard. So in turn you can offer a compiled version of the Semver.cs ... that is a way out.
For my favorite module ;-) I'm currently looking into https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners as free testing environments.

from semverps.

I don't want to do the compiled version. For this I never embedded the nuget package or the dll.

Technically it is already broken in v1.1

That's where I broke it. 1.0 should be still good for your windows setup.

from semverps.

@ddemeyer the new c# code won't work with or without the precompile directives. Unfortunately, following up on Max's code and keeping it simple (no compile) make the 1.1 version non-desktop version compatible. The only way to bring powershell desktop support is to load c# version code from when it worked but then the module updates are going to be gimic.

Unless you have a better suggestion, I'll create a new version with the manifest declaring the CompatiblePSEditions=@("Core")

That would mean that you need to update your dependency to v1.0 which still works in the desktop edition.

from semverps.

So summarized, are you thinking along these lines...

1. V1.0 is Desktop and Core, works
2. V1.1 is Desktop and Core with Max's latest code fixes but it broke for Desktop... so you could have the net48 and net5 C# code side by side and decide in the psm1 file on which runtime you are and which C# file to load... a patch release but latest version works again for everybody
3. V2.0 could be Core only as you mention in #9 a breaking change for the future

Thanks for looking into this :-)

from semverps.

1. V1.0 desktop edition. Core edition is broken I think for 7 or higher.
2. V1.1 is broken for desktop edition.
3. V2.0 only for core edition and respect some versioning rules. Unlist 1.1 as well.

Can't replace existing versions. Only unlist them.

I don't see how in a simple way it works for both editions. When you import a .net type it is not the same as a compiler and pre-compile directives are not defined or considered etc. I tried to fiddle with the code for the desktop edition and didn't import. Since this depends on a 3rt party's code, I don't want to have to troubleshoot it now or the future. Makes sense as the code projects are moving towards .net as well.

Functionally they are the same. Only the supported edition changes.

from semverps.