FS0039 on build but intellisense shows type as available

[stewart-r]

As mentioned in this stack overflow question.

If we try to use a type under .Domain before retrieving records then we hit the above error on build even although Visual Studio editor reports no error or 'red squiggly'.

For example if we set up a test table in development storage like this:

Then try to access the FlintstoneEntity type like this:

namespace ErrorDemo
open FSharp.Azure.StorageTypeProvider
type Azure = AzureTypeProvider<"UseDevelopmentStorage=true">

module MyModule = 
    type Flintstone = Azure.Domain.FlintstonesEntity

Visual Studio reports no errors until we try to build at which point we get the error message noted below.

If, however, we make an attempt to access the table first, for example by adding this line:

let x = Azure.Tables.Flintstones.GetPartition("")

before we try to access the Azure.Domain.FlintstonesEntity type then everything builds and works as expected.

1>------ Build started: Project: ErrorDemo, Configuration: Debug Any CPU ------ 1> C:\Program Files (x86)\Microsoft SDKs\F#\4.0\Framework\v4.0\fsc.exe -o:obj\Debug\ErrorDemo.dll -g --debug:full --noframework --define:DEBUG --define:TRACE --doc:bin\Debug\ErrorDemo.XML --optimize- --tailcalls- -r:"C:\Users\stewa_000\Documents\Visual Studio 2015\Projects\ErrorDemo\packages\FSharp.Azure.StorageTypeProvider.1.4.1\lib\net40\FSharp.Azure.StorageTypeProvider.dll" -r:"C:\Program Files (x86)\Reference Assemblies\Microsoft\FSharp.NETFramework\v4.0\4.4.0.0\FSharp.Core.dll" -r:"C:\Users\stewa_000\Documents\Visual Studio 2015\Projects\ErrorDemo\packages\Microsoft.Azure.KeyVault.Core.1.0.0\lib\net40\Microsoft.Azure.KeyVault.Core.dll" -r:"C:\Users\stewa_000\Documents\Visual Studio 2015\Projects\ErrorDemo\packages\Microsoft.Data.Edm.5.6.4\lib\net40\Microsoft.Data.Edm.dll" -r:"C:\Users\stewa_000\Documents\Visual Studio 2015\Projects\ErrorDemo\packages\Microsoft.Data.OData.5.6.4\lib\net40\Microsoft.Data.OData.dll" -r:"C:\Users\stewa_000\Documents\Visual Studio 2015\Projects\ErrorDemo\packages\Microsoft.Data.Services.Client.5.6.4\lib\net40\Microsoft.Data.Services.Client.dll" -r:"C:\Users\stewa_000\Documents\Visual Studio 2015\Projects\ErrorDemo\packages\WindowsAzure.Storage.6.0.0\lib\net40\Microsoft.WindowsAzure.Storage.dll" -r:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5.2\mscorlib.dll" -r:"C:\Users\stewa_000\Documents\Visual Studio 2015\Projects\ErrorDemo\packages\Newtonsoft.Json.6.0.8\lib\net45\Newtonsoft.Json.dll" -r:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5.2\System.Core.dll" -r:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5.2\System.Data.dll" -r:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5.2\System.dll" -r:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5.2\System.Numerics.dll" -r:"C:\Users\stewa_000\Documents\Visual Studio 2015\Projects\ErrorDemo\packages\System.Spatial.5.6.4\lib\net40\System.Spatial.dll" --target:library --warn:3 --warnaserror:76 --vserrors --LCID:1033 --utf8output --fullpaths --flaterrors --subsystemversion:6.00 --highentropyva+ --sqmsessionguid:e4de3cb0-1455-4883-b2e7-87d51ceacca0 "C:\Users\stewa_000\AppData\Local\Temp.NETFramework,Version=v4.5.2.AssemblyAttributes.fs" AssemblyInfo.fs Library1.fs 1>C:\Users\stewa_000\Documents\Visual Studio 2015\Projects\ErrorDemo\ErrorDemo\Library1.fs(8,37): error FS0039: The type 'FlintstonesEntity' is not defined 1>C:\Users\stewa_000\Documents\Visual Studio 2015\Projects\ErrorDemo\ErrorDemo\Library1.fs(8,37): error FS0039: The type 'FlintstonesEntity' is not defined 1>Done building project "ErrorDemo.fsproj" -- FAILED.

[isaacabraham]

Basically this is a "feature" of the TP. Unlike most other TPs which eagerly evaluate schema and generate the type system up front, the Azure TP generates types on demand, so only once you navigate through blobs or tables do those types appear accessible. It most mostly due to save on potential IO - if you point to a real Azure account, theoretically you could have an infinite number of tables and blobs.

Perhaps tables should be treated differently from blobs and should be eagerly evaluated?

[stewart-r]

Ah - thank you, Isaac. I appreciate that explanation.

It makes perfect sense now you've explained it.

Not sure I have enough experience to form a meaningful opinion on whether it would be best to eagerly evaluate the types for tables. It's really not a huge headache to first try to load a non-existent partition for the type now that I know that's a reliable workaround.

I guess a couple of alternative approaches could be:

• Is it possible/feasible/straightforward to customise that error message to suggest this as a possible cause?
• Could another alternative be to allow eager loading across the board as a consumer controlled option? That way the documentation could explain the potential issues with each approach.

To me, the final option sounds like the best solution but I recognise there could be a chunk of work involved in implementing it and I am sure there are more pressing priorities for the project! :-)

[isaacabraham]

The second option is exactly what I had in mind as the best solution, too :-) There's a number of ways this could go - e.g. for blobs, specify a set of containers of paths that you would like to "eagerly evaluate" as an argument to the type etc..

I'll create a few issues which we can use to track this.

Error message - good idea and a quick win - not sure this is possible though!

[isaacabraham]

@stewart-r By the way - there's basically nothing more pressing than implementing a feature that has some user feedback :-) So I'll sort something out with regards to tables in the near future - keep an eye on that issue ;-)