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?

[dosymep]

always wanting to reinvent the wheel

because someone else's falls off without support, as we see even on our pyRevit project and RevitPythonShell and etc, the developer stopped updating it

[jmcouffin]

or do you want him to do the work for us?

if he is willing to
and if (a big one here because located in ru) we can pay him with the OC money (that would make sense?)

[dosymep]

performance: pyrevit dotnet runtime no longer to compile at Revit launch @eirannejad

it was done

[sanzoghenzo]

always wanting to reinvent the wheel

because someone else's falls off without support, as we see even on our pyRevit project and RevitPythonShell and etc, the developer stopped updating it

Maybe it's my impostor syndrome, but my tendency to use third party libraries is because I think I'm not good enough at coding and maintaining that part of code (and because I'm too lazy).
The beauty of open source libraries is that you can pick up where the original developer left off, so the lack of support can be solved when/if the time comes... but again, this is my two cents and I'm nobody in the grand scheme of future pyRevit versions.

[jmcouffin]

Maybe it's my impostor syndrome, but my tendency to use third party libraries is because I think I'm not good enough at coding and maintaining that part of code (and because I'm too lazy).
The beauty of open source libraries is that you can pick up where the original developer left off, so the lack of support can be solved when/if the time comes... but again, this is my two cents and I'm nobody in the grand scheme of future pyRevit versions

Unless this really is an issue of dll hell with potentially revitlookup, then yes, we should build our own, but in general, we would loose less energy reusing IMHO, Roman is not gone yet 😄

[sanzoghenzo]

Wait, the preview version of RevitToolkit removed the AssemblyLoadContext

Nice3point/RevitToolkit@239af2f

I didn't manage to follow the link in the changelog, but I believe this is good news for us 😉

[dosymep]

use third party libraries is because

I don't even pull my dependencies into pyRevit, so that if anything happens, all the code is available here, etc.

[sanzoghenzo]

I finally got access to the autodesk feedback platform, and indeed Revit will add add-in isolation by setting some tags in the addin manifest, so it will ensure a "DLL paradise" from the start (no assembly will be shared unless you specify the same context name in the manifest);
Unfortunately, for now there's no plan to introduce it into Revit 2025.
If it stays like this and this will only see the light with Revit 2026, then Revit 2025 will become Autodesk's Windows Vista 🤣

Analyzing the purged RevitToolkit code, I must agree with you @dosymep, it would be easier to only implement the things we need directly in pyRevit. Apologies for today's noise.

But at this point, I would wait till april and forget all of this 🙈

[jmcouffin]

But at this point, I would wait till april and forget all of this 🙈

You got me laughing!
Go to bed!