Rewrite Loader into C#

[romangolev]

Rewrite Loader into C#

Description

Implementing an AssemblyBuilder, UIBuilder and SessionManager refactored in C# as a substitute for the original Loader which is written in Python.
This feature aims to increase the load speeds on startup and reload events.

---

Checklist

Before submitting your pull request, ensure the following requirements are met:

• Code follows the PEP 8 style guide. -- Not applicable
• Code has been formatted with Black using the command: -- Not applicable

  pipenv run black {source_file_or_directory}

• Changes are tested and verified to work as expected. - No, just a draft for now

---

Related Issues

If applicable, link the issues resolved by this pull request:

• N/A

---

Additional Notes

THIS IS A DRAFT
Entry point is at PyRevitLoaderApplication which now have 2 modules for loading pyRevit sessions:

• legacy: ExecuteStartUpPython
• refactored: ExecuteStartUpCsharp

Adds new project pyRevitAssemblyBuilder which is set as a dependency project for pyRevitLoader and pyRevitRunner.
Whenever one of them built, dependency is built and loaded automatically.

pyRevitAssemblyBuilder is using DI (Dependency Injection) and have a set of services being instantiated on Revit startup as singletons.

On the moment of opening this draft PR, the module is able to build dummy dlls and simplified UI for them (without images and tooltips). Yet does not support yaml bundle files, does not build lib files.

Reviewers

@jmcouffin @sanzoghenzo @dosymep what do you think? Is it a way to go?

---

Thank you for contributing to pyRevit! 🎉

[sanzoghenzo]

Thanks @romangolev for the huge job!

If it was me, I would already got rid of the legacy/ExecuteStartUpPython method and the IronPython dependency, so that we can put the dlls into the bin/netcore and bin/netfx regardless of the selected python engines.

for the bundle files, I had an idea a while ago to simplify things and switch from folder-based extensions to manifest-based extensions, I'll open a feature request to see if I'm the only one or if this could be a valuable feature that could already be implemented in this PR

[dosymep]

manifest-based extensions

I think if we create good architecture, we can support two way to create tabs :)

[dosymep]

@romangolev Good Job!

I have some doubts about the DI container from Microsoft, we can get into a situation with dll hell and I would like to see a more OOP architecture of this. It would be cool to separate the structure parser from the main libs into a separate one, where there would be no dependence on revit, python and other things, only pure code (service) for parsing the structure.

To implement these things that I listed, you need a lot of effort, and make many important decisions, so I think, for a start, to get rid of the python code, your implementation is perfect.

[jmcouffin]

manifest-based extensions

I think if we create good architecture, we can support two way to create tabs :)

Agreed; but if we start supporting extra worklflows, I will need pyRevit to provide me a paid job ;o
Joke aside, I like the idea of manifest-based extensions:

• Simplifies greatly the extensions part of the code base
• Allow for a specific UX to create those

Side projects I work on that could leverage a manifest based extensions and streamline extension creation

WIP: https://builder.pyrevitlabs.io/

[romangolev]

@sanzoghenzo it's just the start! The legacy loader has quite a lot of code on and because of that, I believe that gradual approach is preferable. I would say that after implementing this feature we may end up with some unpredictable bugs, so for users to be able to make a step back and activate the old way of loading things might be a walk-around in order not to lose main functionality.

[romangolev]

@romangolev Good Job!

I have some doubts about the DI container from Microsoft, we can get into a situation with dll hell and I would like to see a more OOP architecture of this. It would be cool to separate the structure parser from the main libs into a separate one, where there would be no dependence on revit, python and other things, only pure code (service) for parsing the structure.

To implement these things that I listed, you need a lot of effort, and make many important decisions, so I think, for a start, to get rid of the python code, your implementation is perfect.

@dosymep thanks man🙏
I had a doubt about the packages as well. Should we degrade this and implement execution without DI? I'll dig it to see if it's a big deal, but yeah, in case somebody else loads that same dlls, the result might be unpredictable.

Also, the Parser itself doesn't have a lot now, so it wouldn't be a problem to make a separate csproject from it.

[jmcouffin]

@romangolev how is your progress, I just saw the commits but cannot really test, I need to keep my dev environment clean for a presentation next week.
Let me know if you need me/us to test ride the thing.

[romangolev]

@jmcouffin these are the commits regarding to the comments of @dosymep
I managed to got rid of DI and moved the extension parser to a separate file.
That's it for the moment.
Next move is going to be implementing functionality gradually to make it work similar like a python loader 😎
So yeah, probably a little early for a full fledged testing

[jmcouffin]

@romangolev you are on fire!
Thanks for all that

[romangolev]

@jmcouffin consistency is the key!
Even though it feels like a lot, doesn't seem to be like we are halfway through (by code lines count 😎)

Anyway, the situation is as following:

• Create a carcass for a new loader
• MVP to be able to run scripts within the revit ui
• Hook up new parameter to allow to switch between loaders
• Rewrite hashing mechanism to identify changes while reloading extensions
• Parse xaml bundle files mechanism
• Map images to UI panels
• Hooks registration
• Rewrite environment loading tools to c#

Probably something else will pop up as well, but this is as far as I can see now 🧐