System.MethodAccessException at CloudTable.CreateIfNotExists RRS feed

  • Question

  • User-1026144913 posted

    We have an application, Webforms site, which talks to Azure Table storage. A few months ago, the original table storage libraries were upgraded to use the newer Microsoft.Azure.CosmosDB.Table , all was well. Last week, in NuGet package manager we saw the following: 

    "NOTE: This .NET Framework library is in maintenance mode and it will be deprecated soon. Please upgrade to the new .NET Standard library (https://www.nuget.org/packages/Microsoft.Azure.Cosmos.Table) to continue to get the latest features supported."

    We obediently changed the package to use Microsoft.Azure.Cosmos.Table, various other libraries were also upgraded by nuget. it all compiles, but when it runs, on CloudTable.CreateIfNotExists it throws the following exception:

      Message=Attempt by method 'Microsoft.Azure.Cosmos.Table.Logger.LogInformational(Microsoft.Azure.Cosmos.Table.OperationContext, System.String, System.Object[])' to access method 'Microsoft.Azure.Documents.DefaultTrace.TraceInformation(System.String)' failed.

    Tried to revert to Microsoft.Azure.CosmosDB.Table, but it cant find a suitable version of Microsoft.Azure.Storage.Common

    Any suggestions before we undo the "upgrade" in source control and go back to a soon-to-be-deprecated library?

    Thursday, July 11, 2019 11:36 AM

All replies

  • User-1026144913 posted

    It gets more "interesting". Created a new empty webforms project, tried to add the nuget package Microsoft.Azure.CosmosDB.Tables - it failed with the message below:

    Attempting to resolve dependencies for package 'Microsoft.Azure.CosmosDB.Table.2.1.1' with DependencyBehavior 'Lowest'
    Unable to find a version of 'Microsoft.Azure.Storage.Common' that is compatible with 'Microsoft.Azure.CosmosDB.Table 2.1.1 constraint: Microsoft.Azure.Storage.Common (>= 8.6.0-preview && <='.

    Sure enough, if I try to add a nuget package for Microsoft.Azure.Storage.Common the lowest version nuGet offers is 9.4

    So we cant go back, and unless we can resolve this CAS issue, we cant go forward.

    Rocks & Hard Places.

    Thursday, July 11, 2019 2:19 PM
  • User-1026144913 posted

    More exploration: Microsoft.Azure.CosmosDB.Tables is / was  a .Net 4.6 library. Microsoft.Azure.Cosmos.Tables is .Net Standard.

    The unit test project doesn't throw the exception, its only seen when running the WebForms app.

    I also created a console App, no sign of the exception there either. 

    I experimented with adding a SecuritySafeCriticalAttribute to the class that calls CloudTable.CreateIfNotExists, but apparently its not allowed if your class has async methods.

    I created a .NetStandard library to call the azure methods, but System.ComponentModel.DataAnnotations doesn't exist in .NetStandard - instead I have to link to System.ComponentModel.Annotations, That resolves some of the annotations, but not MetadataTypeAttribute - that has not been added to .NetStandard.

    Counting to 10...

    Thursday, July 11, 2019 4:57 PM
  • User753101303 posted


    What if you try again with a new 4.7.2 Web Forms project ? I've seen a note once that suggest using at least this version when using .NET Standard 2.0.

    Thursday, July 11, 2019 5:32 PM
  • User283571144 posted

    Hi Bedford,

    According to your description, I couldn't understand your question clearly.

    Do you mean you want to use Microsoft.Azure.Cosmos.Table to create Azure storage table not azure cosmosdb table API?

    I have installed the Microsoft.Azure.Cosmos.Table nuget package in asp.net web form 4.7.1 and run a create table test(for cosmosdb), it works well. My installed version as below:


    Best Regards,


    Friday, July 12, 2019 2:42 AM
  • User-1026144913 posted

    Thanks for the contributions. 

    To be clear, this was an existing webforms app, it has been running since maybe 2014, using the original azure table storage APIs to talk to Azure table storage (this was before Cosmos DB)

    As I said, a few months ago there was a deprecation message for the table storage api, it was upgraded to use the Microsoft.Azure.CosmosDB.Tables library ( a .Net library) - which could talk to both Azure Tables and Cosmos DB - and again it was running fine. Then there was a message that it would be deprecated "soon" and we should "upgrade" to Microsoft.Azure.Cosmos.Tables (a .Net Standard library). That is when the fun started.

    To PatriceSc : yes the original WebForms project is on 4.7.2 and I created a new empty, minimal WebForms project, as described above, which fails. I also created a console app, it created the table in Azure Table storage.

    To Brando ZWZ: thank you for taking the time to test this, have you tried connecting to Azure table storage, rather than Cosmos DB?

    The fact that it works for unit test and console suggests some kind of code access permission issue, the message indicates its trying to write a diagnostic note, and failing. I have tried adding a diagnostic listener, no help.

    Friday, July 12, 2019 9:49 AM
  • User-279353403 posted

    I was getting this exception in various projects (WebApp, worker roles) when trying to execute table storage queries.


    Microsoft.Azure.Cosmos.Table.Logger.LogInformational(Microsoft.Azure.Cosmos.Table.OperationContext, System.String, System.Object[])' to access method 'Microsoft.Azure.Documents.DefaultTrace.TraceInformation(System.String)' failed.

    I was able to fix by downgrading only Microsoft.Azure.DocumentDB.Core from 2.5.1 to prior version 2.4.2. All other nuget packages were kept at latest versions. I was not able to downgrade with Visual studio GUI and kept getting error "Found invalid data while decoding." I ended up updating the project files / packages.config by hand (only changing 2.5.1 to 2.4.2). Hope this helps.

    Monday, July 15, 2019 2:31 AM
  • User-279353403 posted

    Also make sure to update any binding redirects in app/web configs. Found easiest to remove entire <runtime> section from configs -> rebuild -> double click on warnings generated by VS to let it regen <runtime>.

    Monday, July 15, 2019 2:35 AM
  • User-1026144913 posted

    Thanks, that's a horrible workaround, I've escalated it to Microsoft, we'll see if anyone is listening...

    Monday, July 15, 2019 9:41 AM