I'm trying to get a container reference using an instance of the CloudBlobClient. In the emulator, everything works properly but if I deploy to azure, the second line of:
CloudBlobClient blobClient = storageAccount.CreateCloudBlobClient();
blobClient.GetContainerReference("drives").CreateIfNotExist();
fails with an IOException and says "The specified registry key does not exist". What could be causing this?
I actually figured out what was going wrong. THe IOException is commonly generated by the HTTPWebRequest Class which made me think that since the .Net libraries are only API wrappers, some erroneous calls were being made. I was using the Cloud Drive so I had a reference to Microsoft.WindowsAzure.StorageClient which is API version 1.7 and Microsoft.WindowsAzure.Storage which is version 2.0. The two of these were interfering with each other. Because I needed to keep Cloud Drive capabilities, I removed the Storage Class and everything worked.
Related
I'm running an Azure function in Azure, the function gets triggered by a file being uploaded to blob storage container. The function detects the new blob (file) but then outputs the following message - Did not find any initialized language workers.
Setup:
Azure function using Python 3.6.8
Running on linux machine
Built and deployed using azure devops (for ci/cd capability)
Blob Trigger Function
I have run the code locally using the same blob storage container, the same configuration values and the local instance of the azure function works as expected.
The functions core purpose is to read in the .xml file uploaded into blob storage container and parse and transform the data in the xml to be stored as Json in cosmos db.
I expect the process to complete like on my local instance with my documents in cosmos db, but it looks like the function doesn't actually get to process anything due to the following error:
Did not find any initialized language workers
Troy Witthoeft's answer was almost certainly the right one at the time the question was asked, but this error message is very general. I've had this error recently on runtime 3.0.14287.0. I saw the error on many attempted invocations over about 1 hour, but before and after that everything worked fine with no intervention.
I worked with an Azure support engineer who gave some pointers that could be generally useful:
Python versions: if you have function runtime version ~3 set under the Configuration blade, then the platform may choose any of python versions 3.6, 3.7, or 3.8 to run your code. So you should test your code against all three of these versions. Or, as per that link's suggestion, create the function app using the --runtime-version switch to specify a specific python version.
Consumption plans: this error may be related to a consumption-priced app having idled off and taking a little longer to warm back up again. This depends, of course, on the usage pattern of the app. (I infer (but the Engineer didn't say this) that perhaps if the Azure datacenter my app is in happens to be quite busy when my app wants to restart, it might just have to wait for some resources to become available.). You could address this either by paying for an always-on function app, or by rigging some kind of heartbeat process to stop the app idling for too long. (Easiest with a HTTP trigger: probably just ping it?)
The Engineer was able to see a lower-level error message generated by the Azure platform, that wasn't available to me in Application Insights: ARM authentication token validation failed. This was raised in Microsoft.Azure.WebJobs.Script.WebHost.Security.Authentication.ArmAuthenticationHandler.HandleAuthenticate() at /src/azure-functions-host/src/WebJobs.Script.WebHost/Security/Authentication/Arm/ArmAuthenticationHandler.cs. There was a long stack trace with innermost exception being: System.Security.Cryptography.CryptographicException : Padding is invalid and cannot be removed.. Neither of us were able to make complete sense of this and I'm not clear whether the responsibility for this error lies within the HandleAuthenticate() call, or outside (invalid input token from... where?).
The last of these points may be some obscure bug within the Azure Functions Host codebase, or some other platform problem, or totally misleading and unrelated.
Same error but different technology, environment, and root cause.
Technology Net 5, target system windows. In my case, I was using dependency injection to add a few services, I was getting one parameter from the environment variables inside the .ConfigureServices() section, but when I deployed I forget to add the variable to the application settings in azure, because of that I was getting this weird error.
This is due to SDK version, I would suggest to deploy fresh function App in Azure and deploy your code there. 2 things to check :
Make sure your local function app SDK version matches with Azure function app.
Check python version both side.
This error is most likely github issue #4384. This bug was identified, and a fix was released mid-june 2020. Apps running on version 3.0.14063 or greater should be fine. List of versions is here.
You can use azure application insights to check your version. KUSTO Query the logs. The exception table, azure SDK column has your version.
If you are on the dedicated App Service plan, you may be able to "pull" the latest version from Microsoft by deleting and redeploying your app. If you are on consumption plan, then you may need to wait for this bugfix to rollout to all servers.
Took me a while to find the cause as well, but it was related to me installing a version of protobuf explicitly which conflicted with what was used by Azure Functions. Fair, there was a warning about that in the docs. How I found it: went to <your app name>.scm.azurewebsites.net/api/logstream and looked for any errors I could find.
I am trying to access a data storage of the azure stack. The following instructions work:
BlobClient = StorageAccount.CreateCloudBlobClient();
CloudBlobContainer myContainer = BlobClient.GetContainerReference("mycontainer");
But it crashes, when creating the Blob via myContainer.CreateIfNotExists():
...StatusMessage:The value for one of the HTTP headers is not in
the correct format.\r\n ErrorCode:\r\nErrorMessage:The value for one
of the HTTP headers is not in the correct format.\n
RequestId:"hiddenId"...
The behavior is exactly the same for Queues and Tables.
I tried the "Microsoft.WindowsAzure.Storage" library in its older version 7.2.1, version 8.7 and the current version 9.1. (8.7 should be fine regarding this documentation. Another documentation even sais, that every version between 6.2.0 and 8.7.0 should be compatible. 9.1 is not supported for sure.) In the end it is always the above error.
The code runs fine when targeting public Azure storages instead Azure Stack storages.
So I finally found out the solution with kind support of Microsoft.
It was indeed a versioning problem, one can find out when understanding this documentation the right way.
I am using Azure Stack version 1.0.180103.2. This is the internal version number an means it has been created on the 3rd of January 2018. This refers to version 1801, in the versioning scheme used within the documentation.
The API version 8.7 is only valid from 1802 on. So I have to look at the bottom of that documentation page under "previous". And there one can see that I have to go back to "Microsoft.WindowsAzure.Storage" library 6.2. Using this library it works.
This error could be a result if BlobRequestOptions and OperationContext have not been set, Could you provide values to both then check again? The documentation can be found here: https://learn.microsoft.com/en-us/dotnet/api/microsoft.windowsazure.storage.blob.cloudblobcontainer.createifnotexists?redirectedfrom=MSDN&view=azure-dotnet#overloads
I am developing an Azure website, and I want to make use of Blob storage. I am using VS2013, Azure SDK 2.2. I have tried Azure Storage 2.1.0.4 from NuGet, I have tried using the latest 3.0.2.0 too. I have upgraded the emulator to the latest preview version 2.2.1, I was using 2.2.0 before.
My issue is, it doesnt matter if I point at the emulator or real storage, I get Bad Request 400 errors (invalid headers).
I set up a really simple form application, with a single button to make this easy.
private void button1_Click(object sender, EventArgs e)
{
var account = CloudStorageAccount.Parse(CloudConfigurationManager.GetSetting("StorageConnectionString"));
CloudBlobClient blobClient = account.CreateCloudBlobClient();
CloudBlobContainer container = blobClient.GetContainerReference("UserImages");
if (!container.Exists())
{
container.Create();
container.SetPermissions(new BlobContainerPermissions { PublicAccess = BlobContainerPublicAccessType.Off });
}
}
Everything looks good until container.Exists() executes, and then I get an unhandled error (Bad Request 400). I have tried a few different operations and I get the same unhelpful message every time.
I am storing the Azure Connection string in the appSettings section, and in this simple example I have tried pointing at a real Storage Account, and the emulator, and I get the 400 error every time.
My config file has this:
<appSettings>
<add key="StorageConnectionString" value="DefaultEndpointsProtocol=https;AccountName=[MyAccountName];AccountKey=[MYREALKEY]" />
</appSettings>
Using the Server Explorer in VS2013, I can happily connect to both the Emulator and real storage, and access Blob storage without issue.
This is effectively stopping me adding the ability to my site to upload files to the storage account.
Anyone else having this problem? As far as I know, I have tried older versions and the latest versions of the important components. I have always had SDK 2.2 though.
Any suggestions gratefully received.
For information, I followed this example, which I found in the Azure management portal:
http://www.windowsazure.com/en-us/documentation/articles/storage-dotnet-how-to-use-blobs-20/
Thanks
Ian
To see naming rules, please check out this link: http://msdn.microsoft.com/en-us/library/windowsazure/dd135715.aspx. From this documentation page:
A container name must be a valid DNS name, conforming to the following
naming rules:
Container names must start with a letter or number, and can contain only letters, numbers, and the dash (-) character.
Every dash (-) character must be immediately preceded and followed by a letter or number; consecutive dashes are not permitted in
container names.
All letters in a container name must be lowercase.
Container names must be from 3 through 63 characters long.
Regarding getting 400 error with storage emulator, please check the storage client library version. If it's 3.x, then you would need to install storage emulator 2.2.1 released in preview today. More information about this can be found here: http://blogs.msdn.com/b/windowsazurestorage/archive/2014/01/16/windows-azure-storage-emulator-2-2-1-preview-release-with-support-for-2013-08-15-version.aspx
This drove me insane for two days. Installing/Uninstalling the SDK, emulators, Azure Storage NuGet packages etc. I finally got the emulator working as well as real storage. The MSI you download to install the preview version of the emulator 2.2.1 contains a readme - I didnt know it was there, but it contains some pretty important instructions!
3. Copy all files from the following path:
For 32-bit OS: "%ProgramFiles%\Windows Azure Storage Emulator 2.2.1\devstore"
For 64-bit OS: "%ProgramFiles(x86)%\Windows Azure Storage Emulator 2.2.1\devstore"
to the following path:
"%ProgramFiles%\Microsoft SDKs\Windows Azure\Emulator\devstore"
If prompted, choose to replace the existing files with the new ones.
It turns out the MSI doesnt update the files actually used by the emulator at run time! You have to perform this task by hand. I feel sooo stupid for not seeing this basic instruction. Turns out RTFM was the answer!
I just updated via nuGet to the latest Azure dll's (Id: Microsoft.WindowsAzure.Caching version 2.0.0.0, runtime version v4). That allowed me to configure a shared cache for my roles.
The problem is when I try to access to the AppFabric Memcache programmatically (another cache, not related to the session).
var servers = new List<DataCacheServerEndpoint>();
servers.Add(new DataCacheServerEndpoint(_hostname, _cacheport));
var conf = new DataCacheFactoryConfiguration();
conf.SecurityProperties = new DataCacheSecurity(secure(_authinfo));
var dataCacheFactory = new DataCacheFactory(conf);
_dataCache = dataCacheFactory.GetDefaultCache();
The code compiles fine but throws a runtime error:
Method not found: 'Void Microsoft.ApplicationServer.Caching.DataCacheSecurity..ctor(System.Security.SecureString)'.
If I take this code and I put the dll's to runtime version 2 works like a champ.
Any idea what should I change in order to make it work?
Edit:
Looks like the old constructor for DataCacheSecurity doesn't allow the secure token any more
http://msdn.microsoft.com/en-us/library/microsoft.applicationserver.caching.datacachesecurity.datacachesecurity(v=ws.10).aspx
Now I just have 2 constructors and looks impossible to specify the auth key
Edit2:
I reached Microsoft and they told me:
“Windows Azure Caching and Windows Azure Shared Caching share the same API, and although the assembly names are the same, the assemblies themselves are different and are in different locations. The Caching NuGet package will remove the Shared Caching assembly references and add the correct Caching assembly references. The Caching assemblies are located in the C:\Program Files\Microsoft SDKs\Windows Azure.NET SDK\2012-10\ref\Caching folder.”
conclusion: it is not possible at the moment.
At this time, the new Azure cache .DLL's (v2) are not compatible with previous versions. You will want to choose one version and make sure that all of your providers comply with it. Obviously, the Dedicated cache needs v2.0 of DataCache DLLs.
you would think this would be easy since Azure Appfabric is supposedly part of Azure.
Firstly Microsoft.ServiceBus.dll isnt on the VM; fixed that
Now the tcprelay bind fail: the binding type is unknown. So I called
RelayConfigurationInstaller.AddRelayConfiguration(config);
In Application_Start
Nope, same error. So I copied relayconfigurationinstaller.exe to the VM, ran it using RDP.
Nope, same error.
Any ideas?
EDIT: This is the error I am talking about
ConfigurationErrorsException: Configuration binding extension 'system.serviceModel/bindings/netTcpRelayBinding' could not be found. Verify that this binding extension is properly registered in system.serviceModel/extensions/bindingExtensions and that it is spelled correctly.]
answer: http://www.wadewegner.com/2010/05/net-framework-4-0-and-the-azure-appfabric-sdk/
the installers set the v2 clr config files; I am using v4 clr.
EDIT: well that binary works now but the API calls still dont work. (which is the preferred way of doing things)
Not pretty sure if this helps, but you need to add the AppFabric WCF extensions on your machine.config or yor app.config.