Миграция с локальной среды SharePoint 2013 на SharePoint Online через C# CSOM: получение исторических версий файлов чере ⇐ C#

[Anonymous]

Сценарий:

Я создаю настраиваемый инструмент миграции на C# с использованием клиентской объектной модели SharePoint 2013 (CSOM v15 SDK) для переноса библиотеки документов из локальной фермы SharePoint 2013 в современную среду SharePoint Online.
Требования:

• Перенесите все документы вместе с их полной хронологической историей версий. (например, v1.0, v2.0, v3.0).
• Перенесите все связанные свойства настраиваемых метаданных (значения столбцов), последовательно сопоставленные с каждой итерацией версии.
• Утилита запускается с локального компьютера/рабочей станции миграции, аутентифицированной с помощью учетных данных локальной сети (NTLM/Windows) Аутентификация).

Проблема:
При переносе текущей/последней версии файлов отлично работает с использованием File.OpenBinaryDirect(), загрузка исторических версий постоянно завершается сбоем. При итерации по ListItem.File.Versions FileVersion.Url возвращает относительный путь виртуального макета (например, _vti_history/512/Folder/Document.docx). Независимо от того, какой протокол .NET или архитектура веб-запроса используется, выборка потока байтов этих исторических записей постоянно возвращает HTTP 404 Not Found, 400 Bad Request или ошибки аутентификации/компиляции.

Что мы пробовали (и почему они не удалось):
Подход 1:

Код: Выделить всё

ListItem.Versions

(стандарт CSOM)[/b]

• Результат: Выброс Поле или свойство «Версии» не существует.
• Причина: Обнаружено, что ListItem.Versions является эксклюзивным для облачного SDK v16 и не существует в SharePoint 2013 (v15) Объект ListItem. Мы должны использовать File.Versions.

Подход 2:

Код: Выделить всё

SP.File.OpenBinaryDirect

с _vti_history URL[/b]

• Результат: Выброс Указанный аргумент находится вне диапазона допустимых значений. Имя параметра: serverRelativeUrl.
• Причина: OpenBinaryDirect строго ожидает активный современный путь относительно сервера и полностью отвергает виртуальную структуру URL-адресов _vti_history.

Подход 3: SharePoint 2013 REST API с файлом GUID/идентификатор элемента

Мы попытались настроить таргетинг на прямой поток файлов через конечные точки, такие как:

Код: Выделить всё

{site-url}/_api/web/GetFileById('{guid}')/versions({id})/$value

и {site-url}/_api/web/lists(guid'{list-id}')/items({id})/versions({id})/$value

• Результат: Ошибка: 400 неверный запрос или 404 не найден.
• Причина: Обнаружено, что конечная точка двоичного извлечения /$value в исторических версиях не полностью поддерживалась/отсутствовала в ранних версиях локального механизма REST SharePoint 2013.

Подход 4:

Код: Выделить всё

HttpWebRequest

и HttpClient через современный .NET с учетными данными NTLM[/b]

Мы создали абсолютные URL-адреса к виртуальным конечным точкам _vti_history (например, https://myfarm.com).

• Результат: Последовательно возвращает 404 Not Found или 401 Несанкционировано.
• Причина: Конвейер IIS или обработчик аутентификации удаляет контекст аутентификации Windows/NTLM, когда консоль внешнего клиента напрямую сопоставляется с изолированными внутренними системными папками SharePoint, такими как _vti_history. Мы также столкнулись с исключениями компиляции платформы при попытке использовать устаревшие перехватчики, такие как UnsafeAuthenticatedConnectionSharing, поскольку наше консольное приложение работает в современной среде .NET, где WebRequestHandler устарел.

Текущие блокировщики/ограничения:

• Исходные файловые системы содержат специальные пути символы, расширения файлов для конкретных приложений (например, .aspx, эталонные шаблоны макетов) и глубокие структуры папок.
• Стороннее программное обеспечение для миграции или официальный инструмент Microsoft SPMT нельзя использовать из-за ограничений внутренней инфраструктуры и политик управления данными. Мы должны достичь этого с помощью специального решения C#.

Вопрос:
Как внешнее приложение C# может безопасно аутентифицировать и извлечь необработанный двоичный поток исторических версий документов из локальной среды SharePoint 2013 с помощью CSOM SDK v15 или стандартных веб-конечных точек, не сталкиваясь с барьерами виртуальной папки 404 Not Found? Существует ли устаревшая конфигурация веб-службы SOAP (

Код: Выделить всё

lists.asmx

) или альтернативный поставщик потоков, который изначально поддерживает эту настройку?
Любые примеры кода, рекомендации или указатель на отсутствующие зависимости будут высоко оценены.