Skrypt nie działa po aktualizacji Revita lub Rhino. Co trzeba sprawdzić?

Ten sam skrypt może działać w jednej wersji Revita lub Rhino i zgłaszać błąd w następnej. To problem zgodności z oprogramowaniem, nie historii zmian samego pliku. Trzeba sprawdzić wersję programu oraz pakiety, pliki i ustawienia potrzebne do uruchomienia skryptu.

Revit 2024 i Revit 2025 korzystają z innych platform .NET

Plik .dyn mógł pozostać bez zmian, ale dodatek lub pakiet zbudowany dla starszej platformy .NET może już nie działać. Autodesk wskazuje, że starsze dodatki do Revita trzeba przebudować dla .NET 8.

Po aktualizacji zmienia się środowisko uruchomieniowe

Skrypt opisuje logikę automatyzacji. Do jego uruchomienia potrzebujesz konkretnej wersji Revita albo Rhino oraz zgodnych pakietów, autorskich komponentów, plików zewnętrznych i ustawień. Dynamo należy do konfiguracji Revita, a Grasshopper do konfiguracji Rhino. Zapisz jednak także ich wersje, bo aktualizacja programu może zmienić cały ten zestaw. Wszystkie te elementy tworzą środowisko uruchomieniowe. Po aktualizacji programu skrypt trzeba sprawdzić ponownie, nawet jeśli sam plik się nie zmienił.

Zapisz konfigurację, którą faktycznie sprawdziłeś

Numer skryptu opisuje tylko zmiany w pliku. Osobno zapisz wersję Revita albo Rhino, pakiety, autorskie komponenty i pliki wymagane do działania. Cały ten zestaw to zależności skryptu. Dopiero po teście oznacz konfigurację jako sprawdzoną.

Każdej obsługiwanej aktualizacji Revita odpowiada określona wersja Dynamo for Revit, dlatego zapisz oba numery. Powiązania wersji opisuje dokumentacja Autodesk. Wersje pakietów i decyzje w tabeli są przykładowe.

Jedna baza kodu może obsługiwać kilka wersji Revita

Wtyczka do Revita nie musi mieć osobnego projektu .csproj dla każdego rocznika. Można utrzymywać jedną bazę kodu i budować z niej osobny plik dla każdej wspieranej wersji Revita. Taki gotowy plik to build. Każdy build odwołuje się do właściwej wersji Revit API i trafia do katalogu dodatków danego rocznika.

Revit 2025 przeszedł z .NET Framework 4.8 na .NET 8. Autodesk określa tę migrację jako zmianę wymagającą przebudowania starszych dodatków. Kod wspólny może zostać, ale wynik kompilacji dla Revita 2024 używa net48, a dla Revita 2025 net8.0-windows.

Nice3point/RevitTemplates przygotowuje konfiguracje typu Debug.R24, Release.R25 i Release.R26 w jednym projekcie. Różnice Revit API można wydzielić do bloków kompilowanych tylko dla wskazanych wersji.

Revit wczytuje pliki .addin, które wskazują mu bibliotekę i punkt startowy wtyczki. Taki plik to manifest. Trafia do katalogu przypisanego do konkretnej wersji, na przykład Autodesk\Revit\Addins\2025. Opisuje to dokumentacja rejestracji dodatków Autodesk.

Jeden projekt może tworzyć wtyczkę dla kilku wersji .NET

Od wersji 8.20 Rhino 8 domyślnie używa .NET 8. Budowanie jednego kodu dla kilku platform .NET nazywa się multi-targetingiem. Jeden projekt może tworzyć pliki dla net48, net8.0 i net10.0. Yak pozwala później opublikować kilka zgodnych wariantów tej samej wersji pakietu. Grasshopper jest dostarczany z Rhino, więc w pakiecie wskazujesz wersję Rhino, nie osobną wersję Grasshoppera.

Plik Dynamo nie ma automatycznej zgodności ze wszystkimi wersjami Revita

Każdej aktualizacji Revita odpowiada określona wersja Dynamo for Revit. Sam graf może otworzyć się w nowszej wersji Dynamo, ale zgodność może przerwać nowy węzeł, zmiana Revit API, silnik Pythona albo pakiet z biblioteką binarną. Dynamo 3.0 przeszło na .NET 8, dlatego pakiety zbudowane dla Dynamo 2.x nie mają gwarancji działania w Dynamo 3.x.

Praktyczna zasada wynikająca z ograniczonej zgodności wstecznej jest taka: jeżeli jeden graf ma obsługiwać kilka roczników Revita, rozwijaj go w najstarszej wspieranej wersji i testuj kolejno w nowszych. Nie zapisuj jedynej kopii w nowszym Dynamo przed zakończeniem prób. Nowszy graf może nie otworzyć się w starszej generacji Dynamo albo używać funkcji, których tam nie ma. Ta sama zasada dotyczy definicji Grasshopper korzystających z komponentów dostępnych tylko w nowszym Rhino.

Pakiety aktualizuj osobno

W Dynamo Player okno Graph Dependencies pokazuje pakiety, lokalne definicje i pliki zewnętrzne wymagane przez skrypt. Autodesk opisuje to okno i wykrywanie brakujących zależności.

Rhino Package Manager obsługuje wtyczki do Rhino i Grasshoppera oraz prywatne źródła pakietów. McNeel opisuje, jak Package Manager służy do zarządzania wtyczkami. W oknie brakujących obiektów możesz uruchomić wyszukiwanie brakującej wtyczki. Ta funkcja nazywa się Package Restore i używa nazwy, identyfikatora oraz wersji. Zadziała tylko wtedy, gdy skonfigurowane źródło potrafi dopasować właściwy pakiet. Jeżeli znajdzie pakiet, ale nie dokładną wersję, instaluje najnowszą stabilną. Powstaje wtedy nowa konfiguracja, którą trzeba sprawdzić.

Automatyczne odzyskiwanie nie zawsze działa. Starsza wtyczka rozwijana przez społeczność może nie być już aktualizowana albo nigdy nie trafić do Package Managera. Dostępna nowsza wersja może też nie pasować do starej definicji. Na forum McNeel znajdziesz przykłady braku pakietu w menedżerze oraz konfliktu między wersjami wtyczki.

Dla sprawdzonej konfiguracji zapisz dokładną wersję pakietu i źródło instalacji. Zatwierdzone autorskie pakiety .yak możesz udostępnić zespołowi w prywatnym źródle pakietów Rhino.

Jeśli centralnie zarządzasz komputerami w pracowni, możesz zautomatyzować instalację zatwierdzonych pakietów. Nadal potrzebujesz listy zatwierdzonych wersji i testu przed szerokim wdrożeniem. Automatyczna instalacja zatwierdzonych pakietów to temat na osobny artykuł.

Cztery decyzje skracają kolejne migracje

1. Trzymaj logikę narzędzia poza klasą uruchamianą przez Revit lub Rhino. Przy zmianie API poprawiasz wtedy cienką warstwę integracji, nie cały program.
2. Buduj wszystkie wspierane wersje z jednego repozytorium. Osobne kopie projektu szybko zaczynają różnić się przypadkowymi poprawkami.
3. Kompiluj każdą wersję przy każdej zmianie kodu. Sam udany build nie zastępuje testu w Revit lub Rhino, ale wykrywa odwołania do metod niedostępnych w wybranej wersji programu i platformy .NET.
4. Utrzymuj mały model wzorcowy i kilka prób najważniejszych poleceń. Po zmianie programu uruchamiasz ten sam zestaw i porównujesz wynik.

Najpierw sprawdź konfigurację, którą chcesz wdrożyć

Na wydzielonym stanowisku albo maszynie wirtualnej przygotuj dokładnie tę wersję Revita lub Rhino, pakiety, autorskie komponenty, pliki i ustawienia, które mają trafić do zespołu. Tak powstaje kontrolowane środowisko testowe. Uruchom skrypt, który ma trafić do zespołu, oraz krytyczne skrypty zależne od tej samej konfiguracji. Użyj modeli wzorcowych z zapisanym oczekiwanym wynikiem. Porównaj każdy wynik z tym zapisem i zanotuj decyzję dla całej konfiguracji. Dopiero wtedy zdecyduj, czy wdrożyć ją w całej pracowni.

Test ma potwierdzić dokładnie tę konfigurację, która później trafi na komputery zespołu.

Wróć do artykułu o wersjonowaniu skryptów Dynamo i Grasshopper.