Unable to extend private and public extensions from GitHub Repo

Just to be sure: @InkRF_WasTooShort are you using the pyrevit cli MSI installer? or the exe?

I see that the 5.x releases (tags in github) are not tied to any branch in the repository (I believe that’s because we disabled the git push in the CI pipeline, but since we put the dlls back into the repository, we can re-enable it to have a clearer history).

I saw that the file that is used to build the MSI package has been changed in the latest release with a large diff (the link below points to the file but diffs are collapsed)

In there you can see that there are many files that shouldn’t be there (@Jean-Marc the ones that you shouldn’t have added in the first place :rofl: ), they may be the source of the problem (not sure, just an educated guess).
I see that the git dll is in bin\runtimes\win-x64\native\ and in bin\netfx and bin\netcore folders, but not directly in bin along with LibGit2Sharp.dll.

But I believe that the pyrevit CLI should be managed and packaged separately from pyrevit, because it doesn’t need all the things that are in the bin folder (cengines and netfx in the first place, maybe other things)
At the same time, since the pyrevit cli is only compiled for netcore, putting the dlls directly in the bin folder might disrupt pyrevit that runs in revit < 2024.

I have been using the exe installer. Just installed v5.0.1 of the CLI with the msi installer & I was able to extend extensions just fine.

That’d be apprechated :slight_smile:

Mainly curious here - would you like to see it in its own repo & whatnot or something else? Just based of semantics alone it can be fun telling people how pyRevit and pyRevit CLI are two different things, but pyRevit does have the CLI included in it.

Do you have all Net frameworks installed? Having a look around, I saw that this error sometimes happens when LibGit2Sharp is targeting the wrong framework

Latest Installed .Net Framework: 9.0.0
Installed .Net Target Packs: v4.0 v4.5 v4.5.1 v4.5.2 v4.6 v4.6.1 v4.7.2 v4.8 v4.X 
Installed .Net-Core Target Packs: v9.0.101 

Yes, we have been installing .NET 8.0 Desktop Runtime (v8.0.13) since the v5 CLI will not run without it. Just for context here is what I have installed.

I am interested in that list of .NETs you have there, are you getting that from pyrevit env? I recall it listing installed .NETs in past versions but since v5 came out the CLI seems to not be able to pull that anymore (I am calling it from powershell with admin perms):

==> User Environment
Microsoft Windows 10 [Version 10.0.26100]
Executing User: TP\JW
Error: Could not load file or assembly 'System.Management, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.
Run with "--debug" option to see debug messages

Yes, it is showing in the bottom of the output. But interesting that I just tried it at work and got an error in the pyrevit env command.

==> Running Revit Instances
Error: Object reference not set to an instance of an object.
Run with "--debug" option to see debug messages 

You seem to be missing the 4.8 framework. Could that be it?

By chance you have Revit open right now? I know sometimes the env command will not complete/throw an error if any Revits are open

Maybe? Would be strange that past versions of the CLI (v4.8.16 and before) worked fine without it.

I suppose this speaks to my lack of knowledge, but I kind of thought that Revit would download any of the .NETs that it needed, i.e. 4.8 for 2024 and below, and 8.0 for 2025 on. We do now have a step in our deployment to install it (again if needed) but just assume it came with Revit.

You are correct, I closed Revit and it worked.

Yes, it does makes sense. I have no idea what is happening as well haha

Obligatory

1 Like

Oh, so my assumpion were wrong…
the builder of the exe installer takes everything from the bin folder, and the native dll is “misplaced”, but this is true also for version 5.0.0, so I’m not sure if this is the problem anymore.

we talked about it internally a while ago, it could be a good thing to separate the various parts into their own repositories… but for the CLI it could be just a matter of creating a separate build target for the release pipeline that uses a temporary folder for compiling and packaging only the necessary files.

Since we have introduced the double runtime (.net 8 for revit 2025 and net framework for older versions), having the bin folder shared between pyrevit and the cli makes little sense, since those dll are (or should be) compiled only for .net 8, the target runtime for the CLI, so they should be in the netcore subfolder (where the libgit2sharp issue is already solved - this is why the extension manager works).

1 Like

Just tried it in my work machine it worked fine as well.

I see that LibGit2Sharp is in the netcore folder on the repo but its also in the bin folder as well. If I just missed something feel free to just reply “it should be that way” but figured I’d bring it up incase it should only be in the netcore folder

citation needed

Just want to double check here too - are you talking about a different issue with the extension manager (i.e. the one in the pyrevit toolbar) or the issue with the CLI we’re talking about now?

this:


this is because of

1 Like

Gotcha, thanks for the confirmations :slight_smile:

I encountered the same error with v5.1.0 pyRevit CLI .exe installer, and I can’t seem to find a .msi installer for 5.1.0 or 5.0.1, but the .msi installer for 5.0.0 worked, and so no longer giving the LibGit2Sharp dll error. This is fine for now, since we’re not using Revit 2026 yet.

1 Like

Glad to hear I’m not the only one experiencing it. Still can’t find what the root cause is. :frowning:

There is an issue with the .exe installer for the cli.
I tried it the other day. Probably something messed up in the paths for the installer.

Regarding the MSI for the cli for 5.1
https://github.com/pyrevitlabs/pyRevit/releases/download/v5.1.0.25094%2B1017/pyRevit_CLI_5.1.0.25094_admin_signed.msi

You can always find the MSI in the assets of each release.

1 Like

Thanks @Jean-Marc, I’ll look for the MSI there.

Is there a preferred way to uninstall older versions of the CLI remotely / silently? I had set up remote deployment scripts to install the old version a while ago, and I’d like to move people to the new version, but so far I’ve had to use the Windows Add/Remove programs tool. I can’t find any documentation anywhere for what flags the installers accept, and just installing over the old version didn’t seem to work.

(Apologies if I should be moving this to another thread)

@d-ho-215 at the moment windows remove is the only means i know how, which we are able to call remotely/silently, but we will still do some manual uninstall steps in terms of cleaning up the PATH env vars, as well as the contents in ProgramData and AppData