0

I have encountered an unusual situation where the same code is behaving differently on a particular machine. The program is written in VB.NET and WF4. The workflow XAML is read from a database at runtime and compiled on the fly. I mention this only to give context to my question in case of relevancy.

Specifically, the exception thrown within the WF is:

Invalid cast from 'System.Double' to 'System.Nullable`1[[System.Double, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]'

It is difficult to debug the program since the machine is owned by another organization and the user has little time to assist me. I believe the exception occurs when a WF variable of type double is passed to a method I have written and exposed through a WF argument. The method parameter is of type Nullable(Of Double).

The code in question is installed and is run regularly on as many as 100 computers in several different organizations. It is only on this one particular machine that it behaves differently.

I wonder if the compile options Option Explicit, Option Strict and Option Infer could be the source of the exception. Is it possible that the values for one or more of these Compile Options is being overridden on this problematic machine due to some specific configuration change made to the .net framework deployment on this machine? The behavior of these options and any effect they may have on the JIT compiler at runtime is not an area of the framework I am particularly knowledgeable of.

The assemblies target .net 4.0 and were compiled using VS2010 SP1. The machine in question is running Win7 64bit. The assembly is compiled for release and x64 platform.

This is my first question posted to this site, although I have used it with great success for many years. Thank you in advance for any advice.

Kevin Brown
  • 1
  • 2
  • I'd guess they have a different version of one of your assemblies. Turn on fusion logging on that machine, execute, then pull out all the logs it generates. Do the same on a working machine. Check the versions of the loaded assemblies to see which one is incorrect. –  Aug 08 '14 at 20:55
  • No, the assemblies are identical to the versions in use on other machines. I have confirmed this personally. – Kevin Brown Aug 08 '14 at 21:01
  • Assume nothing, not even that what you believe to be true is. Unless you check the fusion logs (or do some kind of interception when assemblies are loaded within your application), you don't know what is actually loaded at runtime. The biggest problem you can give yourself when facing inexplicable issues is to say, "I know". You know nothing, Kevin Brown. BRB, winter. –  Aug 08 '14 at 21:03
  • Will, I do thank you for the advice and I will do as you have suggested. Unfortunately, the affected machine is not controlled by my organization and I am at the user's mercy when requesting access. – Kevin Brown Aug 08 '14 at 21:51
  • I did make an effort to confirm the version of the assemblies and the version of the embedded database file by calculating and comparing an MD5 hash code. Again, I thank you for your advice. What does "BRB, winter" mean (I risk appearing foolish asking this, but I wonder)? – Kevin Brown Aug 08 '14 at 22:00
  • that and the line before it was a lame Game of Thrones joke. Now lamer, as I had to explain it :| One last time--you need to view the fusion logs to see what versions of assemblies are being loaded at runtime. MD5 hashes aren't an equivalent test. You need to see what the runtime is loading and from where. –  Aug 11 '14 at 14:51
  • I completely forgot about this post. As Will suggested, there was an issue with the installation of .Net 4.5 on the machine in question. Uninstalling .Net 4.5 and then installing .Net 4.5.1 resolved this issue. Fusion logging did in fact reveal that there were older .Net assemblies being loaded, just as Will suggested it might. – Kevin Brown Jul 10 '15 at 20:34
  • ;) and that's why you never assume when weird stuff like this happens! Feel free to add that as an answer below so you can close out your question. Make a nice answer, and add some detail about what the fusion log said, and I'll redirect future folks to your answer when they have similar issues. I won't add an answer as "turn on fusion logging" really isn't an answer, it's how you *get* the answer. –  Jul 10 '15 at 20:39

0 Answers0