Resolving References

Session Hunter will continue to work, even if it cannot resolve the type. But if you want to know what the type is, Session Hunter needs to reference the assembly that created the session variable. Performance of Session Hunter is also significantly degraded when it cannot resolve references. In one test, processing 5000 session items that could not be resolved took 75 seconds, while it only took 8 seconds to process when it could resolve the references.

Getting all of the references and dependencies can be one of the most challenging parts of using Session Hunter but there are a number of features to help with the process. There are two ways to reference the assemblies it needs:

Bin folder

The simplest way is to have all of the assemblies into the same directory as Session Hunter. That way, it can use the local reference for all dependencies. This can be done by copying Session Hunter into the application folder that created the session variables, or copying the assemblies into the same folder as Session Hunter.

Manually Adding References

You can also manually add the references. This is especially valuable if you code changes often and you don’t want to continuously keep the two folders in synch or the folder is deleted on updates. From the references screen, it should list the full name of the missing assembly. Use the add button to point to the assembly that is missing and it should now be able to resolve the types. These settings are saved for the future, so you should only need to do this once.

When a type cannot be resolved, the missing assembly window will only have the assembly that is directly referenced by the session object. If you have already added this assembly, but it still cannot resolve the type, you are almost certainly missing a dependency. To help with this, there is a button that will add all dependencies to the Missing Assemblies list. You can then add those assemblies to see if the type can then be resolved.

If you are still having issues resolving the type, Microsoft has a free tool called the “Assembly Binding Log Viewer” or Fuslogvw.exe http://msdn.microsoft.com/en-us/library/e74a18c4%28v=vs.71%29.aspx. This will log assembly binding failure and can help diagnose the problem.

Global Assembly Cache (GAC)

Session Hunter will resolve types in the GAC. There are a number of articles online for adding your code to the GAC, such as http://msdn.microsoft.com/en-us/library/dkkx7f79.aspx.

Limitations:

  • You cannot add references to unmanaged code
  • If you add a reference to an assembly, it won’t be unloaded when you remove it from the list. Normally this does not have any effect on the tool, but there may be unpredictable behavior if you load an assembly with the same signature from a different location. If you trying different assemblies out to see which one resolves, you should consider closing the application before switching.
  • Assemblies that uses Code Access Security are not supported because it has not been fully tested

Last edited Feb 2, 2013 at 9:30 PM by repuust, version 10

Comments

No comments yet.