I am working on migration from SharePoint 2010 to SharePoint 2013. I have mounted the content database in SharePoint 2013 and also deployed the WSPs from SharePoint 2010 which were created in Visual Studio 2010 to SharePoint 2013. Currently the site is running in SP 2010 mode.

The WSP solutions contain web application scoped resources and hence are deployed to web applications and not globally. There are SafeControl entries in the package, web parts, user control etc. Now when I browse the pages which contain the webparts I get the error:

Could not load type 'assemblyname'.

I have checked that all the physical files are deployed correctly to 14 hive, the dlls are all present in C:\Windows\assembly and the SafeControl entries are also present in web.config file. In the past I have had WSPs which deployed globally and I have not found any issues in them. There is a similar question over here:

"Could not load type" from custom SharePoint 2010 WSP deployed to SharePoint 2013


I created few simple VisualWebPart projects in VS 2010, deployed them to a web application in SP 2010 and then migrated the application to SP 2013 and deployed the solutions there. Everything works fine. That means this issue is not specific to web application scoped SharePoint solutions which I originally thought. There is something else going on in my projects which I am not able to identify.

  • what version of sp2013 are you using and also what version of vs are you using?
    – Ali Jafer
    Commented Jan 20, 2014 at 15:43
  • @aliSharepoint I am using SharePoint Enterprise Server 2013 and Visual Studio Professional 2012 Commented Jan 20, 2014 at 15:51
  • i presume you did this: Visual Studio 2012 -> Create new solution -> Under SharePoint 2013 select "Import SharePoint 2010 Solution"
    – Ali Jafer
    Commented Jan 20, 2014 at 15:59
  • No, I haven't yet upgraded the VS 2010 solutions to VS 2012. I have simply copied the WSPs created from VS 2010 and deployed them to SharePoint 2013 server. I first want the working site in SP 2010 mode. Once I have that I can then plan to upgrading the solutions to VS 2012. Commented Jan 20, 2014 at 16:07
  • maybe it's possible to recompile the wsp's against the new sharepoint assemblies? Or try to change the fileversion of the assembly. I had a similar problem, and a change of the file version of the assembly helped for me.
    – Sascha
    Commented Jan 23, 2014 at 8:50

2 Answers 2


i dont exactly know how it works in2010 with the wsp but i would of thought that the initial wsp can be converted which is fine as it uses .net 3.5

the issue is your getting the error:

Could not load type 'assemblyname'.

this tells me that there is a reference that is not referenced! so in your project within vs you need to upgrade custom dlls that are referenced for 2010 to 2013!

as noted:

Visual Studio 2012 -> Create new solution -> Under SharePoint 2013 select "Import SharePoint 2010 Solution

that should solve the issue.. but as you are looking for it to work off the bat i would presume that a dll within the project under reference is not set properly or doesnt exist in 2013 to work but it does in 2010!

have you tried a simple webpart like hello world? click a button and it shows hello world on a lable? see if it works which it should. Im still going with the fact that there is a dll in your project that doesnt exist in 2013 (assemble for 2010 3.5) and not assembly 4.0!


ok this is worth a try:

try putting the dll that is causing the issue within the web application dll folder!


that should do the trick ;)

just to make it clear that the error your getting is Could not load type 'assemblyname'. ? so there is somthing called assemblyname in your project? or have you just renamed it?

if the issue still persists than you need to force compile on the .cs class that you have named 'assemblyname'. within vs2012 goto the .cs class in question -> properties -> change build action to compile! build and deploy, the 'assemblyname' should now work as its compiled properly within the dll and packaged properly within the wsp!

  • 1
    As I have mentioned the dlls are there in the assembly folder. When solutions with earlier framework dlls are deployed in SP 2013 the dlls end up in C:\Windows\Assembly folder whether the solutions are web application scoped or global. In case of global solutions in SP 2010 mode the dll get properly referred. However, this doesn't seem to be the case with WSPs with web application scoped resources. Moreover, when the VS 2010 projects are converted to VS 2012 and hence 4.5 framework the dlls then automatically end up in newer version of assembly folder c:\windows\microsoft.net\assembly Commented Jan 20, 2014 at 16:34
  • just ammended my answer!
    – Ali Jafer
    Commented Jan 23, 2014 at 8:33
  • just added another solution if the bin folder doesnt work! the second solution should fix the wsp issue where your dll is not properly built
    – Ali Jafer
    Commented Jan 23, 2014 at 8:46
  • Thanks Ali. This is what actually happened. A colleague setup the test site in SP 2010. While setting it up she ran a WSP from obsolete code base by mistake. I did the migration and had the latest code and WSPs from this latest code. I wasn't aware of the issue. So there were some references to the classes from obsolete code. I will mark yours as answer as you tried to give best possible explanation. Commented Jan 23, 2014 at 9:23
  • ahh, glad to see that you solved your issue! :)
    – Ali Jafer
    Commented Jan 23, 2014 at 9:25

I am assuming - you are not facing with WSPs which are Globally deployed. Only with Web Application scoped

Can you retract the solution and check if it is 100% removed from GAC and 14 hive. Try IIS and try to deploy one more time

  • 1
    I have tried install/uninstall, iisreset etc several times. I haven't got any success with that. Commented Jan 20, 2014 at 16:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.