While using Owin.Security.OpenIdConnect.Server in 4.5 framework facing the below error :
error CS1061: 'IAppBuilder' does not contain a definition for
'UseOpenIdConnectServer' and no accessible extension method
'UseOpenIdConnectServer' accepting a first argument of type
'IAppBuilder' could be found (are you missing a using directive or an
assembly reference?)`
Can anyone suggest a way to overcome this error?
If you are using Owin.Security.OpenIdConnect.Server version 2.00, the dependencies are
If you are using Owin.Security.OpenIdConnect.Server version 1.1.0, the dependencies are
Related
I've got an Azure Function app that creates a precompiled DLL (so it uses normal .cs files, not the older .csx method, pre-VS2017). Previously, it was targeting .Net Framework 4.5.2. I updated it to 4.7 so as to use some of the new C# 7 features. I updated my NuGet packages by doing "Update-Package -Reinstall" and verified that they all have the "net47" target set in my packages.config file.
Everything compiles fine. But when I call a function that uses either of 2 HttpRequestMessageExtensions methods, I get an exception. One example of the exception is this:
Method not found: 'System.Net.Http.HttpResponseMessage
System.Net.Http.HttpRequestMessageExtensions.CreateResponse(
System.Net.Http.HttpRequestMessage, System.Net.HttpStatusCode)'.
Here's an example of a tiny test function that will cause the error:
using System.Net;
using System.Net.Http;
public static HttpResponseMessage Run(HttpRequestMessage req)
{
return req.CreateResponse(HttpStatusCode.Accepted, "");
}
Upon calling this function with say Postman, I'll receive the aforementioned exception. I also get a similar method not found exception when I call GetQueryNameValuePairs() on the HttpRequestMessage.
I've tried updating my NuGet packages to the latest, no difference. I've cleaned and rebuilt and restarted a bunch of times, making sure to nuke my bin and obj directories.
I'm not sure what could be the problem. I guess I could downgrade back to .Net 4.5.2 but I'd rather not. For one, I want to use C# 7, and for two, I want to understand what the problem is rather than avoid it.
Update: interesting. The issue seems to be with System.Net.Http. If I lower it to 4.0.0 everything works fine. If I raise it to any higher version I get the issues listed above. I tried selectively lowering each of my packages, one by one, to their previous version number to find this out. I then updated all but this one to the latest version and it fixed the issue.
I also tested it on my side. The issue is related to the latest version of System.Net.Http assembly(4.3.2). If I don't install this package manually or install the earlier versions(4.3.1/4.3.0), the application could work fine.
The CreateResponse method is a extension method which is written in System.Web.Http assembly(version 5.2.3). It seem that it is not compatible with the latest version of System.Net.Http. Please could just skip the error by using the earlier version of System.Net.Http and you can also submit this issue to Microsoft using follow channel.
https://connect.microsoft.com/VisualStudio/Feedback
Interesting. For me, if I got above version 4.0.0 (including 4.1.1 or 4.3.1) I still get the same problem of not finding those extension methods.
The assembly might not be updated during you change the package version. From the bin\Debug\net47 folder, we could check the current assembly version we used.
If the modified date of assembly is 2/9/2017, the package version is 4.3.1. If the modified date of assembly is 4/19/2017, the package version is 4.3.2. If the assembly is not the latest version, it could work fine on my side.
In addition, Microsoft.Asp.Net.WebApi.Client package is installed by default when creating an Azure function. System.Net.Http is one of its dependencies. So we don't need to install the System.Net.Http package manually. When running our application, NuGet will choose a right version of System.Net.Http for our application.
I had the same issue running my Azure Function locally and eventually tracked it down to conflicting System.Net.Http assemblies. I created my Azure function from a blank ASP.NET Web App and initially pulled down the System.Net.Http NuGet package to use within the project. I also pulled down the Microsoft.AspNet.WebApi.Client for use within the project. It did not matter which version of System.Net.Http I tried my project would compile but fail when the request was made.
Eventually, I removed packages I had downloaded, cleaned the build folder and added just the Microsoft.AspNet.WebApi.Client. I noticed that this automatically referenced the System.Net.Http on my machine for my version of the .NET Framework. (C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework). This compiled successfully and I was able to make requests to the function without any exceptions.
Using #Aaron-Newton's insight, I identified that my issue was due to my Azure Functions project referencing a .Net Standard 2.0 class library. I switched it to .Net Framework 4.6 and it started working again. Seems like this is a bug in the Functions tooling.
I've filed a bug with the Functions team here: https://github.com/Azure/Azure-Functions/issues/477
I had the same issue. I spent quite a while to fix this problem.
The cause is that the Azure Functions project is refering to .Net Standard Library with version higher than 1.4.
Bringing down your .Net Standard version to 1.4 or lower would fix the problem.
But this is defintely a bug with Azure Functions SDK. They should fix it.
https://github.com/Azure/azure-webjobs-sdk-script/issues/980
https://github.com/Azure/Azure-Functions/issues/477
After upgrading to the latest version of Xamarin.Forms (2.3.3.175) my iOS project throws the compilation error
Failed to resolve assembly: 'Stateless, Version=2.5.53.0, Culture=neutral, ...' (MT2002) in File MTOUCH and Path MTOUCH
The shared code is in a PCL library targeting PCL 4.5 - Profile78
So far Google search hasn't returned anything.
Anyone encounter this yet? Appreciate any help in resolving this.
I am using Xamarin Studio Community Edition version 6.1.2 (Build 44)
You are likely using couchbase lite. Stateless is an assembly required by couchbase lite. It seems it cannot be resolved if used in a pcl project. You can read something about this problem here. A couchbase developer states that
The strategy has changed since then. We won't be supporting PCL but instead we aim to support .NET Standard 2.0 when it is ready.
Hope this helps.
Xamarin.Forms has NO dependency on an assembly named Stateless of any sort. Check your dependencies, and your dependencies dependencies...
When adding the Microsoft.Azure.Devices NuGet package (I've tried 1.0.0, 1.0.2, and 1.0.4) to an ASP.NET 5 (Web API 2) project, the reference to System.Net.Http.Formatting is marked as not resolvable with
NU1001 The dependency fx/System.Net.Http.Formatting could not be resolved
There are several NU1001 issues out there, but none whose causes seem to map to this one. The best reference is this one on Github, but the resolution details were sketchy.
The reference DLL is indeed marked as Copy Local when the package is brought into a 'legacy' assembly package, so I can see why it might not find it, but can't determine the right way to fix it.
In my actual use-case, Microsoft.Azure.Devices is being referenced by a .NET assembly package and THAT is then included as a project reference in the ASP.NET 5 project, and indeed that gives the same error as trying to directly reference the NuGet from the ASP.NET 5 project.
We're using dnx452 as the only framework referenced in the project.json file.
I tried this with version 1.0.5 and it installed successfully for me.
I am using Xcode 6.2, Facebook-iOS-SDK 4.0. I used to have working code with Facebook-iOS-SDK 3.20.0.But, now I am getting compile-time error FacebookSDK.h not found. I am using pod to install sdk. Can someone give me any pointers why this is happening?
The SDK (v 4.0) is no longer one framework named "FacebookSDK", but rather a few different packages with a naming convention of "FBSDKTypeKit", where types are different things like Core and Login. This means the name of the header files have also changed, so that's why your project can no longer find FacebookSDK.h (as it's now FBSDKCoreKit.h).
I'm currently trying to convert a WiX 3.5 custom actions project in Visual Studio 2008 to WiX 3.7 and Visual Studio 2012 and I'm getting the following exception:
The type or namespace name 'MyNamespace' could not be found (are you
missing a using directive or an assembly reference?)
The dll is definitely referenced and Visual Studio 2012 has no problem seeing the namespace. Everything under the namespace even pops up in Intellisense, but when I build it I'm getting this exception.
Anyone have an idea of what's going on here?
Additional Info:
The namespace I'm referencing is a .Net 2.0 library and the custom actions project is a .Net 2.0 project.
EDIT:
After further investigation, I'm getting this warning, which I'm guessing is the root of the problem:
The primary reference "MyNamespace, Version=8.5.1.20, Culture=neutral,
PublicKeyToken=f593502af6ee46ae, processorArchitecture=MSIL" could not
be resolved because it has an indirect dependency on the .NET
Framework assembly "mscorlib, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089" which has a higher version "4.0.0.0"
than the version "2.0.0.0" in the current target framework.
Why is it trying to use mscorelib 4.0 when this is a 2.0 project?
So it turned out that the dll being reference, while compiled to target the .Net 2.0 framework, was being compiled with the 4.0 compiler. Switching the project to compile with the 3.5 compiler solved the problem.
This may be completely unrelated but I had a similar issue yesterday. I had accidentally copied a class file (.cs) from one solution into another solution. Clearly, I hadn't added the references to the other solutions.
In our case, while the referenced dll was targeting .Net 4.0, it had its own reference to a .Net 4.5.2 dll. The referenced 4.0 framework target led us to believe that 4.5 or 4.5.1 were sufficient to handle things, but they weren't—the referencing project had to be 4.5.2 to handle the dll and all its references.
This was clearly an error on the part of the dll maker.