Udostępnij za pośrednictwem

Could not load file or assembly 'NewWebPart' or one of its dependencies. Access is denied.

  • Artykuł

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):

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.

Hope that helps someone else.

- Chris