New classes added to an assembly are not found through reflection

We have a rules processing system where each rule is represented by a class and all rules implement a common interface. Occasionally, we will add a rule (class) to the assembly but when that rule comes up for processing, the system cannot find that class. The code we use to run the rules looks like this.

private void runClass(string dllName, string className, string methodName, string ruleNamespace)
{
    Assembly _Assemblies = Assembly.LoadFrom(dllName);

    Type _Type = null;
    string nameSpace = _Assemblies.ManifestModule.Name.Substring(0, _Assemblies.ManifestModule.Name.ToLower().IndexOf(".dll"));
    if (ruleNamespace.Trim() != "")
        nameSpace = nameSpace + "." + ruleNamespace;
    _Type = _Assemblies.GetType(nameSpace + "." + c开发者_运维知识库lassName);
    if (_Type == null)
        throw new Exception("Cannot find class " + className + " in " +     nameSpace + ".");

    IRule rule = (IRule)Activator.CreateInstance(_Type);
    rule.Process();
}

I have tried cleaning the build, rebuilding from scratch, rebooting, wiping the DLL's by hand and rebuilding and several other things that I can't remember right now. The freaky part is that there may be 50 rules in an assembly and 48 of them are found but two are not, and the two that are not found are the ones that have been just added. Can anyone think of what might cause this?

Update: I found the actual answer and accepted the one closest to the actual answer because it led me in the right direction. We have two branches of code, one for dev and one for QA on our dev machines. the applciation is a web service and in order to debug it, we have to start the unit tests, attach to the aspnet_wp.exe process and then set breakpoints. The reason why it couldn't find the classes was because the machine got pointed to the QA instance of the web service, so, any new classes would not be found; all the old ones were there because they had been deployed to the QA branch. Thanks for all the comments and eventually leading me to the right places to look, it was eventually all about the deployed location but not in the way you would think. :)

If this problem persists after a reboot then you have 1 of 3 potential issues.

1. You aren't actually deploying it.

2. Your app uses some type of custom assembly caching mechanism and doesn't refresh based off of seeing a new assembly in a pick up folder.

3. You are deploying it, but not to the correct location/server.

If I was to place a bet, I'd see what was behind door #3.

UPDATE
Based on the comments: I didn't realize you were running this locally versus deploying to the server.

That said, it sounds like you are referencing the assembly by the assembly name instead of through a project level reference. VS caches assemblies during development and probably isn't refreshing your local cache.

Further, depending on the project type it sometimes gets confused as to where the assembly actually is. For example, in web site projects VS will happily (and usually incorrectly ) retarget your assembly references if it finds a copy of the assembly in the GAC or along some other path. Web Application projects don't usually exhibit this behavior.

In the main project, right click on the assembly reference and see where it thinks it's loading the dll from.

If I understand you correctly and the assembly may get replaced in runtime, the issue you're having is Assembly.LoadFrom will return the same assembly if its identity is the same, even if you specify a different path.

Consider using LoadFile instead. See explanation on choosing binding context here.

However first you must ensure that assembly indeed has changed. Put a breakpoint on this method and when it hits, open the file located at dllPath in Reflector (while it's still free :-) and ensure you're actually trying to load the new assembly.

I would start with deleting the assembly at its expected location and then checking if the code fails.