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:
Related
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.
First of all Sorry all that I have to write the lengthy question, But it is necessary to write these things to explain my problem better.
We have an installer to install our application. I want to upgrade the database through installer. So, I have created a snapshot of the latest structure database and placed in the package of the application. I have used the RedGate SQL Comparison SDK API to compare structure of two databases and then synchronize the customer database with the latest snapshot (which I have provided).
I am using custom action class library project to write the methods and those methods will be called the installer itself.
I have purchased the RedGate License key and also RedGate Tool is installed on one machine. On the same machine, I have a installshield license, So I am writing the custom action code on that machine only.
We need to add 'licenses.licx' file in the project where we are using the RedGate SDK API. I have added that file as mentioned in 'http://documentation.red-gate.com/display/CSD11/Distributing+your+SDK+applications'.
I have added that file and the compilation succeeded, as I have the license activated on the same machine. So, first of all to embed the license with the project I had deactivated the RedGate License from the installed RedGate and then While compiling the project I got a popup for activation as shown below:
I have applied the valid license, then I have compiled the installer project from installshield 2014 (which is using the custom action project).
My code of synchronizing the database is working as expected. So, I didn't found any problem in the synchronization code.
Here, the problem is: If I will install the product on the machine which have the Redgate License, then the product will be installed and database will be synchronized successfully. On the client machines, it is obvious that they would not have the RedGate license. The installer is giving the activation popup as shown in above image just before starting the synchronizing.
Even though I have given the valid license at the time of compiling the, I am not able to sync the dbs on other machines.
Hope, someone has a solution for this.
Thanks in anticipation.
Did you rename the assembly after compiling? The engine requires that the assembly file name is the same as the name of the embedded licence resource. Here's a quote from the relevant page in the documentation.
When deploying an assembly utilizing SQL Comparison SDK to a remote site where SQL Comparison SDK is not already installed and activated, you may be asked to activate the SDK, even though the assembly had been built and licensed correctly.
The problem occurs after renaming an assembly. SQL Comparison SDK assemblies cannot be renamed after they are built, because the licensing system requires the licence resource embedded into an assembly to bear the same name as the assembly file name.
You can either change the assembly back to its original name, or change the settings in your Visual Studio project so that the output assembly is compiles as a different name and deploy the assembly built with the desired name.
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...?
All,
I'm currently in the process of attempting to create a repeatable process for the upgrade of a TFS 2008 installation to new hardware in what Microsoft call a migration upgrade, but am experiencing issues when building the VS 2008 projects on the new hardware.
Our TFS 2008 installation consists of two machines; one which houses the SQL databases and Application Tier, and the other which acts as a dedicated Build Server.
The new hardware for our TFS 2010 installation consists of two machines; one which houses the SQL databases, Application Tier, SharePoint and the Reporting Services.
So far, I have managed to successfully repeat the backup of the necessary TFS databases from the original server to the new server and restore them, followed by the 'tfsconfig import' command to successfully import and upgrade the databases to a Team Project Collection. The Team Project Collection appears correctly, and it is immediately usable. All security settings, shelvesets, workspaces etc. are intact.
Our issues start when we begin trying to build solutions. We are initially trying to build these solutions without upgrading them to the VS 2010 format, nor modifying the target Framework of any of the projects.
We get the following errors when various projects build:
< filename>.resx(x,y): error RG0000: Could not find a type for a name. The type name was 'System.Collections.Generic.List`1[[< class>, < assemnbly>, Version=a.b.c.d, Culture=neutral, PublicKeyToken=9557797252b44220]], mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. Line x, position y. [< projectfilename>]
ResGen : error RG0000: Could not load referenced assembly "< filename>.dll". Caught a FileNotFoundException saying "Could not load file or assembly '< filename>.dll' or one of its dependencies. The system cannot find the file specified.". [< projectfilename>]
Various 'ambiguous' MSBuild target references when compiling workflow-related projects:
C:\Program Files (x86)\MSBuild\Microsoft\Windows Workflow Foundation\v3.5\Workflow.VisualBasic.Targets (153): 'GeneratedCodeAttribute' is ambiguous in the namespace 'System.CodeDom.Compiler'.
There are various suggestions about how to eliminate these issues, including modifying the 32-bit support flag on ResGen, or forcing the use of the 64-bit ResGen, and upgrading projects to VS 2010 format and changing them to target Framework 4.
Issue 1. can be fixed by changing the offending projects to target Framework 4, however this particular project cannot be upgraded yet due to compatibility issues, and I have not yet found a solution for issues 2. & 3.
We have upwards of 20 Team Projects, with multiple branches in each, and would therefore (due to the amount of work involved) like to avoid manually changing all projects/solutions (especially as some products cannot be upgraded to Framework 4 yet for compatibility reasons, and building Framework 3.5 targeted projects in Framework 4 MSBuild does not appear to be as compatible as Microsoft would have us believe).
If anybody has any ideas which may prove helpful, then please let me know.
Cheers,
Antony
EDIT:
Issue 1 has been seen by other people, and relates to resource files referencing generic lists of a custom type. As it turns out, these were superfluous in our project, so I simply removed them, and that build issue was history.
Issue 2 seems to have dissappeared all by itself, possibly as a result of fixing issue 1.
Issue 3 relates to building VS2008 Workflow projects in MSBuild 4, when they target Framework 3.5. Microsoft, in their infinite wisdom, have apparently chosen to not address this issue (Link to Connect site), and there are several ideas to fix it (referencing specific versions of the Framework, changing the build workflow to use MSBuild 3.5), none of which work.
So our upgrade to 2010 is on hold it would seem, until either the products for which we build the 3.5 workflows (CRM 4.0 and SharePoint 2007/2010) support Framework 4, or until Microsoft fix the issue.
EDIT:
Microsoft have admitted that there is an issue, and have released the following information relating to the above KB number: http://support.microsoft.com/kb/2023579
As stated in my commented addition on my original post, this issue relating to the workflows not building is indeed resolved by a patch for the Microsot .Net Framework 4 Extended, which is outlined in KB2023579, which has not yet been made public (at the time of this post).
This solution was provided by Microsoft through a support call, and as such I am bound by the terms and conditions of that call, which prevent me from distributing a link to the patch until the official KB article is made available, at which point I will post the link. Sorry.
Hotfix that worked for us: http://support.microsoft.com/kb/2249629