I would like to use RedisTimeSeries module (latest feature) in Redis from .net core client in Azure.
I created Azure Cache for Redis (from RedisLabs) (https://azure.microsoft.com/en-us/services/cache/) standard resource in the Azure portal.
Downloaded the .net redis samples code from https://github.com/rustd/RedisSamples.
When I compiled samples code, it downloaded the nuget package called StackExchange.Redis (among other libraries).
Played with samples to understand how redis works from .net client.
It appears that raw REDIS commands where wrapped by StackExchange.Redis library.
Next, I wanted to play with RedisTimeSeries (as described at https://github.com/RedisTimeSeries/RedisTimeSeries).
The StackExchange.Redis .net library does not seem to provide any API to invoke RedisTimeSeries module related commands such as TS.CREATE, TS.ADD etc.
Here are my questions:
Is RedisTimeSeries module supported in Azure Cache for Redis (from RedisLabs)?
If supported, how do I invoke TS related commands from my .net core client?
If not supported, is there any other .net library that lets me do this?
Is RedisTimeSeries module supported in Azure Cache for Redis (from RedisLabs)?
Azure Cache for Redis, is not from RedisLabs but from MS, the only Redis vendor who currently supports Modules deployments is RedisLabs Cloud Pro (see: https://redislabs.com/redis-enterprise/deployments/ and https://redislabs.com/partner/microsoft/)
If supported, how do I invoke TS related commands from my .net core client?
DbSync.Execute("MyCommand", args)
It is coming soon on Azure Redis, see redis enterprise features on azure cache for redis coming soon
Enterprise tier will support RedisTimeSeries
RedisTimeSeries has been GA in Azure Cache for Redis, Enterprise Tier, since March 2021.
NRedisTimeSeries the recommended .Net client for RedisTimeSeries
Related
I have been using QueueClient to handle all functionality with the Storage Queue. I noticed in a few examples online that there is a CloudQueue, that has several more methods.
What is the difference between the two? Why would you use one over the other?
EDIT: I am using both Microsoft.Azure.Storage.Queue and Azure.Storage.Queues
Azure Storage client libraries for .NET - Azure for .NET Developers | Microsoft Docs
Azure.Storage.Queues are the v12 version of the SDK, Microsoft.Azure.Storage.Queue is the v11 version. . .
Typically we recommend using the latest version of the SDK, and typically only one version of the SDK per application.
I'm trying to use client side encryption for azure to securely upload files to blob storage in .NET,
However it seems that BlobEncryptionPolicy is not available and I have not seen any documentation specifying alternative solutions from microsoft.
Even their documentation still uses BlobEncryptionPolicy:
Client-Side Encryption and Azure Key Vault for Microsoft Azure Storage
Specifically i'm inside of a xamarin project using the latest .net version.
If i create a sample console app, I can reference BlobEncryptionPolicy without any issues. However the same nuget package inside a xamarin shared project can not resolve the reference to BlobEncryptionPolicy under the Microsoft.WindowsAzure.Storage.Blob namespace.
Does anyone know what is going on here?
There are some differences between Microsoft.WindowsAzure.Storage package depending on .net core and the one depending on .net framework.
You may have developed your Xamarin project based on .net core, where BlobEncryptionPolicy is not supported(this method doesn't exist in the dll).
As when you create a console app(.net framework), you can use the encryption. If you build a console app(.net core), you will find no such method as well.
An open issue on github about this, saying the encryption for .net core is coming soon.
You can change your targetframework to use it if .net core is not necessary for your development.
UPDATE: DNX does not exist anymore. Please ignore this question.
Current WindowsAzure.ServiceBus (3.0.4) nuget package (http://nuget-preprod-0-v2gallery.cloudapp.net/packages/WindowsAzure.ServiceBus/) requires .NET Framework 4.5 Full Profile and it is not usable with an application build specifically to use DNX Core.
As I understand, the only way to build such application at this moment is to use REST API.
What is the recommended way to include authentication information to requests? Do we have any open source nuget to handle it or should the SAS token creation be implemented by each developer? Links to the REST API authentication samples are broken.
While the Service Bus nuget package is not open sourced, do we have any active channels to reach the developers to find out if they have any plans to support DNX Core and we should not use REST API because the library update is coming soon?
The REST URL to publish a message on Queue/Topic will be like,
http{s}://{serviceNamespace}.servicebus.windows.net/{queuePath|topicPath}/messages
The authorization SAS Token has to be part of the request header
For further read, REST Run-Time APIs
It's also possible by using the AMQP protocol. I recently used AMQP to communicate with an Azure IoTHubClient, all in a DNXCore5.0 project. I used the AMQPNetLite Library to do so, it also has Service Bus Examples!
(Reposting as my prior answer was erroneously deleted by the moderators.)
Microsoft now provides a .NET core version of this library. I am shipping a .NET Core app on Linux that calls it.
https://github.com/azure/azure-service-bus-dotnet
Announcement post:
https://blogs.msdn.microsoft.com/servicebus/2016/12/20/service-bus-net-standard-and-open-source/
As a Microsoft Azure services client, I received earlier today the following mail: http://aka.ms/Qga48e.
I was wondering how I could migrate my Blob storage without services disruption to use the latest Azure File Storage service.
Anybody has already performed this action? Any feedbacks will be welcomed.
Thanks.
I don't think that it would be necessary. Besides Azure Blob Service and Azure File Service serve different purposes all together and the things you could do with blob service can't be done through file service.
As mentioned in the newsletter, what you should try to do is upgrade your client applications to make use of latest version of storage client library. If you're using an older version of library (< 2.0), there would be some pain in migration but migrating from 2.0 to 4.x (currently latest version) should be rather painless.
Next thing you should look into is the default service version of your storage account services. If you're using .Net storage client library, you can fetch it via GetServicePropertiesAsync method. You can update the default service version using SetServicePropertiesAsync method.
You may also find this link helpful about understanding storage service versioning: http://msdn.microsoft.com/en-us/library/azure/dd894041.aspx.
UPDATE: 13-DEC-2014
Azure Storage Team has published a blog post which talks more about this issue: http://blogs.msdn.com/b/windowsazurestorage/archive/2014/08/05/microsoft-azure-storage-service-version-removal.aspx.
The Storage Service REST API is not being removed. There are several versions of the API, from over the years. Older versions of the REST API (prior to the 2012-02-12 version) are being retired. But it's definitely not going away, and neither is the Azure Storage service.
Different versions of the SDKs (across the various language stacks) and command-line tools (PowerShell, CLI) may be using one of the older versions. If you're using the current versions of SDKs and command-line tools, this has no effect on you.
Consider how many versions there have been (all tracked here, and all listed in the page you linked to in your answer:
2014-02-14 (current)
2013-08-15
2012-02-12
2011-08-18
2009-09-19
2009-07-17
2009-04-14
If you're using an older version of an SDK or command-line tool, there's a chance that, in Dec. 2015, it won't work as expected anymore, as the underlying version will have been retired. So, essentially you have until December 2015 to update your Azure projects if needed.
I wanted to follow the guidance of “Windows Azure Storage and CORS” but I notice that my version of the Windows Azure SDK (2.1) does not have the members (like ServiceProperties .Cors) used in the article. I also notice that the documented members of ServiceProperties do not include Cors. Was this stuffed removed from the codebase or is this stuff so new that it is not documented yet? Is this CORS stuff in a future version of the SDK? Or do I have to use the REST API?
Storage Client Library (version 2.x) which comes with SDK 2.1 does not have support for CORS. It is supported in Storage Client Library version 3.x. So if you want to manage CORS settings, you would need to use that library. You can download this library through Nuget: http://www.nuget.org/packages/WindowsAzure.Storage. You could always use REST API if you want to.
However, please keep in mind that SDK 2.1 is not compatible with version 3.x of storage client library. What that means is that if you use 3.x version of storage client library in your project you won't be able to use storage emulator. You would always need to connect to cloud storage account for development.
Windows Azure Blobs, Tables and Queues now support CORS to enable users to access/manipulate resources from within the browser serving a web page in a different domain than the resource being accessed.
http://msdn.microsoft.com/en-us/library/windowsazure/dn535601.aspx