Target Git Extensions v4.0

[RussKie]

The Plugin Manager must target v4.0 and not the "latest", otherwise it will be targeting version higher than the release. As a result it won't be loaded by the Git Extensions app.

Resolves gitextensions/gitextensions#10548

[mstv]

changes looks OK to me at first glance
local build succeeds (after digging into appveyor.yml)
signing fails in AppVeyor build (temporarily?)

---

The Plugin Manager must target v4.0 and not the "latest", otherwise it will be targeting version higher than the release.

And vice versa?

[mstv]

I have unpacked the locally built GitExtensions.PluginManager.0.0.0.1.zip to c:\Users\Administrator\AppData\Local\GitExtensions\UserPlugins\GitExtensions.PluginManager of the VM (gitextensions/gitextensions#10548 (comment)).
The PackageManager.UI.exe requests 6.0.10 instead of 6.0.11 now, and still does not recognize that a newer runtime is installed.

[mstv]

The PackageManager.UI.exe requires the x86 .NET desktop runtime. GE works with the x64 variant.

[RussKie]

The PM is built as x86. GE itself is a x86 process, but is run under x64 runtime... I don't think we need to worry too much about running the PM standalone.

…

On Sun, 18 Dec 2022, 11:08 pm Michael Seibt, ***@***.***> wrote: The PackageManager.UI.exe requires the x86 .NET desktop runtime. GE works with the x64 variant. — Reply to this email directly, view it on GitHub <#69 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABBTEXWJIVWGXTVKF7UJMZ3WN35CJANCNFSM6AAAAAATCOR5MQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[RussKie]

changes looks OK to me at first glance local build succeeds (after digging into appveyor.yml) signing fails in AppVeyor build (temporarily?)

The Plugin Manager must target v4.0 and not the "latest", otherwise it will be targeting version higher than the release.

And vice versa?

Signing requests are only accepted from release branches, and not PRs to those.

There are a lot of configs in this repo that could do with improvements, I'm unable to dedicate enough cycles for those right now

[mstv]

For GE, I have downloaded and installed the x64 desktop runtime.

The Plugin Manager (PackageManager.UI.exe) started from GE requests the x86 desktop runtime. It took long until I noticed the difference. So we might get similar bug reports as for "core runtime vs. desktop runtime".

[RussKie]

@maraf is there a reason for us to build x86 version and not x64?

[mstv]

👍 A fresh install works well

---

The Plugin Manager must target v4.0 and not the "latest", otherwise it will be targeting version higher than the release.

And vice versa?

I ask because of

GE_USE_LATEST_DOTNET: true

[RussKie]

👍 A fresh install works well

Awesome! I'll be merging this then.

The Plugin Manager must target v4.0 and not the "latest", otherwise it will be targeting version higher than the release.

And vice versa?

I ask because of

GE_USE_LATEST_DOTNET: true

I think we're talking about two different things. GE_USE_LATEST_DOTNET makes GE to build again the latest available .NET. This burns the target runtime into the runtimeconfig.json - e.g.:

      {
        "name": "Microsoft.WindowsDesktop.App",
        "version": "6.0.12"     <-- target 12 version or later
      }

This PR makes the PM to target GE v4 and not GE vNext. Otherwise, the PM may require different dependencies or different versions of those available in GE v4.
This is orthogonal to the target .NET runtime version, and the PM will target any .NET Desktop v6 version because of this:

{
  "runtimeOptions": {
    "tfm": "net6.0",
    "frameworks": [
      {
        "name": "Microsoft.NETCore.App",
        "version": "6.0.0"
      },
      {
        "name": "Microsoft.WindowsDesktop.App",
        "version": "6.0.0"     <-- target *any* version
      }
    ]
  }
}

Does this make sense?

[mstv]

Thank you for the explanation.
So the main fix is that in src/GitExtensions.PluginManager/GitExtensions.PluginManager.csproj.user.
(I focused on *.runtimeconfig.json before.)

[RussKie]

Essentially, I believe this is the fix for gitextensions/gitextensions#10548

[maraf]

@RussKie Thanks for resolving it!

The Plugin Manager must target v4.0 and not the "latest", otherwise it will be targeting version higher than the release. As a result it won't be loaded by the Git Extensions app.

I can't agree more!

@maraf is there a reason for us to build x86 version and not x64?

No, there is not.