Code cast InvalidCastException when it "Shouldn't"
-
I am working with EFT solutions in the LSRetail LSOne POS, and one of my customers has an issue that I cannot figure out why happens. I have a class that has the following declaration:
public class MyEFTService : EFTBase, IEFTService, IMyInterface
{
//Code omitted
}The IMyInterface interface is one I have added so I can execute some added functionality to the class from another location. I do that like this:
public IPosTransaction RunTask()
{
var service = Services.EFTService(entry);
var dxcpcEft = (IMyInterface)service;//rest of code omitted}
The Services.EFTService(entry) call returns the instance of MyEFTService created during startup, which I then cast to my IMyInterface and I can then do the calls I need to. This works on my machine, on my testers machine, and any co-workers machine. But it's here my customer has an issue. When we try to cast the instance to the IMyInterface interface on his machine we get an InvalidCastException. In debug, if I look at the service variable and browse through the object information, I can see variables that only my version of EFTBase has and I then know that it does have the IMyInterface as well. We also tried to execute service is IMyInterface in the immediate debug window of visual studio and it returns true. So, as far as I can see, the service variable DOES have the IMyInterface and visual studios Immediate debug window confirms it. We also tried to run service.GetType(), and that too returns information related to MyEFTService class:
{Name = "EFTService" FullName = "LSOne.Services.EFT.EFTService"}
Assembly: {LSOne.Services.EFT.MY_EFT, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null}
AssemblyQualifiedName: "LSOne.Services.EFT.MyEFTService, LSOne.Services.EFT.MY_EFT, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"
Attributes: Public | BeforeFieldInit
BaseType: {Name = "EFTBase" FullName = "LSOne.Services.EFT.Common.EFTBase"}
ContainsGenericParameters: false
CustomAttributes: Count = 0
DeclaredConstructors: {System.Reflection.ConstructorInfo[1]}
DeclaredEvents: {System.Reflection.EventInfo[0]}
DeclaredFields: {System.Reflection.FieldInfo[15]}
DeclaredMembers: {System.Reflection.MemberInfo[75]}
DeclaredMethods: {System.Reflection.MethodInfo[52]}
DeclaredNestedTypes: {System.Reflection.TypeInfo.d__23}
DeclaredProperties: {System.Reflection.PropertyInfo[3]}
DeclaringM -
I am working with EFT solutions in the LSRetail LSOne POS, and one of my customers has an issue that I cannot figure out why happens. I have a class that has the following declaration:
public class MyEFTService : EFTBase, IEFTService, IMyInterface
{
//Code omitted
}The IMyInterface interface is one I have added so I can execute some added functionality to the class from another location. I do that like this:
public IPosTransaction RunTask()
{
var service = Services.EFTService(entry);
var dxcpcEft = (IMyInterface)service;//rest of code omitted}
The Services.EFTService(entry) call returns the instance of MyEFTService created during startup, which I then cast to my IMyInterface and I can then do the calls I need to. This works on my machine, on my testers machine, and any co-workers machine. But it's here my customer has an issue. When we try to cast the instance to the IMyInterface interface on his machine we get an InvalidCastException. In debug, if I look at the service variable and browse through the object information, I can see variables that only my version of EFTBase has and I then know that it does have the IMyInterface as well. We also tried to execute service is IMyInterface in the immediate debug window of visual studio and it returns true. So, as far as I can see, the service variable DOES have the IMyInterface and visual studios Immediate debug window confirms it. We also tried to run service.GetType(), and that too returns information related to MyEFTService class:
{Name = "EFTService" FullName = "LSOne.Services.EFT.EFTService"}
Assembly: {LSOne.Services.EFT.MY_EFT, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null}
AssemblyQualifiedName: "LSOne.Services.EFT.MyEFTService, LSOne.Services.EFT.MY_EFT, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"
Attributes: Public | BeforeFieldInit
BaseType: {Name = "EFTBase" FullName = "LSOne.Services.EFT.Common.EFTBase"}
ContainsGenericParameters: false
CustomAttributes: Count = 0
DeclaredConstructors: {System.Reflection.ConstructorInfo[1]}
DeclaredEvents: {System.Reflection.EventInfo[0]}
DeclaredFields: {System.Reflection.FieldInfo[15]}
DeclaredMembers: {System.Reflection.MemberInfo[75]}
DeclaredMethods: {System.Reflection.MethodInfo[52]}
DeclaredNestedTypes: {System.Reflection.TypeInfo.d__23}
DeclaredProperties: {System.Reflection.PropertyInfo[3]}
DeclaringMI'd start by checking if the customer has all the right dependencies - if the interface or class is declared in a separate assembly (and it probably should be) then a version mismatch could cause the problem.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
-
I am working with EFT solutions in the LSRetail LSOne POS, and one of my customers has an issue that I cannot figure out why happens. I have a class that has the following declaration:
public class MyEFTService : EFTBase, IEFTService, IMyInterface
{
//Code omitted
}The IMyInterface interface is one I have added so I can execute some added functionality to the class from another location. I do that like this:
public IPosTransaction RunTask()
{
var service = Services.EFTService(entry);
var dxcpcEft = (IMyInterface)service;//rest of code omitted}
The Services.EFTService(entry) call returns the instance of MyEFTService created during startup, which I then cast to my IMyInterface and I can then do the calls I need to. This works on my machine, on my testers machine, and any co-workers machine. But it's here my customer has an issue. When we try to cast the instance to the IMyInterface interface on his machine we get an InvalidCastException. In debug, if I look at the service variable and browse through the object information, I can see variables that only my version of EFTBase has and I then know that it does have the IMyInterface as well. We also tried to execute service is IMyInterface in the immediate debug window of visual studio and it returns true. So, as far as I can see, the service variable DOES have the IMyInterface and visual studios Immediate debug window confirms it. We also tried to run service.GetType(), and that too returns information related to MyEFTService class:
{Name = "EFTService" FullName = "LSOne.Services.EFT.EFTService"}
Assembly: {LSOne.Services.EFT.MY_EFT, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null}
AssemblyQualifiedName: "LSOne.Services.EFT.MyEFTService, LSOne.Services.EFT.MY_EFT, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"
Attributes: Public | BeforeFieldInit
BaseType: {Name = "EFTBase" FullName = "LSOne.Services.EFT.Common.EFTBase"}
ContainsGenericParameters: false
CustomAttributes: Count = 0
DeclaredConstructors: {System.Reflection.ConstructorInfo[1]}
DeclaredEvents: {System.Reflection.EventInfo[0]}
DeclaredFields: {System.Reflection.FieldInfo[15]}
DeclaredMembers: {System.Reflection.MemberInfo[75]}
DeclaredMethods: {System.Reflection.MethodInfo[52]}
DeclaredNestedTypes: {System.Reflection.TypeInfo.d__23}
DeclaredProperties: {System.Reflection.PropertyInfo[3]}
DeclaringM- Ensure than their machine is up to date on their Windows updates. 1) Have the customer uninstall it (and all older versions), and reinstall it.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
I'd start by checking if the customer has all the right dependencies - if the interface or class is declared in a separate assembly (and it probably should be) then a version mismatch could cause the problem.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
I thought I did confirm the versions, but it does look like there is a version mismatch with at least some files. I will update when I have more information.
-
I thought I did confirm the versions, but it does look like there is a version mismatch with at least some files. I will update when I have more information.
:thumbsup:
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
-
I thought I did confirm the versions, but it does look like there is a version mismatch with at least some files. I will update when I have more information.
Easy way to prevent it in the future; make a hash from all that you build. Do not confirm the versions, confirm the resulting hash.
Bastard Programmer from Hell :suss: "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
-
:thumbsup:
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
Upon further research, it became clear that the versions of the POS system did not match the expected version. We transferred the source code over to the customer so he could build the files with his version and to great care in deleting all other versions of the affected DLL. We still get the same results. I also found the version on my machine that they actually got from me and ran a test on my machine, and it works without problems. So now to rule out a problem on the customer's end, he is currently sending me the entire software catalogue with my file changes to see if it crashes on my machine. If it fails, it's something in his project. If it does not fail... then I actually don't know. I will keep you posted.
-
Upon further research, it became clear that the versions of the POS system did not match the expected version. We transferred the source code over to the customer so he could build the files with his version and to great care in deleting all other versions of the affected DLL. We still get the same results. I also found the version on my machine that they actually got from me and ran a test on my machine, and it works without problems. So now to rule out a problem on the customer's end, he is currently sending me the entire software catalogue with my file changes to see if it crashes on my machine. If it fails, it's something in his project. If it does not fail... then I actually don't know. I will keep you posted.
Sound like you're going to need a site visit with a copy of VS ... I hate those. I once spent a week sitting quietly in a library waiting for software to go wrong, only to find on the Friday it was a hardware problem: they had a laminator they used to seal new user badges which spat so much noise back down the mains lead it fritzed out the PSU. Still, it was on expenses, and the hotel bar was good!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
