pyRevit 5

[eirannejad]

Priority 1:

• branches: main-4 and develop-4 for pyRevit 4* and main and develop for pyRevit 5 @eirannejad
• support for netcore (try to keep compatibility with netfx - maybe compile pyRevit to netstandard2) @dosymep
• performance: pyrevit dotnet runtime no longer to compile at Revit launch @eirannejad

bin/
bin/netfx/
bin/netfx/engines
bin/netcore/
bin/netcore/engines
bin/pyrevit.exe <- `netcore`

• purge old ironpython engines @sanzoghenzo

Priority 2:

• performance: faster extension parsing (dotnet extension) (Bundler library)
• performance: rewrite ui builder in dotnet so it is faster

[eirannejad]

@jmcouffin @sanzoghenzo @dosymep

https://discourse.pyrevitlabs.io/t/invitation-to-pyrevit-meetup-2-12th-february-4-30pm-cet/2640/5?u=eirannejad

@dosymep
I also moved all the pyrevitlib/pyrevit/runtime/*.cs files into dev/pyRevitLabs.PyRevit.Runtime. We need to:

• setup pyRevitLabs.PyRevit.Runtime to build these csharp files into netstandard
• setup pyrevitlib/pyrevit/runtime/__init__.py to not compile these files anymore and just load the assembly and provide access to the types

[dosymep]

@eirannejad, I created draft-pr #2088

[jmcouffin]

I just fixed dependabot to work against the develop-4 branch for now

[jmcouffin]

RevitNet8UpgradeTips.pdf
for reference

[jmcouffin]

For reference, assembly load contexts
https://docs.microsoft.com/dotnet/api/system.runtime.loader.assemblyloadcontext

A way to prevent Dll conflicts that is partially implemented in some edge cases in dynamo

https://devblogs.microsoft.com/powershell/resolving-powershell-module-assembly-dependency-conflicts/

[jmcouffin]

further reference jeremytammik/RevitLookup#210

[jmcouffin]

#2088 for reference to ilpack.

[jmcouffin]

for reference, pages 20+ and pages 35+ https://thebuildingcoder.typepad.com/files/migrating_to_net_core_8_webinar.pdf

and

https://thebuildingcoder.typepad.com/files/migrating_to_net_core_8.pdf

[jmcouffin]

for reference
chuongmep/RevitAddInManager#54

[github-actions]

"👋 Hi there! It looks like there hasn't been any activity on this issue for the past 60 days. We understand that things can get busy.
Just a friendly reminder that this issue is scheduled to be automatically closed in 14 days if there's no further activity.
If you still need assistance or have additional information to share, please feel free to comment, and we'll be happy to help! 🚀
Thanks for your understanding!"

[sanzoghenzo]

I realize I ignored most of the links @jmcouffin posted here, but some of them are very valuable for trying to fix the DLL hell!

What I've learned so far:

On revit < 2025, where we can't use any kind of isolation, the plugin loading order matters because if the plugin that is loaded first uses the latest version of a dependency, this is loaded fine and used by the other add-ins.
We can add this info to the wiki, instead of blindly remove and re-add the addin, a user could check the dlls vesions the various add-ins folders. Not sure if it easier/faster, though!

On our part, we should worry about the dependency versions of the "built-in add-ins" such as dynamo, and stick to that version - but this means that we would need to use different versions for each Revit version!

With revit 2025 / .Net8 we can use the AssemblyContext; RevitLookup solved this, by leveraging RevitToolkit by Nice3point that handles isolation from version 2025.0.1

RevitToolkit is versioned following Revit versions, and its objects are compatible with revit 2019+; so we can use this library for all the versions (but the AssemblyContext feature is obviously available only on 2025).
We need to change all the reference in the code to the Revit Interfaces (IExternalApplication, IExternalCommand, and so on) to the concrete classes of this library, so that they wil be loaded in a isolated context.
We need to investigate if this library plays well with pyRevit's architecture, since we're building/managing a lot of dynamic assemblies...

One note: since RevitToolkit itself needs to be loaded in the main Revit context, it is subject by the dll hell, so we have to coordinate the version, at least with the one used by RevitLookup.

For versions < 2025, RevitToolkit has a ResolveHelper to help with the dependencies loading, but it doesn't save us from the dll hell.

PS: I may start to use the RevitAddinManager, how come I didn't know of it? 😅

[jmcouffin]

With revit 2025 / .Net8 we can use the AssemblyContext; RevitLookup solved this, by leveraging RevitToolkit by Nice3point that handles isolation from version 2025.0.1

this is the reason why I wanted to get Nice3Point in the conversation. Maybe you could continue with your remarks on Telegram in the common conversation with @dosymep and Roman Karpovich

[dosymep]

With revit 2025 / .Net8 we can use the AssemblyContext; RevitLookup solved this, by leveraging RevitToolkit by Nice3point that handles isolation from version 2025.0.1

I think it would be good if we had our own release, and if possible not to depend on other people's implementations, so as not to have problems with them in the future

[sanzoghenzo]

I think it would be good if we had our own release, and if possible not to depend on other people's implementations, so as not to have problems with them in the future

What's up with you .net developers always wanting to reinvent the wheel? 🤣 jokes aside, if you think the code we need is simple enough to implement ourselves, then by any means we should do it.
But I feel that we don't have the resources and time to extend the code base too much.

this is the reason why I wanted to get Nice3Point in the conversation

Oh, I didn't make the connection... 😅 but the library is well documented, so it shouldn't be too hard to adapt out code... or do you want him to do the work for us?