I'm getting this runtime exception with Hangfire after upgrading to .NET6
System.TypeLoadException: Could not load type 'System.Collections.Generic.ISet`1' from assembly 'mscorlib, Version=4.0.0.0
at Hangfire.Common.TypeHelper.TypeResolver(Assembly assembly, String typeName, Boolean ignoreCase)
at Hangfire.Common.TypeHelper.DefaultTypeResolver(String typeName)
at System.Linq.Enumerable.SelectArrayIterator`2.ToArray()
at Hangfire.Storage.InvocationData.DeserializeJob()
ISet isn't in mscorlib.dll from what I can tell. It's supposed to be in System.Runtime.dll according to the docs.
Any ideas why Hangfire is doing this? I'm using Hangfire.AspNetCore 1.7.27.
As said in the comments, you should look in your Hangfire database for a serialized parameter featuring a ISet.
It is the deserialization of this parameter which causes the issue, as indicated by :
at Hangfire.Storage.InvocationData.DeserializeJob()
As to the root cause of the problem, I was first thinking that the job had been enqueued with an older version of the framework, while the dequeue attempt was with a newer version of the framework. But this might also be a serialization settings issue, as stated by this older answer
Related
I'm having a frustrating issue with Ninject and MVC 4.
Here is the code block:
Kernel.Bind<IUserInfo>().To<UserInfo().InRequestScope();
var userInfo = Kernel.Get<IUserInfo>();
Most of the time, this is fine, and I have a user info. Sometimes, though, I get the following error:
Error activating IUserInfo
No matching bindings are available, and the Type is not self-bindable.
Activation path:
1) Request for IUserInfo
Suggestions:
1) Ensure that you have defined a binding for IUserInfo.
2) If the binding was defined in a module, ensure that the module has been loaded into the kernel.
3) Ensure you have not accidentally created more than one kernel.
4) If you are using constructor arguments, ensure that the parameter name matches the constructors parameter name.\r\n 5) If you are using automatic module loading, ensure the search path and filters are correct.
I've pared down everything I cant think to, and am at a loss. I don't know why this would fail intermittently. Based on my admittedly limited knowledge of Ninject, there should be no way for the binding to be missing.
I see a lot of references to using the Ninject MVC Nuget packages, but the app as I inherited it does not use those, it initializes Ninject using an ActionFilter. Is this pattern just broken at its core, and somehow interfering with proper binding?
Help?
Take a look at the BindFilter option
https://github.com/ninject/ninject.web.mvc/wiki/Filter-configurations
There is some sort of caching issue I believe, that makes filters behave differently to controllers. This means that the binding can fail, usually under heavy load, but unpredicatably.
It turns out that newer versions of Ninject need more setup for InRequestScope to work. By removing Ninject entirely, and readding references to Ninject, Ninject.Web.Common, and Ninject.Web.MVC, it added the Ninject.Web.Common.cs file that was neccessary for InRequestScope to work.
Previously, it was actually binding InTransientScope, which meant it would get garbage collected, which is non-deterministic, which explains my intermittent issues. I wish it would have thrown exceptions when i tried to bind InRequestScope, but c'est la vie.
I tried to create a class library in .NetFrameWork 4.0.
I used the below code in a class and trying to add mscorlib.dll from .NetFrameWork 4.0 since the System.Type is residing on mscorlib.dll.
string str3 = (string)type.Format(str2, obj1, obj.properties.email.value);
But while adding the reference ,there is an error occured
Anyone please help me in this
You don't need to add reference to mscorlib.dll as it is automatically refered by the build system.
For using "Type" class,all you need to do is,just use the "using System" namespace.
Check this:
I'm working on a project that uses NHibernate (v 3.3.0.4000) and memcache (v 3.1.0.4000 which is the latest available).
I have a large field containing pretty big strings. As I do not want to load this field with every call, I've configured the property as "lazy loading" with Fluent Nhibernate .
Everything works fine (my property is loaded on demand) except when memcache is enabled. Iget this exception :
NHibernate.PropertyAccessException: The type System.Object can not be assigned to a property of type System.String setter of XYZ ---> System.ArgumentException: Impossible de convertir l'objet de type 'System.Object' en type 'System.String'.
I guess the problem is related to the version of "NHibernate.Caches.MemCache", which is quite old and doesn't seem to be alive.
I would like to know if anyone has managed to run memcache with lazy properties . If not, is it possible to disable cache for a single property ?
It looks like this was a known bug:
Retrieving object from 2nd cache with lazy property fails
And, fortunately for you, it was fixed in the latest release (3.3.2, as of today)
Just update NHibernate and the problem will be gone.
Although I love the idea of F# type providers my first serious attempt to use them crashed hard.
I was going to connect to a service (WCF) with WsdlService<"http://someurl/some.svc?wsdl">
It fails epicly with:
The type provider
'Microsoft.FSharp.Data.TypeProviders.DesignTime.DataProviders'
reported an error: tmp6E6C.cs(9409,26): error CS0644:
'System.ComponentModel.PropertyChangedEventHandler' cannot derive from
special class 'System.MulticastDelegate'
c:\Windows\Microsoft.NET\Framework\v4.0.30319\mscorlib.dll: (Location
of symbol related to previous error)
and a lot of other warnings which probably are not relevant:
tmp6E6C.cs(290,28): warning CS0436: The type
'System.Data.DataRowState' in
'c:\Users\someuser\AppData\Local\Temp\tmp6E6C.cs' conflicts with the
imported type 'System.Data.DataRowState' in
'c:\Windows\Microsoft.NET\Framework\v4.0.30319\System.Data.dll'. Using
the type defined in 'c:\Users\someuser\AppData\Local\Temp\tmp6E6C.cs'.
tmp6E6C.cs(9427,17): (Location of symbol related to previous warning)
Is this a known feature ;-) or am I using it wrong?
I unfortunately cannot post the WSDL, and its rather large with a lot of types in it so I must admit I am somewhat lazy and have not trimmed it down either. OTOH if I did know what part of the WSDL was offending or creating this error I would of course have put it here.
To change the WSDL is not an option either, so I am mainly interested in knowing why F# WSDL type providers can not handle this (WCF) WSDL, or what I am doing wrong.
It works excellent when consumed by C# and svcutil.exe from VS2010.
I have tried all the params to the WsdlTypeProvider and they do give the same result (except ForceUpdate of course). Should I be consuming these services in another way with F#?
===============================================================================
Added info (since I am new and didnt want to answer. dont ask why :):
Thank you all answering/commenting.
I did go partly this way may self (manually using svcutil). As I tried to say above, I tried to use svcutil by hand, and it fails when compiling the generated C# code (in a library besides the F#).
That is, I did the following:
1) Create the contract by setting up a reference in VS 2010 GUI. This works as expected
2) Try to create it by using svcutil from cmd-line. Then the compile of that file fails with same error.
As it seems from my point of view what happens in svcutil from cmd-line and what happens when using svcutil (or what is used) from the GUI adding the same service does not generate the code with the same parameters. I guess this is partly controlled by the fact that what I try to consume is a WCF service and not a "clean" WSDL/webservice, and the type provider assumes that I try to use a "clean" webservice.
I did not manage to find any params for svcutil takeing care of this, or any possible combinations of params, not saying that I did try all permutations of combinations, but trying the ones probable based upon (trying to) deep reading the documentation of svcutil (and I am not entirley new at using it from cmd-line).
So far I have concluded that it is some "missing" params to svcutil which causes this, and that the F# type provider is not at fault. I would still very much like to solve it somehow, still using F# type providers, but a fallback is to generate the code by GUI in C# and then reference that part of code in F# again. That is not the elegant solution I was trying to achieve, since I do have a lot of services and I would very much like to create such a nice way of prototyping and testing those services.
Another fallback would of course also give up the whole F# part and just go with some unit-testing etc., but that again is defating the purpose of sneaking in F# and learning at same time ;-)
The WSDL type provider (and a few others) are using SvcUtil in the background to do the heavy lifting. If you open ProcExp of taskmgr or some similar tool, you can see the SvcUtil process getting spawned after pasting the TP code into Visual Studio. With ProcExp at least, you can see the full command line with arguments which was used.
So find out exactly what SvcUtil command line was invoked by the TP for your service, and check if it works outside of the F# environment.
The fact that SvcUtil works from C#/VS 2010 is interesting. I assume if you are using F# TPs you are on VS 2012 right now. If so, the version of SvcUtil itself might be different, which could be related.
The specific error would appear to be the same as explained here, so you might have some incomplete annotations in your service code.
I am not able to leave this issue ...
I have now done the following:
Run svcutil with plain vanilla setting: svcutil http://some.address/some/path.svc
Run with some more setting: svcutil /r:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5\System.dll" /r:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5\System.Data.dll" http://some.address/some/path.svc
This does generate the follwowing differences in the C# file (it is present in 1) and not present in 2) obviously):
namespace System.ComponentModel
{
using System;
[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.CodeDom.Compiler.GeneratedCodeAttribute("System.Runtime.Serialization", "4.0.0.0")]
[System.SerializableAttribute()]
public partial class PropertyChangedEventHandler : System.MulticastDelegate
{
public PropertyChangedEventHandler(System.Runtime.Serialization.SerializationInfo info, System.Runtime.Serialization.StreamingContext context) :
base(info, context)
{
}
}
}
namespace System.Data
{
using System;
using System.Runtime.Serialization;
[System.CodeDom.Compiler.GeneratedCodeAttribute("System.Runtime.Serialization", "4.0.0.0")]
[System.FlagsAttribute()]
[System.Runtime.Serialization.DataContractAttribute(Name="DataRowState", Namespace="http://schemas.datacontract.org/2004/07/System.Data")]
public enum DataRowState : int
{
[System.Runtime.Serialization.EnumMemberAttribute()]
Detached = 1,
[System.Runtime.Serialization.EnumMemberAttribute()]
Unchanged = 2,
[System.Runtime.Serialization.EnumMemberAttribute()]
Added = 4,
[System.Runtime.Serialization.EnumMemberAttribute()]
Deleted = 8,
[System.Runtime.Serialization.EnumMemberAttribute()]
Modified = 16,
}
}
Which again makes the file compile in 2) and is as expected otherwise.
The somewhat strange part then is: Why isnt System.dll used in F# wsdl providers when running svcutil? System.Data.dll I kind of understand, since that isnt default used when running svcutil (at least according to the documentation).
OTOH I think also that the documentations says that IF the assemblies are in the GAC it should use them. So how do I verify they are there, and/or load them to the assembly if not?
Running gacutil -i System.dll (on version 4.5 of the System.dll) gives:
Failure adding assembly to the cache: An attempt was made to load a
program with an incorrect format.
Is it some 64/32 bit issue? (Im on a 64 bit windows if that does have any relevance)
Or to rephrase the problem: How do I get System.dll and System.Data.dll to part of the references when running svcutil when I cannot add the references directly through the WsdlProvider-part?
Im pretty sure it does not use System.dll since if I add the collectiontype param to wsdlprovider:
WsdlService<"http://some.url/some/path.svc", "c:\\temp\\wsdl\\some.wsdlschema", true, ".", true, true, false, false, "System.Collections.Generic.List'1">
it also complains with the following:
The type provider
'Microsoft.FSharp.Data.TypeProviders.DesignTime.DataProviders'
reported an error: Error: No type could be loaded for the value
System.Collections.Generic.List'1 passed to the /collectionType
option. Ensure that the assembly this type belongs to is specified via
the /reference option.
which should have been available directly if System.dll was referenced (I think).
Any ideas to further investigate or solve this issue?
I'm working on a wcf project. Some of my services return objects that contain circular references. The serialization of these objects is handled through setting IsReference to true on DataContract attribute, so everything works fine if i write code to call those services. But for simple testing, it seems more preferable to me to use the GUI interface WcfTestClient.exe, and it turns out that WcfTestClient fails to display circularly referenced objects.
I know trying to display objects which contain references to each other will cause infinite recursion if nothing special has been processed. I just wonder does that mean it is impossible to test services that return circularly referenced objects via WcfTestClient ? Thanks.
Hi I had the same problem with WCF test client , which cannot able to handle this circular reference even the IsReference =true. An unhandled exception of type 'System.StackOverflowException' occurred in mscorlib.dll error is happening at the WCFTestClient.exe , but not with your WCF service, that's why it's falling to the visual studio Disassembly with the stackoverflow error. the point is WCFTestClient is not intended or expecting a circular reference like visual studio object tree. Hope you understand. nice question anyway... :)