I've been using an AzureBatch Pool for a while, with deployed application packages, and been able to modify/update them through Azure with no problems, for months.
I tried to create a new pool that is configured exactly the same as my current pool, but with a separate app package.
My problem is the folder structure is almost completely different between the two pools and I don't know what I can do about it.
The path for the original pool to the exes I need looks like: C:\user\tasks\applications\wd\'packagename'\'version'\'nodetimestamp'\'PACKAGENAME'
But in this new pool the structure looks like:
C:\user\tasks\apppackages\'packagenameNodetimestamp'\'PACKAGENAME'
I cant see how these pools are created any differently, I've tried to recreate this new pool several times, but it comes out the same. Not all of the options when creating a pool are viewable from Azure Portal after it has been created, but I'm pretty sure it is just a cloudservices pool, windows server 2012 R2 for both.
Any help would be greatly appreciated, thank you for your time.
EDIT:
Accepted answer is obviously correct. I had not updated my environment variable references to reflect the change in pools that I had made.
The packages that you've specified for a pool or task are downloaded and extracted to a named directory within the AZ_BATCH_ROOT_DIR of the node. Batch also creates an environment variable that contains the path to the named directory. Your task command lines use this environment variable when referencing the application on the node.
On Windows nodes, the variable is in the following format:
Windows: AZ_BATCH_APP_PACKAGE_APPLICATIONID#version
On Linux nodes, the format is slightly different. Periods (.), hyphens (-) and number signs (#) are flattened to underscores in the environment variable. Also, note that the case of the application ID is preserved. For example:
Linux: AZ_BATCH_APP_PACKAGE_applicationid_version
Further to add:
The internal mechanism and Dir structure is dependent on the OS type and IMO (In my opinion) it is no where recommened to be dependent on the hard coded location hence the mechanism to access these feature is via env vars, i..e whatever underlying changes may happen the env vars will point to the source of right dir.
If keen: There was an upgrade in place few months back and the feature notice is residing here: https://github.com/Azure/Batch/issues/1
Hope this covers the scenario and helps!