Migrating to ArconQ 1.3.0

ArconQ 1.3.0 is a largely additive release: it overhauls the File Storage page in the UI and introduces the new ArconQ Management SDK. Neither of those requires any migration.

It also reworks the File Storage SDK, and that change is breaking for apps that use it.

Breaking change

The File Storage SDK API has changed. The IFileStorageBus interface, the FileEntry class and the FileEntryType enum have been removed and replaced by IFileStorage and IBlobStorage. Apps that use the old API will not compile until they are updated.

This is a code-level change only — the files already in your storage are not affected, and there is nothing to migrate in your ArconQ instance itself.

What is affected

Only application code that used IFileStorageBus needs changes. If your apps don't use the File Storage SDK, no action is required. The stored files, the File Storage page, and the rest of the platform are unaffected.

Updating the File Storage SDK

After updating the ArconQ SDK package in your app, replace the old File Storage API with the new one. For the full new API see the File Storage reference.

1. Replace the injected interface

Inject IFileStorage instead of IFileStorageBus. It is registered automatically by AddArconQ(...), so no registration changes are needed.

// Before
public MyService(IFileStorageBus fileStorageBus) { ... }

// After
public MyService(IFileStorage fileStorage) { ... }

2. Update the method calls

The methods were renamed and made explicit about files versus folders. Map your calls as follows:

Before (IFileStorageBus)	After (IFileStorage)
UploadAsync(localPath, fileStoragePath)	UploadFileAsync(localFilePath, remoteFilePath)
UploadAsync(stream, fileStoragePath)	UploadFileAsync(stream, remoteFilePath)
DownloadAsync(localPath, fileStoragePath)	DownloadFileAsync(remoteFilePath, localFilePath)
DownloadAsync(fileStoragePath) → Stream	DownloadFileAsync(remoteFilePath) → Stream
ListFilesAsync(fileStoragePath) → List<FileEntry>	ListFilesAsync(remoteDirectoryPath) → List<FileResponse>
deleting a file	DeleteFileAsync(remoteFilePath)

Argument order changed for downloads

For the download-to-local overload the parameter order is reversed: it is now DownloadFileAsync(remoteFilePath, localFilePath) — remote source first, local destination second. The upload overloads keep the local-then-remote order.

Every new method also accepts an optional trailing CancellationToken.

3. Update result types

ListFilesAsync now returns FileResponse records instead of FileEntry objects:

FileEntry (removed)	FileResponse
FullPath	Path
ModifiedOn	LastModifiedOn
CreatedOn	(removed)
FileEntryType (enum)	(removed)
—	Size (file size in bytes)

Note two behavioral changes:

• ListFilesAsync now returns files only and lists them recursively, including files in nested folders. It no longer returns folder entries, so code that inspected FileEntryType to tell files and folders apart is no longer needed.
• Remote paths are now validated. Paths must be relative to the storage root, use / as the separator, and avoid characters and names that aren't portable across operating systems — see Remote paths. Invalid paths throw an ArgumentException.

4. New capabilities (optional)

The rework also adds folder-level and copy operations you can adopt where useful: UploadDirectoryAsync, DownloadDirectoryAsync, DeleteDirectoryAsync and CopyFileAsync. For raw, key-based access there is also the lower-level IBlobStorage — see Advanced: blob-level access.