Azure-webjobs-sdk: WebJobs v3 does not run in a .NET 4.6.1 console app

[brettsam]

Scenario:

1. Create a .NET 4.6.1 console app
2. Add the WebJobs v3 package
3. Create a simple app with just a single function (I created a QueueTrigger)
4. Run
5. End up with the error here: https://github.com/Azure/azure-webjobs-sdk/issues/1385#issuecomment-355139760

LoaderExceptions are: Method 'Commit' in type 'Microsoft.Azure.WebJobs.Host.Blobs.Bindings.DelegatingCloudBlobStream' from assembly 'Microsoft.Azure.WebJobs.Host, Version=3.0.0.0, Culture=neutral, PublicKeyToken=null' does not have an implementation.

The issue is that WindowsAzure.Storage ships two different libraries -- one for netstandard13 (which WebJobs v3 builds against) and one for net45 (which a .NET 4.6.1 app will run against). Those two libraries have two different versions of CloudBlobStream, which we derive from in DelegatingCloudBlobStream. The most obvious change is that it has a Commit method in net45 and a CommitAsync in netstandard13.

Talked with @fabiocav and there's no obvious easy workaround or solution right now. Customers will either need to use WebJobs v2 if they target .NET 4.6.1 or use a .NET Core console app if they want to use v3.

[fabiocav]

We have reached out to the storage team and they plan on addressing this issue on a future release.

[brettsam]

There is a workaround that should work while we wait on the permanent fix: in your WebJobs application, explicitly change the reference to WindowsAzure.Storage to target the netstandard1.3 version of the library rather than net45. That will load the correct assembly and the error should go away.

[garyapps]

I have run into this same issue; I tried to use version 3.0 of the webjobs SDK in a .net framework webjob (which is what the VS template for a webjob produces), and just cannot get it to run on Azure.

@brettsam I don't know how to implement your workaround. How does one change the reference to target a different version of the library? When I look on NuGet for WindowsAzure.Storage I only see one version. Is there someplace I can obtain this netstandard1.3 version you mentioned? Or did you mean something else?

@fabiocav Is there an estimate for when this issue will be resolved? It has been 8 months since you brought it to the attention of the storage team so it might have slipped through the cracks.

[wpo365]

I can confirm the workaround suggested by @brettsam.

@garyapps To target the netstandard1.3 version I needed to unload the project in Visual Studio, edit the csproj file and changed the corresponding hint path for the referenced dependency from

<Reference Include="Microsoft.WindowsAzure.Storage, Version=9.3.2.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL"> 

  <HintPath>..\packages\WindowsAzure.Storage.9.3.2\lib\net45\Microsoft.WindowsAzure.Storage.dll</HintPath>
</Reference>

to

<Reference Include="Microsoft.WindowsAzure.Storage, Version=9.3.2.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL"> 

  <HintPath>..\packages\WindowsAzure.Storage.9.3.2\lib\netstandard1.3\Microsoft.WindowsAzure.Storage.dll</HintPath>
</Reference>

[brettsam]

I'm going to close this as there's nothing we can do from the WebJobs side. The workaround will continue to work until the API is fixed across the two versions by the Storage SDK. I'll follow-up with them again.

[davidmatson]

I believe there is something that can be done from the WebJobs side - it could ship both libnet45 (or some other min version) and libnetstandard2.0 DLLs. That might be the only solution that guarantees this kind of bug doesn't happen again - if any dependencies have a .NET Framework version that isn't fully binary-compatible with their .NET Standard version, we'd probably have the same problem here.

[davidmatson]

Another way of putting it:
I think the WebJobs SDK currently has the following bug:
It says it implements the CloudBlobStorage class, but it doesn't implement the right members of that class for all applications that can use .NET Standard 2.0 libraries. In order to implement this class correctly on full .NET Framework, it would need to implement different methods (and provide a separate libnet4x dll with that implementation).

[fabiocav]

Doable, but that would require us to target full multi-target, including .NET Framework targets, as opposed to targeting .NET Standard only

[fabiocav]

Just noticed that you've opened and linked to an issue requesting multi-targeting. This doesn't come without some challenges, so we'd need to consider the impact. I'll leave that open for discussion, but in the meantime, the workaround for this particular issue is still the recommended approach to deal with this problem.

[davidmatson]

Understood there are some challenges, and we can discuss more on that issue. Ideally, any package that ships both full framework and standard would have full framework be a superset of standard only, not with breaking changes or missing types between the two, but apparently that's not always the case. :(

We're using PackageReference rather than packages.config. Do you know if there's a workaround for that case? (Some of our other packages only work with the new, PackageReference-style NuGet - the older packages.config-style NuGet doesn't have all the same features.)

[davidmatson]

I did some checking, and I don't believe there's a workaround when using PackageReference. Details about PackageReference:
https://docs.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files

I'm not aware of a workaround or solution for our projects other than dual-targeting (and/or convincing WindowsAzure.Storage to change net standard to be a strict subset of full framework).

[steventmayer]

@davidmatson I'm in the same boat (using 4.7.2). I ended up, temporarily, excluding the remote asset and adding the 1.3 local version. .Csproj looks like this:
<ItemGroup> <PackageReference Include="WindowsAzure.Storage" Version="9.3.1"> <ExcludeAssets>All</ExcludeAssets> </PackageReference> </ItemGroup> <ItemGroup> <Reference Include="WindowsAzure.Storage" Version="9.3.1"> <Hintpath>ExternalPackages\Microsoft.WindowsAzure.Storage.dll</HintPath> </Refence> </ItemGroup>

Hopefully there is different way to do it with PackageReference but I had no luck.

[ai-motion]

any updates on this issue?

[svengeance]

@brettsam I was running into this issue, however after installing the 4.0 beta for Microsoft.Azure.Storage, the warnings have went away. I scanned the release notes but nothing stood out and this issue wasn't referenced. Are you aware of any fixes therein that might have alleviated this?

[brettsam]

Do you mean the WebJobs package? https://www.nuget.org/packages/Microsoft.Azure.WebJobs.Extensions.Storage/4.0.0-preview1

I don't have any concrete changes -- but this is such a huge change in the Storage SDK that I suspect these types have all been reworked.

[svengeance]

Heya, yeah I did mean the WebJobs package.

In any case I've been running the QueueTrigger webjob in Azure on Net 4.7.2 for a few days without a hiccough or crash, so I think I'll bite with the preview version and see it through.