Where to store plugin data files

Rhino Developer Yak
1

Hello everyone,

I have been developing plugins for Rhino for a couple of years. Now we finally switched over form the old .rhi based plugin distribution to the new .yak system.

I am having some issues with this new system, and I am seeking advice regarding if I am doing this correctly or if there is a more correct approach to my solution.

Context:

The plugin relies on a couple of files which are copied into place once and stay there uninterrupted.

The plugin folder with the old system looked something like this:

AppData\Roaming\McNeel\Rhinoceros\8.0\Plug-ins\Main plugin folder 
│
├── plugin version folder 1 (eg 1.1.2.0)\
│    ├── plugin file.rhp
│    └── more plugin files
│
├── plugin version folder 2 (eg 1.3.0.0)\
│    ├── plugin file.rhp
│    └── more plugin files
│
└── Extra_folder\
     └── profiles

When there was an update, the new version of the plugin was installed in a new folder, leaving the old version unaffected.

This was convenient because the files in the Extra_folder were not affected by the update or restart. These files are profiles for the plugin, they never change and they are not packaged into the plugin as they are client specific.

I was counting on a similar solution when I migrated to the new system. I was hoping that I can set up a similar system:

AppData\Roaming\McNeel\Rhinoceros\packages\8.0\Main plugin folder
│
├── plugin version folder 1 (eg 1.1.2.0)\
│    │
│    ├── net8.0-windows\
│    │   ├── plugin file.rhp
│    │   └── more plugin files
│    │
│    └── net48\
│        ├── plugin file.rhp
│        └── more plugin files
│
├── plugin version folder 2 (eg 1.3.0.0)\
│    │
│    ├── net8.0-windows\
│    │   ├── plugin file.rhp
│    │   └── more plugin files
│    │
│    └── net48\
│        ├── plugin file.rhp
│        └── more plugin files
│
├── Extra_folder\
│    └── profiles
│
└── manifest.txt

To my surprise every time I restart Rhino all the folders in main plugin folder gets wiped except the one mentioned in the first line of manifest.txt. This means I cannot create my Extra_folder at this place.

Worth mentioning that I install the yak package directly with the -PackageManager command. The plugin is not uploaded to the online manager yet. I do not know if this has any effect on the outcome.

My solution:

During my investigation I have noticed that the persistent settings class still stores the data in the original plugin folder (not in the package folder).

I have used Path.GetDirectoryName(SettingsDirectory) to grab the plugin directory of the old place and put my Extra folder with the profiles at that location. While this is working, I feel like this is not the best / correct / most elegant solution.

Is there a better, more official way to handle these types of files?

Thank you in advance.

Barna

3

Hi Barna,

Your overall direction is correct. The package directory is simply the wrong persistence boundary.

Yak controls everything below ...\packages\<Rhino version>\<package name>. manifest.txt is Package Manager state, not an extension point, and Rhino may reconcile that directory with the active package version at startup. Treat the entire package tree as read-only, replaceable installation content. Installing a local .yak through _PackageManager does not change this behavior. This matches Yak’s documented installation model.

PlugIn.SettingsDirectory is the supported per-user location for data that must survive plug-in updates. The path resembles the old RHI tree, but it is Rhino separate, plug-in-specific settings location. I would create a child directory there instead of navigating to its parent:

internal string ProfilesDirectory
{
    get
    {
        var path = Path.Combine(SettingsDirectory, "profiles");
        Directory.CreateDirectory(path);
        return path;
    }
}

SettingsDirectory does not guarantee that the directory already exists, hence CreateDirectory. This location remains stable across Yak updates as long as the plug-in name and GUID remain unchanged. Make sure the net48 and net8.0-windows builds use the same plug-in identity.

If the profiles must be shared by every Windows user on the machine, use SettingsDirectoryAllUsers and provision the files during deployment, since writing under ProgramData may require elevated permissions.

So the clean model is: versioned binaries and bundled resources in Yak; persistent, customer-specific files in the plug-in’s settings directory.

4

Hey Lucas,

Thank you for the fast reply and the tips. Have a nice day.