I have a durable functions app that worked perfectly until I upgraded package Microsoft.Azure.WebJobs.Extensions.DurableTask from version 1.5.0 to 1.6.0.
Now running locally caused this error in the console:
[8/31/2018 9:35:58 PM] A ScriptHost error has occurred
[8/31/2018 9:35:58 PM] System.Private.CoreLib: No parameterless constructor defined for this object.
[8/31/2018 9:35:58 PM] Stopping Host
I have made absolutlely no code changes. What am I missing?
Thanks in advance for your help.
See comment on our GitHub here: If you're using the Functions V2 runtime, breaking changes were introduced into the Functions V2 host. Durable Functions 1.6.0 accommodates those changes and must be used with version 2.0.12050.0 or higher of the Functions runtime. There's a new version of the Azure Functions Core Tools out to accommodate these changes as well.
If you want to use Durable Functions 1.6.0, you'll need to follow these steps:
You will need to update your Azure Functions Core Tools to the latest version. (2.0.1-beta.37)
If your app is built using Visual Studio, you need to update your Microsoft.NET.Sdk.Functions NuGet package to v1.0.19.
You will need to migrate to the new Functions V2 host.json schema.
If you want to stay with Durable Functions 1.5.0, you will need to pin your core tools to an older version, and in Azure, pin your FUNCTIONS_EXTENSION_VERSION. More detailed information on pinning can be found in the runtime release announcement.
If your Functions app is running on the V1 runtime, Durable Functions 1.6.0 should work without incident. (Please let us know if it's not, that means we need to fix something.)
Functions Runtime 2.0.12050-alpha release
notes
Functions Runtime 2.0.12050-alpha
announcement
Durable Functions 1.6.0 release notes
I can't comment so I have to answer.
There are several problems with durable functions v2.
With the latest package versions I can't run locally with VisualStudio IDE.
I tried and checked all the infos in the previous answer; "Azure Functions and Web Job Tools" is changed so I tried also versions 15.10.2009.0 and 15.8.5023.0
Most relevant problem is that at this point if I go down with package versions I can't use Newtonsoft because of versioning constraints.
Related
Got an Azure Function that is supposed to call the context to update the values of DbGeography. I keep getting this exception:
Spatial types and functions are not available for this provider because the assembly 'Microsoft.SqlServer.Types' version 10 or higher could not be found.
I installed the NuGet package in the Azure Function project. Currently, the Azure Function is not published, I run it locally. It would be nice to solve these issues, even when the function is deployed.
According to your error message, I suppose your issue is about when you try to deploy to a machine that does not have the CLR Types for SQL Server installed.
You said you have installed the Nuget package, so I suggest you could also check whether the appropriate version of the native SqlServerSpatial110.dll assembly is copied to the output directory and deployed with your application. For more details about this issue, you could refer to this article.
You could also check whether you have installed the Microsoft System CLR Types. Fore more details ,you could read this SO thread.
After a lot of research I just installed "Microsoft System CLR Types for SQL Server 2012" from:
X86 - http://go.microsoft.com/fwlink/?LinkID=239643&clcid=0x409
X64 - http://go.microsoft.com/fwlink/?LinkID=239644&clcid=0x409
Worked like a charm!
Besides, If I use SqlGeography in Microsoft.SqlServer.Types package, it works fine on my side:
The code in Azure function:
The result in Azure portal:
As soon as I've solved one issue with IBM.EntityFrameworkCore, another one has arose. Everything is soooo hard and painful with DB2 and their .NET team...
The problem: I have several EntityFrameworkCore - based projects in the same VS solution, for example MyDb2EfModel, MyMsSqlEfModel, and MyNpgsqlEfModel. (It's kind of a complex data-integration scenario.) On top of that I have a CLI project which references all the three and performs actual data ops. When the CLI project references only MyDb2EfModel project - IBM.EntityFrameworkCore works as expected. But as soon as I add references to the remaining two projects - it simply stops working and throws some misleading exception. The exception happens because overridden DbContext.OnConfiguring and DbContext.OnModelCreating methods aren't called anymore. When there's only one reference (MyDb2EfModel) the methods get called as expected, and everything works. But with all three library projects referenced - they aren't called anymore.
Let's also note that the mentioned methods get called on DbContext instances from MyMsSqlEfModel and MyNpgsqlEfModel libraries. The only one that stops working is MyDb2EfModel (which is based on IBM.EntityFrameworkCore).
Thumbs down for IBM and their .NET team! It's ridiculous how these guys are making things be 100 times more complicated then with any other DB.
The question is obvious: Does anyone has any experience in a similar scenario, and hopefully any suggestion how to resolve the issue?
Thanks!
I've found the reason. It turned out that it's about Microsoft.EntityFrameworkCore version. Currently available version of IBM.EntityFrameworkCore is 1.1.1.101 (.NET Standard 1.6), and it uses Microsoft.EntityFrameworkCore version 1.1.1 or 1.1.2. It cannot be used with Microsoft.EntityFrameworkCore version 2.0.0 (.NET Standard 2.0) - it throws the exception I was getting.
In the other two libraries I've used Npgsql.EntityFrameworkCore.PostgreSQL version 2.0.0 and Microsoft.EntityFrameworkCore.SqlServer version 2.0.0, both depending on Microsoft.EntityFrameworkCore version 2.0.0 (all in .NET Standard 2.0).
So when I referenced only MyDb2EfModel in my CLI project everything was working because only Microsoft.EntityFrameworkCore version 1.1.2 is referenced and used. But as soon as I add reference to another projects CLI ends up with dependencies on both Microsoft.EntityFrameworkCore version 1.1.2 and 2.0.0 versions, and the newer (2.0.0) is loaded and used. And IBM.EntityFrameworkCore was failing because it cannot use it.
How to solve? Either wait for IBM.EntityFrameworkCore for .NET Standard 2.0, or downgrade other references to ensure that Microsoft.EntityFrameworkCore version 2.0.0 isn't used anywhere (which will cause other headaches).
So although it's not about a bug in IBM.EntityFrameworkCore, IBM DB2 .NET team is still to blame for not having .NET Standard 2.0 at least preview published, although .NET Standard 2.0 is available for almost a year now, recently reaching its "release" version. And there are more things to blame IBM DB2 .NET team for (unrelated to this particular issue).
Background:
We are using the VSTS to build and Octopus integration to deploy our product. The Octopus step is configured as follows,
Issue
Today VSTS Build was throwing following error,
No supported agent found in pool Default. All agents in this pool are
using a version that is deprecated. Migrate to the latest 2.x version
of agent. For more information, see
https://go.microsoft.com/fwlink/?linkid=851067
As a result, the Agent was updated to the latest version,
After the update the octopus step stopped working with following error,
Then issue seems to be the environment variables are not replaced in the step.
I would like to know if there is a work around to fix this issue.
First, there is 2.* version available, so you can delete the old one and add the new one.
Secondly, use $(Build.BuildNumber) instead in Package Version input box, also for Output path: $(Build.ArtifactStagingDirectory).
I've created a simple Azure Mobile Services project and added the nuget package for MongoDB (package id is mongocsharpdriver).
The version I added is 1.10.0
When I deploy the project I get the following error:
"Found conflicts between different versions of the same dependent assembly 'MongoDB.Bson': 1.10.0.62. Please change your project to use version '1.9.2.235' which is the one currently supported by the hosting environment."
It seems like the Dlls from the package I've added are conflicting with an older version installed by default in the cloud environment.
Is there a way to get around this problem?
(While trying to figure out whats wrong I installed the nuget package WindowsAzure.MobileServices.Backend.Mongo which can't be installed because it requires mongocsharpdriver(=1.9.2) and dose not allow me to use my newer dlls.)
It seems I'll have to wait for microsoft to update the dll in Azure:
After updating the nu-get packages for a previously working Azure Mobile Service (.Net back-end), I now get the following error when accessing Table Controllers:
An error has occurred.","exceptionMessage":"Object reference not set to an instance of an
object.",
"exceptionType":"System.NullReferenceException",
"stackTrace":"at Microsoft.WindowsAzure.Mobile.Service.Serialization.
SelectExpandWrapperConverter.ODataReflectedTypes..ctor()
at Microsoft.WindowsAzure.Mobile.Service.Serialization ...
Custom Controllers appear to be unaffected.
I've probably missed something obvious, but I can't see it
Any help would be appreciated
Many Thanks
K.
From Henrik F. Nielsen's answer in the MSDN forums:
There are known incompatibilities with the latest version of ASP.NET Web API which was released the same day as our last update. We are working on an update but in the mean time please don't update all your NuGets but only the WindowsAzure.MobileServices.* packages -- they will then include the right dependencies the need.
This is an integration issue with the .NET backend binaries, and it should be resolved soon.
Expanding on #carlosfigueira's answer, it seems that the WepApi 5.2.0 version is not compatible with Azure Mobile Services yet.
I am one of the unfortunate ones who decided to let nuget go to town and update all the packages in the project so here is what I did to deal with this.
Uninstall every nuget package from your mobile service project. Then add them back. Start by using only the Microsoft Azure Mobile Services.NET Backend.* packages - This will pull the currently compatible WebApi 5.1.2 instead of 5.2.0. and other dependent assemblies.
In addition, I was getting a lot of weird redirect binding errors which I believe the tooling added incorrectly - so I commented out all the dependentAssembly tags in the assemblyBindings and then added them back as the mobile service complained. All I had to add back for redirects were Newtonsoft.Json and Microsoft.Owin. YMMV.
I think this may also have something to do with the fact that there are strange interactions between VS and source control plugins since nuget packages sometimes fail because they can't obtain write permissions for packages.config and web.config files.
I am also using a PCL in my service which requires adding the Microsoft.Bcl libraries - perhaps irrelevant but it is what lead me to discovering the underlying error.
Under Tools -> Options -> Projects and Solutions -> Build and Run, set the MSBuild project build output verbosity to Detailed or above to get some insight into what is happening in the process.
[Update 12/24/2014]
I updated something I shouldn't have and everything broke again.
Uninstall all nuget packages. Delete all dependentAssembly elements from the Web.Config file. Save and restart Visual Studio.
Start adding packages back using the following from the Package Manager Console. In my case:
Install-Package WindowsAzure.MobileServices.Backend -Version 1.0.405
Install-Package WindowsAzure.MobileServices.Backend.Tables -Version 1.0.405
Install-Package WindowsAzure.MobileServices.Backend.Entity -Version 1.0.405
Install-Package WindowsAzure.MobileServices.Backend.SignalR -Version 1.0.405
Install-Package WindowsAzure.MobileServices.Backend.Storage -Version 1.0.405
Never touch it again...?