mapped to UNC path

[Ning_Zhou]

for linked rvts, we have mapped path, and i try to convert to UNC path using API, doesn't work, i used TransmissionData in order to process multiple files.

seems Revit will always use mapped path if there's mapped drive no matter you converted to UNC or not, unless you manually change it, any idea how to make it work? thanks

[Ning_Zhou]

if not for linked rvts, then how about linked DWGs?

[Joe.Ye]

Hi Ning,

I didn't have the environment to test using a mapped drive.

The PathType can be set relative and absolute,  can absolute help?

[Ning_Zhou]

thanks Joe, just tested, change from relative to absolute won't make any difference.

there must be a way to change from mapped to UNC path using API!? not only for linked rvt but also for linked dwg, etc.

[Joe.Ye]

Hi Ning,

A common cause for this issue is mentioned by our engineering team.

Did you call SetIsTransmitted(true) on the TransmissionData object before you called WriteTransmissionData? That’s a common mistake. Revit doesn’t read the TransmissonData stream by default. You have to explicitly tell Revit to read the stream by marking the file as transmitted.

Hope this helps,

[Ning_Zhou]

thanks Joe, yes, i did that already, no luck.

[Anonymous]

This is kind of convoluted and most likely not ideal, but anyway here I go...

If you switch the document into worksharing mode, any linked files will be referenced using the relative path from the "central" file. I think this would get around the mapped paths issue, but it probably creates a billion other issues for you.

I'm not sure if links added before switching to shared will be converted though. If they do then they might be a way of switching to shared, reading the relative path, switching back and then updating the link if required.

If I'm short of something to do tonight I'll look into it further.

[Anonymous · Accepted solution]

Ok, desregard my last silly post, that didn't work. I did however do some testing in Revit 2015 and can see your problem, but it might not be as bad as you think.

I found that setting path type to relative while setting the UNC path in TransmissionData did actually work. If you are testing your results by reading back the TransmissionData again before the project has actually been loaded and saved, the ExternalFileReference.GetAbsolutePath() will still report the the mapped drive while GetPath() will show the UNC as expected. Once the file has been loaded and saved, both paths will report as UNC.

[Ning_Zhou]

is it only work for 2015 Scott? to generalize it, how about linked DWG, etc.?

[Anonymous]

Sorry I didn't try with 2014 or DWG files.

By the way, the main project that was hosting the linked file was also residing on a mapped network drive, I did test the behaviour of loading it through both its mapped and UNC paths. I didn't check for a local project linking a remote one though.

For reference, here's the code I used to test. Maybe there is something I'm doing that's different?

ModelPath projectFilePath = ModelPathUtils.ConvertUserVisiblePathToModelPath(@"Z:\Test\TestProject.rvt");
ModelPath oldLinkPath = ModelPathUtils.ConvertUserVisiblePathToModelPath(@"Z:\Test\Linked.rvt");
ModelPath newLinkPath = ModelPathUtils.ConvertUserVisiblePathToModelPath(@"\\XNAS\Public\Test\Linked.rvt");

TransmissionData transData = TransmissionData.ReadTransmissionData(projectFilePath);										
List<ElementId> linkedIds = transData.GetAllExternalFileReferenceIds().ToList();
				
foreach(ElementId id in linkedIds)
{
    ExternalFileReference extRef = transData.GetDesiredReferenceData(id);						
    ModelPath pathAbs = extRef.GetAbsolutePath();						
						
    if(pathAbs.Compare(oldLinkPath) == 0)
    {
        ElementId linkId = extRef.GetReferencingId();
        transData.SetDesiredReferenceData(linkId, newLinkPath, PathType.Relative, true);
        transData.IsTransmitted = true;
        TransmissionData.WriteTransmissionData(projectFilePath, transData);
    }						
}