And this is the difference: I'm not importing the original SXS folder into the Repository, I'm importing an self-extracting Archive, that contains the SXS Folder (and content), so the path is quite short. The "magic" is happening on the client during Installation, by first expanding this archive and then triggering the installation command.
Delivering .NET 3.5 with Software Delivery runs into the described problem, that (depending on the configuration of the Software Library) the sxs path is extended by \\ServerName\Central_Repository\Software Delivery\..... and then the Source path becomes too long. Even reducing this path to for example \\ServerName\Rep\SWD\... will not solve the problem, because using the Full sxs Package allows only to add additional 19 characters to the path (yes, we counted them ;) ).
We ran into the same problem with several other Applications, like Adobe Creative Cloud for example, so we created two Workarounds:
1) Create an self-extracting Archive, and check-in this self-extracting Archive into Software Repository. Self-extracting archives can be configured with a default expand path and a default command executed after expanding:
In this case, the "dotNET_Framework35_W8.1.exe" is checked into the Software Repository with the install command "dotNET_Framework35_W8.1.exe -dC:\Install\sxs"
Within the archive the command after expanding is configured (execute after expansion option) as "dism.exe /online /enable-feature /featurename:NetFX3 /All /Source:C:\Install\sxs /LimitAccess"
Even if you were able to check in the original sxs package, you will run into the problem, that the default Agent Software Deliver Path (e.g. C:\Program Files\Altiris\Altiris Agent\Agents\SoftwareManagement\Software Delivery\{E6F4E4AA-F303-42DC-B2D3-5A881E4ACCD8}\cache) is also much longer as allowed, so the Check-In may work, but the Delivery will fail with the same error (Path too long).
Of course you can just create an Archive with the content, check that into the repository and use a script to expand the archive to a SHORT! path on the client and execute the DISM command afterwards.
2) The second workaround was used for Adobe Creative Cloud. The path were shortened to Numbers like "1,2,3" checked into the Repository and the Iinstallation was done with a script, expanding the directories to the original names on the client. In this case we had to use this, because the size of the Application (>19 GByte) extended the possible size of an self-extracting archive. From the Start, this Application is possible to be checked into the Repository, but the Software Delivery Agent Directory on the client extended the maximum allowed size for a path.
Problem with this Workaround: for the Installation we need double the space on the drive: First the Agent Delivery directory, second the temporary directory where the pathes are created. We create the correct source directories first, then move the files from the agent directory to this temporary directory, and last Installating the Application out of this directory and then finally delete the temporary directory. This is done with a simple VBS.