Assembly load errors after adding web application resources to solution with farm features

Question

We have a solution that was recently changed from being globally deployed to deployed by web application in order to move binding redirects into the solution manifest (instead of using WebConfigModifications). The assemblies have DeploymentTarget="GlobalAssemblyCache"; there are farm scoped features within this solution.

This seemed to be fine in my initial tests, but now I am running into lots of "Could not load file or assembly" issues on different VMs. This is a scenario where an old version of the solution has been installed, retracted, and then I am installing the new version.

In particular, there's 2 assemblies in the .wsp, and there's a feature receiver in AssemblyA that uses a class in AssemblyB, and I get errors like:

Feature receiver assembly 'assemblyA', class 'FeatureReceiver', method 'FeatureInstalled' for feature 'GUID' threw an exception: System.IO.FileNotFoundException: Could not load file or assembly 'AssemblyB' or one of it's dependencies.

I've verified that AssemblyA and AssemblyB are in the GAC and their full names are correct. I tried re-signing the assemblies (and changing the full name in the feature xml) and changing the feature IDs but I think that's made it worse if anything (and now it can't load AssemblyA).

So - I'm left wondering: Is it OK to have a farm scoped feature inside of a solution with web application resources? Or could changing to web application resources have messed something up with something cached in SharePoint?

Answer 1

Supplemental to Robert's answer you might also have to clear the configuration cache:

1. Stop the OWSTIMER service on ALL of the MOSS servers in the farm.

2. On the Index server, navigate to:

   • Server 2003 location: Drive:\Documents and Settings\All Users\Application Data\Microsoft\SharePoint\Config\GUID and delete all the XML files from the directory.
   • Server 2008 location: Drive:\ProgramData\Microsoft\SharePoint\Config\GUID and delete all the XML files from the directory.

3. Delete all the XML file in the directory. NOTE: ONLY THE XML FILES, NOT THE .INI FILE.

4. Open the cache.ini with Notepad and reset the number to 1. Save and close the file.
5. Start the OWSTIMER service on the Index server and wait for XML files to begin to reappear in the directory.
6. After you see XML files appearing on the Index server, repeat steps 2, 3 & 4 on each query server, waiting for XML files to appear before moving to subsequent servers.
7. After all of the query servers have all been cleared and new .xml files have been generated, proceed to the WFE and Application servers in the farm, following steps 2, 3, 4 and 5 for each remaining server.

When performing these steps I have had the best luck making sure my solution was 100% uninstalled and retracted prior and only redeploying after these steps have been completed. Even then I've had a case where this did not work and I've had to repeat the steps over again, system reboot, reboot any other tools that might be caching such as Visual Studio, etc. An IIS reset after the last step prior to redeployment of the solution as well as after the deployment of the solution are extra precautionary steps I have also taken when trying this in order to make sure everything was clear.

Answer 2

This is typically due to the SPTimerV4 having cached the old DLL. A reset of SPTimerV4 followed by an IISRESET followed by some seconds of waiting (for SPTimerV4 to rebuild its cache) is often the solution

To, from Powershell restart SPTimerV4 and IIS Reset:

net stop sptimerv4
net start sptimerv4
iisreset /noforce