I am trying to use the new AppendBlob
This is my code:
CloudAppendBlob appendBlob = container.GetAppendBlobReference("MyDir/MyKey");
if (!appendBlob.Exists())
{
appendBlob.CreateOrReplace();
}
return appendBlob.AppendTextAsync("someText");
If I do DownloadText on the given reference I see the text I put in ("someTextsomeTextsomeTextsomeText").
But if I go to the portal to see the blob I get the error message "Cannot load management data for the current view."
And if i try to use the storage explorer I get "The remote server returned an error: (409) Conflict."
Can anyone explain these errors to me and how to resolve them?
Thanks!
Support for Append Blob is introduced in Storage Service REST API Version 2015-02-21. Storage Client library version 5.0.0 has support for this REST API version.
The reason you're getting this error is most likely because these tools are not updated to make use of latest version of REST API/Storage Client library.
One thing you could do is contact the owners of these tools and ask them to update the code to make use of latest version of REST API/Storage Client library. Azure Storage Explorer is open source so you may want to take the code and update it so that it makes use of the latest library.
If you're looking for other tools, you can either look at Cloud Portam [Disclaimer: I am building this tool] (http://blog.cloudportam.com/announcing-support-for-append-blobs-in-cloud-portam/) or Azure Management Studio. Both of these tools have full support for Append Blobs.
Related
I have a web .net application, it will read an excel file using the Microsoft Access Database Engine. It works fine , but recently it is giving some error. From the log, these 2 points i think are the highlight, which I still could not find a solution. I have tried reinstalling Microsoft Access Database Engine, but not helping. Google for it, but didn't manage to get a hint as well.
One funny thing is whenever it happened, I recycle the app pool on IIS and issue was resolved. But then the issue will come back very quickly. If anyone had come across this, would appreciate any help. Thanks.
The .Net Framework Data Providers require Microsoft Data Access Components(MDAC). Please install Microsoft Data Access Components(MDAC) version 2.6 or later
Retrieving the COM class factory for component with CLSID {2206CDB2-19C1-11D1-89E0-00C04FD7A829} failed due to the following error: 800703fa Illegal operation attempted on a registry key that has been marked for deletion. (Exception from HRESULT: 0x800703FA)
To resolve this problem, please follow official doc to try.
Method 1
Do not log on to the server for interactive sessions by using a service account.
Method 2
Disable the related Windows User Profile Service feature.
For more details, please read this article.
"800703fa Illegal operation attempted on a registry key" error
I've lost the ability to log in to Visual Studio using my work account which is prohibiting me from being able to connect to my Azure Dev Ops repos. I believe the reason is because it's trying to auth me against Azure Gov instead of Azure Comm where my account lives.
When I go to my account options I see the US Azure Gov cloud as registered and when I click "Add" I can see the other Gov clouds; but I don't see the commercial cloud. And when I try to add https://login.microsoftonline.com/ manually, it complains that the server returned a 404. Doing a trace reveals the GET to the metadata endpoint is the culprit. https://login.microsoftonline.com/metadata/endpoints?api-version=1.0
I've checked with other developers and they do have it in their list along with the others I have; they have no issues logging in or connecting to the repos. We're running the same major version of VS 2019 - 16.8.x.
Is there an alternative way to register the comm cloud or get that list to be populated with it?
UPDATE: updated to 16.9.4 without luck.
My google-fu finally kicked in and I found a solution.
Near the bottom of the answer from TianyuSun-MSFT, they suggest:
...you can also close all Visual Studio instances and go to C:\Users[user name]\AppData\Local.IdentityService then rename(or delete) the .IdentityService folder, after that you can restart Visual Studio 2019 and try to log in again.
That worked. But before I did it, I investigated the json configs in there and saw a lot pertaining to older versions I no longer have installed. Perhaps, that was the issue.
Once I restarted and logged in, the commercial cloud was automatically added to the list of Registered Clouds.
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 recently activated the new URL in Azure DevOps, moving from
https://xxx.visualstudio.com/
to
https://dev.azure.com/xxx
Consequently, the address to my NuGet feed also changed:
https://{xxx.pkgs.visualstudio.com/_packaging/feed.xxx.ca/nuget/v3/index.json
to
https://pkgs.dev.azure.com/xxx/_packaging/feed.xxx.ca/nuget/v3/index.json
Everything works except for one thing. Now, I am unable to access my NuGet feed (using Visual Studio, Visual Studio for Mac & Rider). I end up with the following error:
Attempting to gather dependency information for multiple packages with
respect to project 'iOS', targeting 'Xamarin.iOS,Version=v1.0' Unable
to load the service index for source
https://pkgs.dev.azure.com/xxx/_packaging/feed.xxx.ca/nuget/v3/index.json.
If I type the address in a browser, I get the following error:
{"$id":"1","innerException":null,"message":"TF246017: Azure DevOps
Server could not connect to the database. Verify that the instance is
specified correctly, that the server that is hosting the database is
operational, and that network problems are not blocking communication
with the
server.","typeName":"Microsoft.TeamFoundation.Framework.Server.DatabaseConnectionException,
Microsoft.TeamFoundation.Framework.Server","typeKey":"DatabaseConnectionException","errorCode":0,"eventId":3008}
Question
How do I fix it?
Update #1
There is a similar error described in this SO question. I am not using a proxy server.
Update #2
I am not seeing this error message when accessing the index.json:
{"$id":"1","innerException":null,"message":"TF30040: The database is
not correctly configured. Contact your Azure DevOps Server
administrator.","typeName":"Microsoft.TeamFoundation.Framework.Server.AzureClientIPRestrictedException,
Microsoft.TeamFoundation.Framework.Server","typeKey":"AzureClientIPRestrictedException","errorCode":0,"eventId":3007}
I posted the same question developercommunity.visualstudio.com and got it fixed. It was due a problem on Microsoft's side as shown on the dev.azure's status page.
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!