I have a new MVC project using TokenClient from IdentityModel
var tokenClient = new TokenClient(tokenUrl, clientId, CLIENT_SECRET, null, AuthenticationStyle.BasicAuthentication);
I have the nuget package in for IdentityModel and everything compiles fine. However, at runtime I get the following error.
Method not found: 'Void
IdentityModel.Client.TokenClient..ctor(System.String, System.String,
System.String, System.Net.Http.HttpMessageHandler,
IdentityModel.Client.AuthenticationStyle)'.
The .NET version of the MVC project is 4.6.1
What can be causing this issue? I have been searching google and cannot find anything that helps. It must be something simple that i am missing.
EDIT:
initializing it by declaring the parameters explicitly does not work either.
var tokenClient = new TokenClient(tokenUrl, clientId: clientId, clientSecret: CLIENT_SECRET);// CLIENT_SECRET, null, AuthenticationStyle.BasicAuthentication);
However initializing it with the one parameter works fine.
var tokenClient = new TokenClient(tokenUrl);
IdentityModel is a 3rd party library built by the creators of Identity Server. v3.10.1 definitely does have that method overload in it. I have recreated your error and the reason you are getting the error is because IdentityModel v3.10.1 is not compatible with .NET Framework 4.6.1. The creators changed the signature of that overload and made the HttpMessageHandler an optional parameter so your code will compile, but will throw this Method Not Found error at runtime. The IdentityModel project you are referencing has been archived by the guys at Identity Server so I would recommend migrating if you can.
You have a couple of options as I see it:
1) Migrate to .NET Core and leverage IdentityModel v2.
2) Downgrade your project to .NET Framework 4.5.2 (the last compatible version for IdentityModel V1)
3) Do not use this overload (as you've already found the single tokenUrl param works). I would stay away from this approach as you are likely to run into additional compatibility issues.
Basically, if you don't want to migrate to .NET Core, keep this project on 4.5.2. If you can migrate, do that instead. Identity Server is moving toward .NET Core as a whole anyway and you will get more mileage by making that leap now.
I encountered the same problem while working through the MVC Getting Started example for IdentityServer3. If you check the dependencies for IdentityModel v3.10.1 you'll notice that it depends on System.Net.Http (>= 4.3.3). My project had v 4.2, updating to the current version solved the problem.
If you are using ASP.Net MVC application check binding redirect of "System.Net.Http" in web.config
it should be like
<dependentAssembly>
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.0.0.0" />
</dependentAssembly>
Related
Is there a Nuget/Assembly/Library that will allow me to bind BlobProperties for .NET Core Azure 3.x Functions, in both a local environment and in an Azure environment?
I have an Azure Function running on .NET Core 3 with a signature that looks like this:
public async Task DoFunctionWork([BlobTrigger("path/to/{blobName}")] Stream blobStream,
**Microsoft.Azure.Storage.Blob.BlobProperties Properties**)
{
//Function Body....
}
The problem is with the Properties parameter. If run locally, it can only be resolved if I prefix the BlobProperties parameter with the Microsoft.Azure.Storage.Blob namespace as above. In Azure, it never seems to work. When it fails - on either Azure or locally - I get one of the following messages:
Can't bind properties to type 'Azure.Storage.Blob.Properties' or Can't bind properties to type 'Microsoft.Azure.Storage.Blob.Properties'
Has anyone encountered this before? How did you solve it?
Thanks.
It looks like this is because, there is a version mismatch between what your SDK requires and what you have installed.
For instance, if you are using 3.0.9 version of Function SDK, then you might have installed Microsoft.Azure.WebJobs other than (>= 3.0.0 && < 3.1.0) versions.
Microsoft.NET.Sdk.Functions 3.0.9
Microsoft.Azure.WebJobs.Extensions.Storage 4.0.3
I want to upgrade Sustainsys.Saml2 Nuget package from version 0.23.0 to version 2.0.0.
I have an error in next line of code: spOptions.SystemIdentityModelIdentityConfiguration.AudienceRestriction.AudienceMode = AudienceUriMode.Never;.
The SPOptions class doesn't have a IdentityConfiguration property anymore.
var spOptions = new SPOptions();
spOptions.SystemIdentityModelIdentityConfiguration.AudienceRestriction.AudienceMode = AudienceUriMode.Never;
I want to know how to receive the same behaviour after updating to version 2.0.
It's currently not supported in 2.2 to ignore the audience restriction. I you need that, and still run on the .NET Framework you might as well use 1.0.0.
Use the Docusign API to send a Document for a signature
string accountId = loginApi(username, password, integratorKey);
Which then calls LoginAPI method which breaks at line:
LoginInformation loginInfo = authApi.Login();
Which should allow me to receive the accountId for my integrator key/login credentials
Instead I am getting an error of:
{"Method not found: 'RestSharp.IRestRequest RestSharp.RestRequest.AddFile(System.String, System.Action`1, System.String, System.String)'."}
Just started integrating Docusign into our application so using these versions which are dependencies to attempt to recreate this issue:
Docusign.eSign.dll V2.1.8
RestSharpv106.1.0
RestSharpSignedv105.2.3
Newtonsoft.Json v10.0.3
BouncyCastle v1.8.1
Any Idea?
This is because of RestSharp and RestSharpSigned have the same dll file name and one overwrites the other.
You should use RestSharpSigned only to avoid conflict.
I solved the issue by uninstalling RestSharp and its binding redirect in *.config file:
<dependentAssembly>
<assemblyIdentity name="RestSharp" publicKeyToken="598062e77f915f75" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-106.6.10.0" newVersion="106.6.10.0" />
</dependentAssembly>
Know this is a bit of an old one, but I had the same problem. As Nick suspected, the issue was down to a conflict between RestSharpSigned and RestSharp.
I uninstalled both and the DocuSign library, then re-installed RestSharpSigned, then DocuSign. Our other code that was using the standard RestSharp library seems to be working fine with the signed version.
As stated in official document, I am trying to implement UseOwin in the Startup.cs.I am trying to use/port IAppBuilder (Microsoft.Owin.Builder.AppBuilder) inside IApplicationBuilder (Microsoft.AspNetCore.Builder.IApplicationBuilder). I had legacy code written using IAppBuilder running fine on .Net Framework 4.5.
I have seen couple of examples about using IAppBuilder in IAplicationBuilder e.g. example 1 example 2. These attempts were about .netcore 1.1 and not .net core 2.0. May be this is the reason i am unable to port.
Please share your thoughts whether i am trying to achieve something not possible at the moment in .net core 2.0 or there is some error in my code.
Note:
I am using dotnetcore 2.0 with Visual Studio 2017
Error
I am getting following error.
return owinAppBuilder.Build,
Task>>(); TypeLoadException: Could not load type
'System.Security.Cryptography.DpapiDataProtector' from assembly
'System.Security, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a'.
My attempt
app.UseOwin(setup => setup(next =>
{
var owinAppBuilder = new AppBuilder();
var aspNetCoreLifetime =
(IApplicationLifetime)app.ApplicationServices.GetService(typeof(IApplicationLifetime));
new AppProperties(owinAppBuilder.Properties)
{
OnAppDisposing = aspNetCoreLifetime?.ApplicationStopping ?? CancellationToken.None,
DefaultApp = next,
AppName = "test"
};
// Only required if CORS is used, configure it as you wish
var corsPolicy = new System.Web.Cors.CorsPolicy
{
AllowAnyHeader = true,
AllowAnyMethod = true,
AllowAnyOrigin = true,
SupportsCredentials = true
};
//corsPolicy.GetType()
// .GetProperty(nameof(corsPolicy.ExposedHeaders))
// .SetValue(corsPolicy, tusdotnet.Helpers.CorsHelper.GetExposedHeaders());
owinAppBuilder.UseCors(new Microsoft.Owin.Cors.CorsOptions
{
PolicyProvider = new CorsPolicyProvider
{
PolicyResolver = context => Task.FromResult(corsPolicy)
}
});
PublicClientId = "self";
OAuthAuthorizationServerOptions OAuthOptions = new OAuthAuthorizationServerOptions
{
TokenEndpointPath = new Microsoft.Owin.PathString("/Login"),
Provider = new MyServiceProvider(PublicClientId),
AccessTokenExpireTimeSpan = TimeSpan.FromMinutes(60),
AllowInsecureHttp = true,
RefreshTokenProvider = new MyRefreshTokenProvider(),
};
owinAppBuilder.UseOAuthBearerTokens(OAuthOptions);
//owinAppBuilder.UseTus(context => new DefaultTusConfiguration
//{
// // Excluded for brevity, use the same configuration as you would normally do
//});
return owinAppBuilder.Build<Func<IDictionary<string, object>, Task>>();
}));
Microsoft.Owin and related packages do not have targets for .NET Core, no for .NET Standard. All they have is dlls targeting full .NET. You can reference such libraries from your project targeting .NET Core, but they are not guaranteed to work, as you see yourself, because API (set of classes\methods\signatures) of full .NET and .NET Core are different. Visual Studio even will show a warning when you are doing that, for example:
Package 'Microsoft.Owin 3.1.0' was restored using
'.NETFramework,Version=v4.6.1' instead of the project target framework
'.NETCoreApp,Version=v2.0'. This package may not be fully compatible
with your project.
There is Microsoft.AspNetCore.Owin package and you can use OWIN middleware in .NET Core app as your first link describes, but almost all it provides is UseOwin extension method. There is no AppBuilder type there and so on, and there are no Microsoft.AspNetCore.Owin.Cors packages or similar. So you have to either implement all that yourself (no reason to, because you can use the same functionality provided by asp.net core framework) or wait for OWIN packages that target .NET Standard\Core and do that (didn't check, maybe they even exist already).
So, your code uses packages which are indeed not compatible with your target framework, as exception you have at runtime shows. So another answer (for some reason downvoted) is technically correct.
If you still want to use those packages reliably - you need to target full .NET Framework and not .NET Core. To do that, open your .csproj file and change
<TargetFramework>netcoreapp2.0</TargetFramework>
To some .NET framework version that supports .NET Standard 2.0, for example:
<TargetFramework>net47</TargetFramework>
Then go to nuget package manager and, if you have microsoft.aspnetcore.all package (or other packages targeting .NET Core) - uninstall it, you don't need it anyway. Then install Microsoft.AspNetCore package and all other asp.net core packages you need (if not installed already). Rebuild, run and it will work just fine.
That works because all (most?) AspNetCore packages target .NET Standard, not .NET Core, and you can use them in projects targeting full .NET Framework.
Note that by doing that you have asp.net Core project, but not on .NET Core, with all consequences that come from that (cannot run with dotnet run, on linux need to run with mono, and so on).
The Microsoft.Owin components will not work on dotnet core 2.0, they only work on .NET 4.5+
I setup nuget packages
Install-Package Google.Apis.Core
Install-Package Google.Apis
Install-Package Google.Apis.Auth
As it said there http://google-api-dotnet-client.blogspot.ca/
We have released a 1.9.3 version of NuGet packages only for the Core packages - that’s where the new features are. You should still use 1.9.2 version of the API specific packages (such as Drive) and only update the Core packages
Install-Package Google.Apis.Calendar.v3
When I tried to build it I'm getting error:
Assuming assembly reference 'Google.Apis, Version=1.9.2.27817, Culture=neutral, PublicKeyToken=4b01fa6e34db77ab' matches 'Google.Apis, Version=1.9.3.19379, Culture=neutral, PublicKeyToken=4b01fa6e34db77ab',
you may need to supply runtime policy
I added redirect script in web.config:
<dependentAssembly>
<assemblyIdentity name="Google.Apis" publicKeyToken="4b01fa6e34db77ab"/>
<bindingRedirect oldVersion="1.9.2.27817" newVersion="1.9.3.19379" />
</dependentAssembly>
but still getting the same error. I check it with spy and it appears Calendar dll wants old API.
Any idea how to fix it? (Thanks)