Package Paths on Network Drives (Again)

Packages
1

Hi all,

I know this is a classic subject, but I’ve not found a working answer after hours of digging.

We’re encountering problems with loading in certain Dynamo packages that contain .dll files, even though previously the same packages/versions were working fine. We’ve added no new packages and not changed any package versions (or underlying IT systems).

Our setup is:

  • A mix of Windows 7/Windows 10 machines looking to a single, central network location for Dynamo packages.
  • Dynamo v1.3.3 (we’re supporting projects back to Revit 2016).

I’ve looked into common fixes which have worked for other used who have encountered this before:

  • All users have read permission to this location, which is also a trusted location.
  • No .dll files are blocked, all were installed via the package manager.
  • There are no other copies of the Dynamo packages in my local files or in my app data.
  • Packages that are entirely .dyf-based load in just fine.

The Dynamo console gives the following errors for any packages containing dlls:

"Exception when attempting to load package Data-Shapes from \OurOfficeNetworkPath…\01 Packages\Data-Shapes
System.IO.FileLoadException: Could not load file or assembly ‘file://\OurOfficeNetworkPath\01 Packages\Data-Shapes\bin\Package.customization.dll’ or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515)"

I’ve tried restarting, reinstalled packages one-by-one (manually and via package manager) and reinstalling Dynamo. Any help you can offer would be greatly appreciated!

Thanks,
Ollie

3

Nice write-up :slight_smile:
I know of others who prefer the automated approach e.g. @Radu_Gidei1
Our setup has worked perfectly for us until last week, but I suspect there’s been some kind of breaking change in the way the IT-side has been set up.

5

I do too. All it takes is one windows update to either the local machine or the server, or a security setting on either to block out the packages. Without being onsite and poking at your setup pretty hard, it’s impossible to know what is blocking it.

If your IT makes such changes without vetting the impact, then I would seriously consider moving to a robocopy method, but even that isn’t perfect due to other restrictions I’ve seen of late (ie: AV blocking all DLL based systems entirely, or blocking certain ones based on the signature or the author, or even because it wasn’t white listed)…

Verify they work off the local disc as a first step. Then discuss this with your network security admin as a second step.

2 Likes
6

Fixed! It was caused by some very sneakily-blocked .dlls - they weren’t displaying as blocked (in right-click > properties) but it turns out our company antivirus was blocking .dlls on that server due to some recent IT changes.

4 Likes