Castle.ActiveRecord.dll not compatible with ASP.NET MVC 4 Web API - wcf-web-api

MSFT claims that .NET 4.5 is backwards compatible with .NET 4. I went ahead and installed .NET 4.5 and VS 11, then created a new ASP.NET MVC 4 Web API project. When I reference the Castle.ActiveRecord.dll (version 3.0.0.0) into my Web API project, every controller action then generates this error:
[FileNotFoundException: Could not load file or assembly 'Lucene.Net, Version=2.3.1.3, Culture=neutral, PublicKeyToken=45b1dda587cdc860' or one of its dependencies. The system cannot find the file specified.]
System.Reflection.RuntimeAssembly.GetExportedTypes(RuntimeAssembly assembly, ObjectHandleOnStack retTypes) +0
System.Reflection.RuntimeAssembly.GetExportedTypes() +49
System.Web.Http.Dispatcher.HttpControllerTypeCacheUtil.FilterTypesInAssemblies(IBuildManager buildManager, Predicate`1 predicate) +210
System.Web.Http.Dispatcher.HttpControllerTypeCache.InitializeCache() +119
System.Web.Http.Dispatcher.HttpControllerTypeCache..ctor(HttpConfiguration configuration) +69
System.Web.Http.Services.DefaultServiceResolver.<.ctor>b__0(HttpConfiguration config) +241
System.Web.Http.Services.DefaultServiceResolver.GetService(Type t) +80
System.Web.Http.DependencyResolverExtensions.GetService(DependencyResolver resolver) +201
System.Web.Http.DependencyResolverExtensions.GetServiceOrThrow(DependencyResolver resolver) +60
System.Web.Http.Dispatcher.HttpControllerDispatcher..ctor(HttpConfiguration configuration) +65
System.Web.Http.GlobalConfiguration.<.cctor>b__1() +64
System.Lazy`1.CreateValue() +13589652
System.Lazy`1.LazyInitValue() +476
System.Web.Http.WebHost.HttpControllerHandler.<.cctor>b__b() +53
System.Lazy`1.CreateValue() +455
System.Lazy`1.get_Value() +13590694
System.Web.Http.WebHost.HttpControllerHandler.BeginProcessRequest(HttpContextBase httpContextBase, AsyncCallback callback, Object state) +224
System.Web.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +444
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +354
This is interesting because from what I read. the version 2.3.1.3 is a Lucene (java) version, not a Lucene.Net version. I checked NuGet just to be sure, and it has no version 2.3.1.3 available for Lucene.Net.
What gives? I'd love to get running with the new ASP.NET MVC 4 Web API project, as it blends what I love about ASP.NET MVC and WCF Web API. Any ideas as to how to get around this issue?

I posted the solution on asp.net forums where the question originated.
http://forums.asp.net/post/4861300.aspx

Related

ASP.NET core 3.1 :Adding Classes Libraries to the Project_ MissingMethodException: Method not found: 'Boolean Microsoft.EntityFrameworkCore.Migrations

I'm working on asp.net-core 3.1 project, I have added 3 Class Library for my project to separate Access Data, Models class and Utility classes I resolved problems of matching folders etc. But when I run my project I get this Error:
MissingMethodException: Method not found: 'Boolean Microsoft.EntityFrameworkCore.Migrations.IMigrationsModelDiffer.HasDifferences(Microsoft.EntityFrameworkCore.Metadata.IModel, Microsoft.EntityFrameworkCore.Metadata.IModel)'.
Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore.DatabaseErrorPageMiddleware.Invoke(HttpContext
httpContext)
System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start<TStateMachine>(ref TStateMachine
stateMachine)
System.Runtime.CompilerServices.AsyncTaskMethodBuilder.Start<TStateMachine>(ref TStateMachine
stateMachine)
Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore.DatabaseErrorPageMiddleware.Invoke(HttpContext
httpContext)
Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware.Invoke(HttpContext context)
For me, the answer was to make sure all of my EF packages were pointing at the same 3.1.X version. I had inadvertently targeted a 5.0.0 EF package that included the missing method:
https://learn.microsoft.com/en-us/dotnet/api/microsoft.entityframeworkcore.migrations.imigrationsmodeldiffer.hasdifferences?view=efcore-5.0
A straight forward fix for me in Dotnet core 3.1 is to comment out
app.UseDatabaseErrorPage();
in the startup.cs file Configure Method
I found a solution can Help for ERROR:
MissingMethodException: Method not found: 'Boolean Microsoft.EntityFrameworkCore.Migrations.IMigrationsModelDiffer.HasDifferenc
https://github.com/dotnet/efcore/issues/22687

TypeLoadException exception on signout after upgrading to aspnet core 3.1

I use IdentityServer4 for auth which gets installed with Asp.net core web project in visual studio 2019. After upgrading to asp.net 3.1, I get below error on SignOut. I tried force update all the Nugets to latest. Still, I couldn't make it work. Appreciate any workaround.
TypeLoadException: Could not load type 'Microsoft.AspNetCore.Http.IReadableStringCollectionExtensions' from assembly 'IdentityServer4, Version=3.1.0.0, Culture=neutral, PublicKeyToken=f294d0afe402bb2b'.
Microsoft.AspNetCore.ApiAuthorization.IdentityServer.AutoRedirectEndSessionEndpoint.GetParametersAsync(HttpRequest request)
System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start<TStateMachine>(ref TStateMachine stateMachine)
System.Runtime.CompilerServices.AsyncTaskMethodBuilder<TResult>.Start<TStateMachine>(ref TStateMachine stateMachine)
Microsoft.AspNetCore.ApiAuthorization.IdentityServer.AutoRedirectEndSessionEndpoint.GetParametersAsync(HttpRequest request)
Microsoft.AspNetCore.ApiAuthorization.IdentityServer.AutoRedirectEndSessionEndpoint.ProcessAsync(HttpContext ctx)
IdentityServer4.Hosting.IdentityServerMiddleware.Invoke(HttpContext context, IEndpointRouter router, IUserSession session, IEventService events)
IdentityServer4.Hosting.IdentityServerMiddleware.Invoke(HttpContext context, IEndpointRouter router, IUserSession session, IEventService events)
IdentityServer4.Hosting.MutualTlsTokenEndpointMiddleware.Invoke(HttpContext context, IAuthenticationSchemeProvider schemes)
Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context)
IdentityServer4.Hosting.BaseUrlMiddleware.Invoke(HttpContext context)
Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context)
Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore.MigrationsEndPointMiddleware.Invoke(HttpContext context)
Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore.DatabaseErrorPageMiddleware.Invoke(HttpContext httpContext)
Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore.DatabaseErrorPageMiddleware.Invoke(HttpContext httpContext)
Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware.Invoke(HttpContext context)
I fixed this by reverting the IdentityServer4.EntityFramework reference from version 3.1.0 to 3.0.2, it would seem that the missing type is not yet implemented in 3.1.0.
I spent a few days researching this for work and I was unable to find any official documentation with regards to the problem or to the missing type. So the solution came from exasperation more than anything else. I apologize that I cannot provide you with adequate reasoning as to why it needs to be reverted, just that by doing it I fixed it.
for me
I have DAL has
IdentityServer4.EntityFramework and IdentityServer4
also the layer of ClientSlide has IdentityServer4 package changes all them to 3.0.2 instead of 3.1.0 solves the issue
For me the problem was resolved by uninstalling the Nuget package IdentityServer4 version 3.1.1 and letting the framework use the builtin one with version 3.0.0.

Upgrading Virtocommerce from 2.9 to 2.10 - CacheManager Issue

I recently performed the following steps on my VirtoCommerce Site:
Updated my Local Environment from 2.9 to 2.10 via Git.
Publish to Azure the Manager App. (Overwriting 2.9 on Azure)
Publish to Azure the Storefront. (Overwriting 2.9 on Azure)
I got a Typeload error that LibSass_64 couldnt be loaded. Realised my Dev Machine is x64 but the Azure server is x86, so I changed the Build configs in both solutions to x86 and republished with the "remove existing files" setting to clear the x64 dlls.
That solved the typeload error. However now I am getting the following error I am unable to resolve without help. Any help will be greatly appreciated!
Error calling StoreModuleGetStores:
Could not load type 'CacheManager.Core.RuntimeCachingBuilderExtensions' from assembly 'CacheManager.SystemRuntimeCaching, Version=0.7.1.0, Culture=neutral, PublicKeyToken=null'
Exception has been thrown by the target of an invocation.]
System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor) +0
System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj,Object[] parameters, Object[] arguments) +92
System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture) +101
Owin.Loader.<>c__DisplayClass12.<MakeDelegate>b__b(IAppBuilder builder) +66
Owin.Loader.<>c__DisplayClass1.<LoadImplementation>b__0(IAppBuilder builder) +123
Microsoft.Owin.Host.SystemWeb.<>c__DisplayClass2.<InitializeBlueprint>b__0(IAppBuilder builder) +71
Microsoft.Owin.Host.SystemWeb.OwinAppContext.Initialize(Action`1 startup) +462
Microsoft.Owin.Host.SystemWeb.OwinBuilder.Build(Action`1 startup) +40
Microsoft.Owin.Host.SystemWeb.OwinHttpModule.InitializeBlueprint() +70
System.Threading.LazyInitializer.EnsureInitializedCore(T& target, Boolean& initialized, Object& syncLock, Func`1 valueFactory) +115
Microsoft.Owin.Host.SystemWeb.OwinHttpModule.Init(HttpApplication context) +106
System.Web.HttpApplication.RegisterEventSubscriptionsWithIIS(IntPtr appContext, HttpContext context, MethodInfo[] handlers) +534
System.Web.HttpApplication.InitSpecial(HttpApplicationState state, MethodInfo[] handlers, IntPtr appContext, HttpContext context) +172
System.Web.HttpApplicationFactory.GetSpecialApplicationInstance(IntPtr appContext, HttpContext context) +352
System.Web.Hosting.PipelineRuntime.InitializeApplication(IntPtr appContext) +296
You should not change the build platform. Everything should be compiled for "Any CPU" platform.
The original issue with LibSass_64 has happened because the publishing process has copied LibSass.x64.dll and libsassnet.dll to the bin directory. These assemblies should be deleted from bin and there is a special action in the storefront project to do this. Unfortunately the publishing process either doesn't run this action or copies libsass assemblies to the bin anyway. Need to sort this out.
At the same time the bin directory should contain the LibSassNetProxy.dll, which will load the correct version of libsass assemblies from App_Data directory depending on the platform at runtime.

Asp.Net 5 MVC 6 Startup.cs Assembly Decoupling in Beta8

I am working on an eCommerce site using Asp.Net 5 and MVC6 following Onion Architecture (OA) so that we have loose coupling between the layers. I also want to decouple Startup code in its own assembly rather than having it in the MVC project.
In beta7 It was very easy to move the Startup.cs to a class library (Bootstrapper) as explained here. One interesting fact using the mentioned approach is that I didn't have to reference the Bootstrapper assembly from the MVC project. At runtime, hosting under IISExpress, through assembly scanning it was able to find the Bootstrapper assembly mentioned in the Microsoft.AspNet.Hosting.ini file. This was possible by specifying the location in the global.json
{
"projects": [ "Source/Projects","Source/Bootstrapper" ],
"sdk": {
"architecture": "x64",
"runtime": "clr",
"version": "1.0.0-beta7"
}
}
The Bootstrapper project will have reference to all other projects like Infrastructure, Services etc in order to hook up Dependency Injection.
The reason for not referencing the Bootstrapper project in MVC project, following Onion Architecture rules, is to avoid having access to Infrastructure code directly from MVC project. So this was all working fine until I upgraded to Beta8 this morning.
As the hosting model is changed from IIS to Kestrel, I had to refactor the global.json and project.json files as below
global.json
{
"projects": [ "Source/Projects","Source/Bootstrapper" ],
"sdk": {
"architecture": "x64",
"runtime": "clr",
"version": "1.0.0-beta8"
}
}
project.json
{
"dependencies": {
"Microsoft.AspNet.IISPlatformHandler": "1.0.0-beta8",
"Microsoft.AspNet.Server.Kestrel": "1.0.0-beta8",
"....",
"....",
},
"commands": {
"web": "Microsoft.AspNet.Server.Kestrel"
}
}
After making the above changes, I started getting the following error regardless whether I run it using dnx command or directly via Visual Studio
Internal Server Error System.InvalidOperationException A
type named 'StartupDevelopment' or 'Startup' could not be found in
assembly 'EcommerceMvcApp'. at
Microsoft.AspNet.Hosting.Startup.StartupLoader.FindStartupType(String
startupAssemblyName, IList diagnosticMessages) at
Microsoft.AspNet.Hosting.Internal.HostingEngine.EnsureStartup() at
Microsoft.AspNet.Hosting.Internal.HostingEngine.EnsureApplicationServices()
at Microsoft.AspNet.Hosting.Internal.HostingEngine.BuildApplication()
Turned out that I have to specify the config file or inline arguments to the web command as explained here. After following the suggestion, I tried running the application and this time I started getting the error below
System.IO.FileNotFoundException Could not load file or assembly
'Bootstrapper' or one of its dependencies. The system cannot find the
file specified. at
System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String
codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint,
StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean
throwOnFileNotFound, Boolean forIntrospection, Boolean
suppressSecurityChecks) at
System.Reflection.RuntimeAssembly.nLoad(AssemblyName fileName, String
codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint,
StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean
throwOnFileNotFound, Boolean forIntrospection, Boolean
suppressSecurityChecks) at
System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName
assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly,
StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean
throwOnFileNotFound, Boolean forIntrospection, Boolean
suppressSecurityChecks) at
System.Reflection.Assembly.Load(AssemblyName assemblyRef) at
Microsoft.AspNet.Hosting.Startup.StartupLoader.FindStartupType(String
startupAssemblyName, IList diagnosticMessages) at
Microsoft.AspNet.Hosting.Internal.HostingEngine.EnsureStartup() at
Microsoft.AspNet.Hosting.Internal.HostingEngine.EnsureApplicationServices()
at Microsoft.AspNet.Hosting.Internal.HostingEngine.BuildApplication()
The solution requires that I add a reference to the Bootstrapper project in the MVC project and it works. However, it defeats the purpose of having a separate Bootstrapper assembly in the first place.
The question is, why it is unable to find the Bootstrapper assembly like it used to do in Beta7, using the sources specified under "projects" in global.json or is the new hosting model ignoring the global.json? Is there a way to specify the location of the Startup assembly?
Update 1
Just want to highlight that in Beta7 it also works using "dnx command" for both Microsoft.AspNet.Server.WebListener and Microsoft.AspNet.Server.Kestrel.
"commands": {
"kestrel": "Microsoft.AspNet.Hosting --server Microsoft.AspNet.Server.Kestrel --server.urls http://localhost:5004 --config wwwroot/Microsoft.AspNet.Hosting.ini",
"web": "Microsoft.AspNet.Hosting --server Microsoft.AspNet.Server.WebListener --server.urls http://localhost:5004 --config wwwroot/Microsoft.AspNet.Hosting.ini"
}
However, the dnx command (using Microsoft.AspNet.Hosting.json file) fails for both servers in Beta8. If someone is wondering that it's something to do with IIS Helios component in Beta7, it's not the case. I am baffled as why the assembly lookup stopped working in Beta8
Update 2
Here is the stack trace that I get when I try to run in Beta8 using IISExpress. Looks like it's trying to find the assembly in the dnx bin folder.
System.IO.FileNotFoundException: Could not load file or assembly
'Bootstrapper' or one of its dependencies. The system cannot find the
file specified. File name: 'Bootstrapper' at
System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String
codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint,
StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean
throwOnFileNotFound, Boolean forIntrospection, Boolean
suppressSecurityChecks) at
System.Reflection.RuntimeAssembly.nLoad(AssemblyName fileName, String
codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint,
StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean
throwOnFileNotFound, Boolean forIntrospection, Boolean
suppressSecurityChecks) at
System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName
assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly,
StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean
throwOnFileNotFound, Boolean forIntrospection, Boolean
suppressSecurityChecks) at
System.Reflection.Assembly.Load(AssemblyName assemblyRef) at
Microsoft.AspNet.Hosting.Startup.StartupLoader.FindStartupType(String
startupAssemblyName, IList`1 diagnosticMessages) at
Microsoft.AspNet.Hosting.Internal.HostingEngine.EnsureStartup() at
Microsoft.AspNet.Hosting.Internal.HostingEngine.EnsureApplicationServices()
at Microsoft.AspNet.Hosting.Internal.HostingEngine.BuildApplication()
=== Pre-bind state information === LOG: DisplayName = Bootstrapper (Partial) WRN: Partial binding information was supplied for an
assembly: WRN: Assembly Name: Bootstrapper | Domain ID: 1 WRN: A
partial bind occurs when only part of the assembly display name is
provided. WRN: This might result in the binder loading an incorrect
assembly. WRN: It is recommended to provide a fully specified textual
identity for the assembly, WRN: that consists of the simple name,
version, culture, and public key token. WRN: See whitepaper
http://go.microsoft.com/fwlink/?LinkId=109270 for more information and
common solutions to this issue. LOG: Appbase =
file:///C:/Users/sshassan/.dnx/runtimes/dnx-clr-win-x86.1.0.0-beta8/bin/
LOG: Initial PrivatePath = NULL Calling assembly : (Unknown).
=== LOG: This bind starts in default load context. LOG: No application configuration file found. LOG: Using host configuration file: LOG:
Using machine configuration file from
C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Policy not being applied to reference at this time (private,
custom, partial, or location-based assembly bind). LOG: Attempting
download of new URL
file:///C:/Users/sshassan/.dnx/runtimes/dnx-clr-win-x86.1.0.0-beta8/bin/Bootstrapper.DLL.
LOG: Attempting download of new URL
file:///C:/Users/sshassan/.dnx/runtimes/dnx-clr-win-x86.1.0.0-beta8/bin/Bootstrapper/Bootstrapper.DLL.
LOG: Attempting download of new URL
file:///C:/Users/sshassan/.dnx/runtimes/dnx-clr-win-x86.1.0.0-beta8/bin/Bootstrapper.EXE.
LOG: Attempting download of new URL
file:///C:/Users/sshassan/.dnx/runtimes/dnx-clr-win-x86.1.0.0-beta8/bin/Bootstrapper/Bootstrapper.EXE.
Perhaps, if I run dnu publish and host it under IIS it will work, but that means that I would have to publish it every time I make the change
I was stuck in a similar problem. It looks like we do not want to make references from UI layer to Infraestructure layer (we are very stricts), not even for making the dependency resolution.
Maybe it is possible by using late binding (I just heard talked about it), but I think that you should read this article. It basically says that a Composition Root isn't reusable, and there should be one per application (i.e., one for UI.Web, another for UI.Console, and so on).
That responds also my question about what having the DI resolution in UI.Web, but need another UI, let's say Console (answer: it's preferable to make anoter DI resolution in Console, and it'll have it's own resolution dependences related to how a Console Application actually works).
I hope having give you a good point to clarify this issue.
The hosting config file format changed from INI to Json. Try this:
{
"Hosting:Application": "Bootstrapper",
}
Also see this issue.

Windows Azure intermittent Identity error when parsing webconfig

This issue happens seemingly randomly after publishing.
The site will work fine and then bam, I get this error parsing the webconfig. I just republish and it works fine for a bit again. When publishing, I checked the box to remove existing files so there shouldn't be garbage laying around.
This is an MVC4 project using .net 4.5 and Azure Access Control Service (ACS) integrated with Yahoo!. This error occurs when redirecting back from Yahoo. This way happening every time, but I found a post (which I can not find now, of course) where there was a bug with the 4.5.1 Identity and Access Visual Studio integration. I went to the previous version and now it's only sometimes.
ID8030: The value of the 'type' property could not be parsed.
Verify that the type attribute of '<issuerNameRegistry type="System.IdentityModel.Tokens.ValidatingIssuerNameRegistry, System.IdentityModel.Tokens.ValidatingIssuerNameRegistry"><authority name="[my authority]"><keys><add thumbprint="[print]" /></keys><validIssuers><add name="[issuer]" /></validIssuers></authority></issuerNameRegistry>' element is correct.
In the above error message, I have replaced the items in brackets ([]) for this post.
Here is the stack trace:
[TypeLoadException: ID8030: The value of the 'type' property could not be parsed. *** element is correct.]
System.IdentityModel.Configuration.TypeResolveHelper.Resolve(ConfigurationElementInterceptor customTypeElement, Type customType) +602659
System.IdentityModel.Configuration.IdentityConfiguration.GetIssuerNameRegistry(IssuerNameRegistryElement element) +114
System.IdentityModel.Configuration.IdentityConfiguration.LoadHandlerConfiguration(IdentityConfigurationElement element) +841
System.IdentityModel.Configuration.IdentityConfiguration.LoadConfiguration(IdentityConfigurationElement element) +117
System.IdentityModel.Configuration.IdentityConfiguration..ctor(String identityConfigurationName) +180
System.IdentityModel.Services.Configuration.FederationConfiguration.LoadConfiguration(FederationConfigurationElement element) +392
System.IdentityModel.Services.Configuration.FederationConfiguration..ctor(Boolean loadConfig) +94
System.IdentityModel.Services.FederatedAuthentication.CreateFederationConfiguration() +71
System.IdentityModel.Services.FederatedAuthentication.get_FederationConfiguration() +85
System.IdentityModel.Services.HttpModuleBase.Init(HttpApplication context) +56
System.Web.HttpApplication.RegisterEventSubscriptionsWithIIS(IntPtr appContext, HttpContext context, MethodInfo[] handlers) +418
System.Web.HttpApplication.InitSpecial(HttpApplicationState state, MethodInfo[] handlers, IntPtr appContext, HttpContext context) +172
System.Web.HttpApplicationFactory.GetSpecialApplicationInstance(IntPtr appContext, HttpContext context) +336
System.Web.Hosting.PipelineRuntime.InitializeApplication(IntPtr appContext) +296
[HttpException (0x80004005): ***... element is correct.]
System.Web.HttpRuntime.FirstRequestInit(HttpContext context) +9873784
System.Web.HttpRuntime.EnsureFirstRequestInit(HttpContext context) +101
System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerRequest wr, HttpContext context) +254
I had the same issue when running local. I was going through the How-To found here: http://msdn.microsoft.com/en-us/library/jj161104.aspx and would get the type not found error on that assembly.
I double checked to make sure I pulled down the assembly via NuGet and even uninstalled and reinstalled it... no dice. It basically boiled down to a missing reference to the System.IdentityModel.Tokens.ValidatingIssuerNameRegistry
So, if you did pull this down via NuGet and you still have the issue, remember that when NuGet drops this package, it will throw it in a packages folder that's at the solution level in the file system.
If your project doesn’t show a reference to System.IdentityModel.Tokens.ValidatingIssuerNameRegistry, add the assembly to your project by right clicking the project, select Add Reference, Browse, then click the Browse button and then browse up to the packages folder and find the dll ([Your Solution Root]packages\System.IdentityModel.Tokens.ValidatingIssuerNameRegistry.4.5.1\lib\net45) and add it.
I hope this helps.
I ran into the same issue but it was constant for me, not sporadic, so perhaps a different underlying root issue.
I was able to fix the issue though by installing the following NuGet package in my MVC 4 project:
http://www.nuget.org/packages/System.IdentityModel.Tokens.ValidatingIssuerNameRegistry/
I can't remember if this was added by default in a new MVC 4 project. I did at one point remove it so perhaps it may have been removing then reinstalling that resolved the issue. Either way, by adding the package above back I was able to get my MVC 4 project working with ACS correctly.
Hope it works for you as well.
I just had the same problem. One way to solve it is to add a reference to the DLL specified in the other posts.
Another option is to replace the section with this one, that uses a class available in the core .Net Framework 4.5 (you must add a reference to System.IdentityModel too):
<issuerNameRegistry type="System.IdentityModel.Tokens.ConfigurationBasedIssuerNameRegistry, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
<trustedIssuers>
<add thumbprint="[print]" name="[issuer]" />
</trustedIssuers>
</issuerNameRegistry>