SharePoint 2007: “Could not load file or assembly 'NewWebPart' or one of its dependencies. Access is denied.”
I ran into this error yesterday, while trying to create a test web part for a client. I tried various fixes, including (but not limited to):
- Placing my DLL into the GAC;
- Checking what else my assembly might be referencing;
- Changing the security rights on the “Temporary ASP.NET Files” folder;
- Viewing the assembly bindings using SysInternals Process Monitor tool;
- Setting the registry to display assembly binding information;
- Setting the WSS Trust level to “WSS_Medium”;
and several more (including all of the standard SharePoint steps of placing the assemblies in the “bin” folder and adding a SafeControl entry.) None of them worked, and some of them were actually bad ideas (e.g. changing the security rights on the “Temporary ASP.NET Files” folder.)
Finally, I got in touch with one of my colleagues—a guy who is often able to help me through such problems—and he diagnosed the issue right away.
Change the WSS Trust Level to “WSS_Full” or Place DLL in the “app_bin” Folder
The fix I actually implemented was placing my DLL into the “app_bin” folder in my web application’s root. The reason this worked is actually related to the other option: changing the WSS Trust level.
My colleague pointed me to the WSS Trust Policy file. Mine was located in “C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\config\wss_mediumtrust.config"; you should be able to confirm the location of your by looking in one of the web.config files in your SharePoint root folder (search for “<trustLevel”.) Reading through that (not an easy read, by the way), I discovered that the trust levels defined in “wss_mediumtrust.config” contain no mention of the “bin” folder.
This is why putting the assembly in the bin folder doesn’t work, even when setting the trust level to “WSS_Medium”.
The “app_bin” folder, however, is included. This isn’t exactly recommended, however. The actual answer should be to either:
- Set the trust level to “WSS_Full”; or
- Modify the “WSS_Medium” policy to include the “bin” folder.
For a little easier read (and more useful information) about WSS Trust Levels, check out this page on MSDN. Note: the information on this page is specific to WSS 2.0/MOSS 2003. The information should generally be accurate, however, for WSS 3.0/MOSS 2007.
Hope someone else finds that useful.