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 ), 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
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
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
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.
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).
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
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?
), they may be the source of the problem (not sure, just an educated guess).
