The upgrade to version 10 also incorporates the 2.0.0-rc1 breaking changes. That has the comments about removing the middleware.
The comment about the extra slash in the 10.0.0-rc1 notes screwed me up a little. If you are using the CDN url setting you need to make sure the configured value ends with a slash and all your references to the configuration are updated to the correct new name (This might not be an issue for you, but I had some custom property editors that needed to know about the cdn url).
After I updated it servers my files from the container, but it ignores the ImageSharp processing. It seems like it processes the images because the first time when I change the parameters it takes longer to respond on large images, but it still returns the unaltered file. On v9 it worked as intended.
I tried exactly this just now, and it seems to work for me. Upgraded from 9.5.2 to 10.0.1 (and all related packages to the latest versions). Removing UseAzureBlobMediaFileSystem() was the only code change.
AddAzureBlobMediaFileSystem() is enabled in development as well, but not the media URL CDN provider (not sure if it's possible to use that in development in an easy way).
Is it safe to use the Azure Blob Media File System concurrently on v10 and v9 during upgrading and testing?
Do you mean using the same Azure Storage container for the v9 and v10 applications? The structure is exactly the same (media folder in the container root, subfolders named as media IDs, file(s) in subfolders) so I'd say yes. Not sure why you'd want to though, I'd just copy the v9 container to a v10 container.
Azure BLOb Storage File System Provider upgrade 9 to 10
In 9, to add the Azure BLOb Storage File System Provider, you did:
AddAzureBlobMediaFileSystem(to configure)UseAzureBlobMediaFileSystem(to enable)In 10, it seems
UseAzureBlobMediaFileSystemis missing, and the documentation only mentionsAddAzureBlobMediaFileSystem.Is the upgrade procedure to simply remove
UseAzureBlobMediaFileSystem?Yeah, the details you need are here
https://github.com/umbraco/Umbraco.StorageProviders/releases
The upgrade to version 10 also incorporates the 2.0.0-rc1 breaking changes. That has the comments about removing the middleware.
The comment about the extra slash in the 10.0.0-rc1 notes screwed me up a little. If you are using the CDN url setting you need to make sure the configured value ends with a slash and all your references to the configuration are updated to the correct new name (This might not be an issue for you, but I had some custom property editors that needed to know about the cdn url).
Updating the development and test site to v10, but live will stay on v9 until we've tested everything.
Is it safe to use the Azure Blob Media File System concurrently on v10 and v9 during upgrading and testing?
After I updated it servers my files from the container, but it ignores the ImageSharp processing. It seems like it processes the images because the first time when I change the parameters it takes longer to respond on large images, but it still returns the unaltered file. On v9 it worked as intended.
What changes did you make to upgrade? Update NuGet, what else?
I removed UseAzureBlobMediaFileSystem() since it's no longer exists and that's about it.
I tried exactly this just now, and it seems to work for me. Upgraded from 9.5.2 to 10.0.1 (and all related packages to the latest versions). Removing
UseAzureBlobMediaFileSystem()was the only code change.If I take a media URL such as
https://localhost:44319/media/<id>/image.jpg?quality=1and manipulate thequalityparameter, the image changes.AddAzureBlobMediaFileSystem()is enabled in development as well, but not the media URL CDN provider (not sure if it's possible to use that in development in an easy way).Do you mean using the same Azure Storage container for the v9 and v10 applications? The structure is exactly the same (
mediafolder in the container root, subfolders named as media IDs, file(s) in subfolders) so I'd say yes. Not sure why you'd want to though, I'd just copy the v9 container to a v10 container.is working on a reply...