Skip to content
This repository has been archived by the owner. It is now read-only.

MVC 5 RC #307

Closed
panterlo opened this issue Sep 25, 2013 · 49 comments

Comments

@panterlo
Copy link

commented Sep 25, 2013

As posted on http://stackoverflow.com/questions/19013429/dotnetopenauth-not-working-with-mvc-5-rc there seems that the current version of DotNetOpenAuth is incompatible with MVC 5 RC.

Can this be confirmed and are there any plan to support MVC 5 in the near future ?

@AArnott

This comment has been minimized.

Copy link
Member

commented Sep 25, 2013

The binding redirects in that SO question are required because each MVC release otherwise breaks binary compatibility by changing their assembly version. As for the security transparent to critical issue, I've no idea why that's happening. I'll ask some MVC folks to take a look.

@AArnott

This comment has been minimized.

Copy link
Member

commented Sep 26, 2013

So I heard back from the MVC folks. The problem with the security transparent error is that MVC 5 has a new security model from MVC 4, so a binding redirect alone isn't enough. DNOA must actually be recompiled against MVC 5 instead of 4.
As this would then break MVC 4 users, we may have to fork DNOA packages to support both and have folks install one or the other. NuGet package dependency versioning could help enforce users get the right one.

@AArnott

This comment has been minimized.

Copy link
Member

commented Sep 26, 2013

The MVC folks also suggest that DNOA probably would need to remove this attribute from all its assemblies:

[assembly: AllowPartiallyTrustedCallers]

This would be a major problem, since it is what makes DNOA work well on shared hosting medium trust environments.
So instead of forking all of DNOA for MVC 4 vs. 5, I suggest that DNOA remove all MVC dependencies and keep the assembly level attribute.
Then, as a separate NuGet package, have a DLL with just the extension methods for AsActionResult (and whatever other MVC methods need to be moved) and have that NuGet package install the right stuff based on the MVC version used by the receiving project.

@panterlo

This comment has been minimized.

Copy link
Author

commented Sep 26, 2013

Yeah, understood, I further investigated yesterday and came to same conclusion. I recompiled the 4.3.1 this morning without the AllowPartiallyTrustedCallers (we don't run on shared hosting so it's not an issue). Because delay signing is enabled we also had to sn -Vr * to exclude the verificiation from strong names.

Is there anyway disabling signing completely in all projects without having to go trough the GUI doing all that stuff.

And I agree on the last what you wrote, moving out all MVC related code to separate assembly - that will solve this problem easily.

Thanks for your quick response.

@AArnott

This comment has been minimized.

Copy link
Member

commented Sep 26, 2013

I believe the master branch has already changed the strong name signing key to one that is not encrypted and therefore doesn't use delay signing. Can you use that instead?

@panterlo

This comment has been minimized.

Copy link
Author

commented Sep 27, 2013

You are right, I recompiled the master (removing the AllowPartiallyTrustedCallers attribute) but I have some issues coming down to HandleTokenRequestAsync.

When using the UserAgentClient it comaplains over Unexpected response Content-Type text/html when calling GetClientAccessTokenAsync.

Any ideas ? Will dig deeper meanwhile.

@panterlo

This comment has been minimized.

Copy link
Author

commented Sep 27, 2013

The MVC controllers returns propertly application/json, something goes wrong in UserAgentClient for sure... continue to investigate. I only see only test case in the project so there may be something hitting this problem.

@panterlo

This comment has been minimized.

Copy link
Author

commented Sep 27, 2013

Magic happens here:

private async Task<IAuthorizationState> RequestAccessTokenAsync(ScopedAccessTokenRequest request, IEnumerable<string> scopes, CancellationToken cancellationToken) {
        Requires.NotNull(request, "request");
@panterlo

This comment has been minimized.

Copy link
Author

commented Sep 27, 2013

Ok, found the issue in protected override async Task<IDictionary<string, string>> ReadFromResponseCoreAsync(HttpResponseMessage response, CancellationToken cancellationToken) {
// The spec says direct responses should be JSON objects, but Facebook uses HttpFormUrlEncoded instead, calling it text/plain
// Others return text/javascript. Again bad.
string body = await response.Content.ReadAsStringAsync();
var contentType = response.Content.Headers.ContentType.MediaType;

var contentType = response.Content.Headers.ContentType.MediaType; reports faulty text/html.

@panterlo

This comment has been minimized.

Copy link
Author

commented Sep 27, 2013

The MVC controller returns content-type: application/json. Bu the ReadFromResponseCoreAsync method reports back text/html and I can't see why. Must be something going on into HttpClient not transforming properly. Can somebody take a look at this because this breaks both the UserAgentClient and the WebServerClient.

I have until further resolved it by adding it to the if clause in the method ReadFromResponseCoreAsync:
if (contentType == JsonEncoded || contentType == JsonTextEncoded || contentType == "text/html")
{

After this everything works.

@panterlo panterlo closed this Oct 7, 2013
@panterlo panterlo reopened this Oct 7, 2013
@panterlo panterlo closed this Oct 7, 2013
@panterlo panterlo reopened this Oct 7, 2013
@panterlo

This comment has been minimized.

Copy link
Author

commented Oct 7, 2013

Seems like the text/html response should be resolved #306

@AArnott

This comment has been minimized.

Copy link
Member

commented Oct 9, 2013

Please keep this issue open, tracking the MVC 5 compatibility issue. The contentType issue was a different issue that shouldn't have been brought up here.

@AArnott

This comment has been minimized.

Copy link
Member

commented Oct 9, 2013

I just got an email from the MVC folks that is relevant to this conversation:

Hello,

We have identified you as the owner of a package that depends on packages from the ASP.NET team, and your package may be affected by an upcoming change they have. The ASP.NET team asked us to forward the message below to affected package owners.

If you have any questions about this change, please reply back to Kanchan.

Thank you,
The NuGet Gallery Team.


Greetings,

As you may know we have published the Release Candidates for ASP.NET MVC 5, ASP.NET Web API 2, and ASP.NET Web Pages 3, and the RTM release is nearly complete. This is an important release with many great new features that you can see here: http://www.asp.net/visual-studio/overview/2013/release-notes-(release-candidate). We are contacting you because you are a package author that has a dependency on these frameworks. We would like to bring to your attention that with this major release we have removed the security transparent attribute from our assemblies. This means that packages with assemblies compiled against earlier versions of ASP.NET MVC, ASP.NET Web API, or ASP.NET Web Pages will be broken in certain cases (see examples below) when a customer upgrades to the new versions. We recommend you try our new bits and verify that your package still works as expected in your scenarios.

One specific case where you will be broken is if your assembly includes either of the following attributes:
• [assembly:AllowPartiallyTrustedCallers]
• [assembly:SecurityTransparent]
A common error that you might see is a “System.MethodAccessException” when code in your assembly calls a method in one of our NuGet packages. Another common error is if you have types that derive from a type in one of our NuGet packages.

If you are impacted by this change here is what you need to do:
• Remove the [assembly:SecurityTransparent] and [assembly:AllowPartiallyTrustedCallers] attributes from your code.
• Recompile and republish your NuGet package.

Note, if you would prefer to keep the attribute for packages depending on older versions of MVC, Web API, and Web Pages, and to remove the attribute for packages that depend on MVC 5, Web API 2, and Web Pages 3, you can do the following:
• Update your current package to have a version cap so that it will be compatible with only the old version of our package.
o For example, to have your package be compatible with only MVC 4, use this version range: Microsoft.AspNet.Mvc (≥ 4.0.20710.0 && < 4.1)
• For your new package remove the [assembly:SecurityTransparent] and [assembly:AllowPartiallyTrustedCallers] attributes from your code and recompile your package against the new versions and publish the new package that has a dependency on the new version.
o For example, to have your package be compatible with MVC 5 and higher, use this version range: Microsoft.AspNet.Mvc (≥ 5.0.0)

If you come across any additional issues that we need to address please file a bug on our CodePlex site: https://aspnetwebstack.codeplex.com/workitem/list/advanced

Thanks,
Kanchan Mehrotra (kanchanm@microsoft.com)
Senior Test Lead on the ASP.NET team

@programcsharp

This comment has been minimized.

Copy link

commented Oct 18, 2013

Is there anything I can do to help on this? Any MVC 5 upgrade for projects that use DotNetOpenAuth are basically dead in the water until this is fixed.

I've been trying to get master to build without AllowPartiallyTrustedCallers all day, but having issues getting that to work either. I got it to build, but keep getting this when trying to run:

Duplicate type with name '<DotNetOpenAuth.OpenId.Provider.IProviderBehavior.OnOutgoingResponseAsync>d__0' in assembly 'DotNetOpenAuth, Version=5.1.0.0, Culture=neutral, PublicKeyToken=d0acff3d13b42a9d'.

@programcsharp

This comment has been minimized.

Copy link

commented Oct 18, 2013

I was able to get a working build by munging around with branch v4.3 a bit, removing AllowPartiallyTrustedCallers, and replacing the signing there with the signing from master branch.

I can contribute that build (or the diff) back as a stopgap if the owners are interested.

@AArnott

This comment has been minimized.

Copy link
Member

commented Oct 19, 2013

No active development is going into the project at this point. I was the
primary developer for years and stepped down a few months ago. No one else
has stepped up.

Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre

On Fri, Oct 18, 2013 at 3:10 PM, Chris Hynes notifications@github.comwrote:

I was able to get a working build by munging around with branch v4.3 a
bit, removing AllowPartiallyTrustedCallers, and replacing the signing there
with the signing from master branch.

I can contribute that build (or the diff) back as a stopgap if the owners
are interested.


Reply to this email directly or view it on GitHubhttps://github.com//issues/307#issuecomment-26633728
.

@panterlo

This comment has been minimized.

Copy link
Author

commented Oct 19, 2013

programcsharp I am sending you an e-mail how I did get this working properly.

@AndreiMaz

This comment has been minimized.

Copy link

commented Oct 19, 2013

Hi Andrew,

You created a great project. It's used by thousands by users. But now it's not compatible with MVC 5. And it'll just die if it won't be fixed. Could you please fix this issue in the near time? Furthremore, MS team already sent you the list of steps on how to make it compatible

Regards,
Andrei

@AArnott

This comment has been minimized.

Copy link
Member

commented Oct 19, 2013

Perhaps I will. I can't promise though, as I left the project because my
time is very limited.

Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre

On Sat, Oct 19, 2013 at 8:46 AM, Andrei Mazoulnitsyn <
notifications@github.com> wrote:

Hi Andrew,

You created a great project. It's used by thousands by users. But now it's
not compatible with MVC 5. And it'll just die if it won't be fixed. Could
you please fix this issue in the near time? Furthremore, MS team already
sent you the list of steps on how to make it compatible

Regards,
Andrei


Reply to this email directly or view it on GitHubhttps://github.com//issues/307#issuecomment-26652291
.

@AndreiMaz

This comment has been minimized.

Copy link

commented Oct 19, 2013

Hi Andrew,

Thanks a lot for the quick reply. Yes, please do it. This is the only fix the community needs. No other changes or enhancements are required.

P.S. Only our project (nopCommerce) has more than 15,000 live sites using DotNetOpenAuth. And I think there are millions of others users using DotNetOpenAuth. We all need this fix and really appreciate if you could fix time for it.

Thanks,
Andrei

@AArnott

This comment has been minimized.

Copy link
Member

commented Oct 19, 2013

What version of DNOA would you like fixed for MVC 5? DNOA 5 (the beta) or
the latest stable 4.x release?

Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre

On Sat, Oct 19, 2013 at 9:03 AM, Andrei Mazoulnitsyn <
notifications@github.com> wrote:

Hi Andrew,

Thanks a lot for the quick reply. Yes, please do it. This is the only fix
the community needs. No other changes or enhancements are required.

P.S. Only our project (nopCommerce) has more than 15,000 live sites using
DotNetOpenAuth. And I think there are millions of others users using
DotNetOpenAuth. We all need this fix and really appreciate if you could fix
time for it.

Thanks,
Andrei


Reply to this email directly or view it on GitHubhttps://github.com//issues/307#issuecomment-26652663
.

@AndreiMaz

This comment has been minimized.

Copy link

commented Oct 19, 2013

The one which is is available via nuGet (I presume the latest stable)

Regards,
Andrei

@AndreiMaz

This comment has been minimized.

Copy link

commented Oct 19, 2013

One more thing related to the previous reply. Could you also please update nuGet packages once it's fixed.

Thanks,
Andrei

@AArnott

This comment has been minimized.

Copy link
Member

commented Oct 19, 2013

They're both available. But the unstable release requires that you "Include
Prerelease" in nuget to get it.
As the fix will be a breaking change, I don't think the v4.x versions are
appropriate for this fix. So you may want to start scouting out DNOA v5 to
see how much of a breaking change it would be for you.

Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre

On Sat, Oct 19, 2013 at 9:19 AM, Andrei Mazoulnitsyn <
notifications@github.com> wrote:

The one which is is available via nuGet (I presume the latest stable)

Regards,
Andrei


Reply to this email directly or view it on GitHubhttps://github.com//issues/307#issuecomment-26653063
.

@AArnott

This comment has been minimized.

Copy link
Member

commented Oct 19, 2013

Yes, updating the NuGet packages with the fix goes without sayin'. :)

Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre

On Sat, Oct 19, 2013 at 9:20 AM, Andrei Mazoulnitsyn <
notifications@github.com> wrote:

One more thing related to the previous reply. Could you also please update
nuGet packages once it's fixed.

Thanks,
Andrei


Reply to this email directly or view it on GitHubhttps://github.com//issues/307#issuecomment-26653077
.

@AndreiMaz

This comment has been minimized.

Copy link

commented Oct 19, 2013

Great. Thanks a lot. Please update ANY version which is possible so we can update our references using nuGet.

@programcsharp

This comment has been minimized.

Copy link

commented Oct 20, 2013

What if we remove [APTC] from the current 4.3 package and then make a new 4.3-PartiallyTrusted package? That would make most people's MVC5 upgrades go smoothly, but allow people that need partial trust to switch over to the other package.

Doing the fix would be fairly easy:

  • Change the current 4.3 package to build with SignAssembly=false and DelaySign=false by default (which will also remove the [APTC] attribute because of the conditional compilation)
  • Sign that output after build, a la v5
  • Create a new 4.3-PartiallyTrusted package that builds with the old defaults

I can submit a patch for the first item (that's basically what I did to get a working build), but I'm not familiar enough with the build process to do the rest of the fix.

NOTE: I noticed that 4.3 with SignAssembly=false is missing a few InternalsVisibleTo attributes in a couple places, but that is simple to fix -- I can contribute a patch for that too.

@AArnott AArnott closed this in 64f683a Oct 20, 2013
@AArnott

This comment has been minimized.

Copy link
Member

commented Oct 20, 2013

I am also preparing a fix for v4.3.

@AndreiMaz

This comment has been minimized.

Copy link

commented Oct 20, 2013

Andrew,

Thanks a lot for so quick response and the fix. Highly appreciated!

Regards,
Andrei

AArnott added a commit that referenced this issue Oct 20, 2013
By installing this optional package, MVC5 customers can change their
AsActionResult() extension methods to instead use:
AsActionResultMvc5().
All other code remains the same and it fixes the MVC 5 break for DNOA.

Fixes #307
Merge branch 'MVCDependency' into v4.3
@AArnott

This comment has been minimized.

Copy link
Member

commented Oct 20, 2013

Fix for NuGet package users:

  1. Run the following NuGet command

    Install-Package DotNetOpenAuth.Mvc5

  2. Change all uses of AsActionResult() to AsActionResultMvc5()

@AndreiMaz

This comment has been minimized.

Copy link

commented Oct 21, 2013

I cannot find this DotNetOpenAuth.Mvc5 package in nuget

@panterlo

This comment has been minimized.

Copy link
Author

commented Oct 21, 2013

Did you use nuget.org repository because it's working for me:
PM> Install-Package DotNetOpenAuth.Mvc5

@AndreiMaz

This comment has been minimized.

Copy link

commented Oct 21, 2013

Oops, was searching in wrong place (updates). Everything is fine. Found it

@AndreiMaz

This comment has been minimized.

Copy link

commented Oct 21, 2013

Andrew,

I've just tested the packages. Everything works fine. Thanks a lot. Please let me know your PayPal email and I'll send you some beer

Regards,
Andrei

@alastairs

This comment has been minimized.

Copy link

commented Oct 21, 2013

An additional problem is that the DotNetOpenAuth.Mvc5 package requires DNOA.Core v4.3.2.13293, so this package doesn't work with the DNOA v5 alpha. Is this intentional?

@AArnott

This comment has been minimized.

Copy link
Member

commented Oct 21, 2013

The v5.0 fix is slightly different and I'll be publishing the fix for it as
well soon.
On Oct 21, 2013 1:32 AM, "Alastair Smith" notifications@github.com wrote:

An additional problem is that the DotNetOpenAuth.Mvc5 package requires
DNOA.Core v4.3.2.13293, so this package doesn't work with the DNOA v5
alpha. Is this intentional?


Reply to this email directly or view it on GitHubhttps://github.com//issues/307#issuecomment-26700089
.

@AArnott

This comment has been minimized.

Copy link
Member

commented Oct 21, 2013

Thanks Andrei. My address is AndrewArnott@gmail.Com
On Oct 20, 2013 11:46 PM, "Andrei Mazoulnitsyn" notifications@github.com
wrote:

Andrew,

I've just tested the packages. Everything works fine. Thanks a lot. Please
let me know your PayPal email and I'll send you some beer

Regards,
Andrei


Reply to this email directly or view it on GitHubhttps://github.com//issues/307#issuecomment-26695661
.

@AndreiMaz

This comment has been minimized.

Copy link

commented Oct 21, 2013

Andrew,

sent

@koichia

This comment has been minimized.

Copy link

commented Oct 21, 2013

Hi Andrew,

Just wanted to say thanks for taking time to do the updates!

I tested the v4.3 + MVC5, and works great.

@AArnott

This comment has been minimized.

Copy link
Member

commented Oct 22, 2013

The DNOA v5.0-alpha2 version is now available on NuGet with the fix.
The AsActionResult() extension method is available by installing the
DotNetOpenAuth.Mvc package.

Note that the v4.x branch builds an DotNetOpenAuth.Mvc5 package that has an
AsActionResultMvc5() extension method,
while the v5.0 versions build an DotNetOpenAuth.Mvc package that has an
AsActionResult() extension method.

Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre

On Mon, Oct 21, 2013 at 2:32 PM, koichia notifications@github.com wrote:

Hi Andrew,

Just wanted to say thanks for taking time to do the updates!

I tested the v4.3 + MVC5, and works great.


Reply to this email directly or view it on GitHubhttps://github.com//issues/307#issuecomment-26758807
.

@alastairs

This comment has been minimized.

Copy link

commented Oct 22, 2013

Thanks @AArnott, much appreciated. I updated my site to MVC 5 (not Web API 2), then DotNetOpenAuth 5.0-alpha2. This all went through ok. I'm now trying to update my site to Web API 2 which is failing with the following message:

Updating 'Microsoft.AspNet.WebApi.Client 4.1.0-alpha-120809' to 'Microsoft.AspNet.WebApi.Client 5.0.0' failed. Unable to find a version of 'DotNetOpenAuth.OAuth2.Client' that is compatible with 'Microsoft.AspNet.WebApi.Client 5.0.0.'

Any thoughts on what's going on here? I'm still listing prerelease packages, so it should in theory be able to try to resolve the dependency with the 5.0-alpha2 packages too.

@AArnott

This comment has been minimized.

Copy link
Member

commented Oct 23, 2013

The DotNetOpenAuth.OAuth2.Client package is compiled against
AspNet.WebApi.Client 4.0. Semantic versioning suggests that 5.0 has
breaking changes in it (thus driving the major version increment). So DNOA
would likely need a recompile in order to work with it.

Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre

On Tue, Oct 22, 2013 at 11:10 AM, Alastair Smith
notifications@github.comwrote:

Thanks @AArnott https://github.com/AArnott, much appreciated. I updated
my site to MVC 5 (not Web API 2), then DotNetOpenAuth 5.0-alpha2. This all
went through ok. I'm now trying to update my site to Web API 2 which is
failing with the following message:

Updating 'Microsoft.AspNet.WebApi.Client 4.1.0-alpha-120809' to
'Microsoft.AspNet.WebApi.Client 5.0.0' failed. Unable to find a version of
'DotNetOpenAuth.OAuth2.Client' that is compatible with
'Microsoft.AspNet.WebApi.Client 5.0.0.'

Any thoughts on what's going on here? I'm still listing prerelease
packages, so it should in theory be able to try to resolve the
dependency with the 5.0-alpha2 packages too.


Reply to this email directly or view it on GitHubhttps://github.com//issues/307#issuecomment-26827467
.

@AArnott

This comment has been minimized.

Copy link
Member

commented Oct 23, 2013

Hmmm... on closer inspection it looks like that's not true. DNOA actually
compiles against WebApi.Client 5.0 now. I'll update the packages.

Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre

On Tue, Oct 22, 2013 at 8:48 PM, Andrew Arnott andrewarnott@gmail.comwrote:

The DotNetOpenAuth.OAuth2.Client package is compiled against
AspNet.WebApi.Client 4.0. Semantic versioning suggests that 5.0 has
breaking changes in it (thus driving the major version increment). So DNOA
would likely need a recompile in order to work with it.

Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre

On Tue, Oct 22, 2013 at 11:10 AM, Alastair Smith <notifications@github.com

wrote:

Thanks @AArnott https://github.com/AArnott, much appreciated. I
updated my site to MVC 5 (not Web API 2), then DotNetOpenAuth 5.0-alpha2.
This all went through ok. I'm now trying to update my site to Web API 2
which is failing with the following message:

Updating 'Microsoft.AspNet.WebApi.Client 4.1.0-alpha-120809' to
'Microsoft.AspNet.WebApi.Client 5.0.0' failed. Unable to find a version of
'DotNetOpenAuth.OAuth2.Client' that is compatible with
'Microsoft.AspNet.WebApi.Client 5.0.0.'

Any thoughts on what's going on here? I'm still listing prerelease
packages, so it should in theory be able to try to resolve the
dependency with the 5.0-alpha2 packages too.


Reply to this email directly or view it on GitHubhttps://github.com//issues/307#issuecomment-26827467
.

@alastairs

This comment has been minimized.

Copy link

commented Oct 23, 2013

I managed to upgrade to the 5.0-alpha3 packages (and subsequently Web API 2) without any further difficulties - thanks so much @AArnott.

@breath2k

This comment has been minimized.

Copy link

commented Oct 30, 2013

On trying to update Nuget package I got:
Install failed. Rolling back...
Updating 'DotNetOpenAuth.Core 5.0.0-alpha3' to 'DotNetOpenAuth.Core 4.3.3.13295' failed. Unable to find versions of 'DotNetOpenAuth.Mvc, DotNetOpenAuth.Core.UI, DotNetOpenAuth.OpenId.Core, DotNetOpenAuth.OAuth.Core, DotNetOpenAuth.OAuth.Common, DotNetOpenAuth.OAuth2.Core' that are compatible with 'DotNetOpenAuth.Core 4.3.3.13295'.
Are you able to help please?

@mgravell

This comment has been minimized.

Copy link

commented Dec 10, 2013

The current v5 alpha build pre-dates some security fixes from the end of November; is there any plan to update the v5 alpha build?

@jasmeetsangari

This comment has been minimized.

Copy link

commented May 13, 2015

Hi Guys,

I am Using the Nuget Package DotNetOpenAuth.Ultimate 4.3.4.13329 and MVC 5.2.3 I changed to using AsActionResultMvc5 method the exception I get is:

Attempt by security transparent method 'DotNetOpenAuth.Messaging.MessagingUtilities.AsActionResult(DotNetOpenAuth.Messaging.OutgoingWebResponse)' to access security critical type 'System.Web.Mvc.ActionResult' failed.

Assembly 'DotNetOpenAuth, Version=4.3.0.0, Culture=neutral, PublicKeyToken=2780ccd10d57b246' is marked with the AllowPartiallyTrustedCallersAttribute, and uses the level 2 security transparency model. Level 2 transparency causes all methods in AllowPartiallyTrustedCallers assemblies to become security transparent by default, which may be the cause of this exception.

@john-warpdevelopment

This comment has been minimized.

Copy link

commented Jan 29, 2016

I get an the following error when trying to use reflection on a project that references openauth.

Inheritance security rules violated by type: 'DotNetOpenAuth.Messaging.OutgoingWebResponseActionResult'. Derived types must either match the security accessibility of the base type or be less accessible.":"DotNetOpenAuth.Messaging.OutgoingWebResponseActionResult

I do have the DotNetOpenAuth.Mvc5 package referenced, so I'm running out of ideas.

@gkverneland

This comment has been minimized.

Copy link

commented Feb 20, 2017

@AArnott do you have any news? Do you know why DotNetOpenAuth 5.0.0-alpha3 (from October '13) is still not stable?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
You can’t perform that action at this time.