Here’s the deal, sometimes when you write SharePoint code on your dev machine, it deploys just fine. When you package it and deploy it on another server, it doesn’t always work so hot. Furthermore, you might sometimes experience this exception on dev box:
Error occurred in deployment step ‘Add Solution’: Failed to load receiver assembly “…”.
System.IO.FileNotFoundException: Could not load file or assembly ‘…’ or one of its dependencies. The system cannot find the file specified.
So what’s going on here? Well, it’s quite simple, and yet, it is almost haunting. The fact is, Visual Studio doesn’t always pick up your changes when it builds your solution. It seems to think that that if you haven’t changed the code, when you build your solution it shouldn’t compile a new DLL. That annoys me because sometimes I actually need it to rebuild that DLL for me. If I tell VS to build, I’m thinking it’s going to recompile all of the DLLs for me (note to self: build != recompile). As my friend James S. says, “There’s your problem.” In other words, “stop thinking; start doing.”
So, I’ve been paranoid about packaging my code. First, I intend to clean up my dev box and run a test deployment on it as an ITPro would on his/her Test environment. Second, I deploy to a Test farm. So the goal in VS is to get a fully compiled .sln file. To confidently get that, I perform a manual clean, build, package, and then test it.
Here are my steps:
1. Right-click the project and Retract
2. Verify the feature is gone from the filesystem, the DLLs are no longer in the GAC, etc.
3. In Visual Studio’s Solution Explorer window, click Show all files
4. Control-click bin, obj, pkj, pkjobj
5. Delete and confirm delete
6. Right-click the project and Build
7. Right-click the project and Package
Now I know for sure that everything in the package is using the latest code, settings, etc.
And yes, I realize there is a Clean function. I don’t trust it. Do you?