I see. The ImageTargetEditor looks for the image target textures in a specific directory, these textures are used for rendering the Image Targets in the scene view of the Editor. So, you should not move the location of those "special" directories used by Vuforia,  even if in previous versions of Vuforia this was "technically" possible by modifying the editor script code to point to a custom path. 

If this is somewhat in conflict with your "desired" directory structure in your project, my suggestion is to introduce a distinction between Vuforia specific assets and other assets you use in your project, and apply your specific desired directory arrangement to the latter.

I will also bring this issue to the attention of our team, just in case there is any additional tip that they could share on this topic.

Moving the materials, for example, causes an error within ImageTargetEditor, which we have no access to. How can we update the paths?

Yes, but you should be able to do that using the public API. 

We're not wanting to customise any of the internal code. I want to have the freedom to place my ImageTargetTextures, Data Sets and Default Materials in a more sensible place within our projects without causing a load of errors.

The reason is that the Vuforia internal code is not meant to be modified or exposed to public; the Vuforia SDK offers a public API, and this is what developers should use. 

I understand that customizing the "internal code" of Vuforia can be sometimes an easy and nice shortcut to obtain specific results, however this approach does not represent the recommended way of using Vuforia API, and as such it has been deprecated with the new version of the SDK.

That is my point and my query. Why has everything been wrapped up in a DLL? WIthout access to the QCARUtilities all the paths that you have declared are now set in stone, giving us no flexability to move files about to fit in with our project structure.

OK. QCARUtilities.cs is now built into the DLLs, so the source code is no longer available.

So, you will probably need to re-write that portion of "customized" code in a way which relies on just using the public API

QCARUtilities.cs

Namely it's GlobalVars struct which contained definitions for paths for all the materials/prefabs/shaders etc, which allowed us to change the folder structure away from the default that is imported.

Do you remember the name of the specific script you are referring to ? 

As long as we can load datasets from the application.persistantdatapath then we should still be ok. How about the script that allowed us to define paths for where Vuforia looked for certain things such as materials and webcam profiles? Where can that now be found and set?

Hi,

have you checked this article:

https://developer.vuforia.com/forum/faq/unity-loading-dataset-sd-card

This illustrates how you can load a Dataset from device storage; more in general, you should be able to load Datasets from various location using the standard API;  is there some specific functionality that you cannot achieve with the API (i.e. without modifying the DataSetImpl class) ?