I upgraded SP 2010 Solution created using VS 2010 to SP 2013 solution in VS 2012. The Solution has one SharePoint project which references another SharePoint project in the same solution. There are using statements in the project which refer to classes in the referred project. When I build individual projects or whole solution everything builds fine. However, when I try to deploy or package a project which references another SharePoint project, I get the namespace error:

The type or namespace name 'XXXXX' does not exist in the namespace 'XXXXXX' (are you missing an assembly reference?)

All assembly references, .Net Framework etc are properly updated to reflect SP 2013 changes. The issue is very similar to this issue:

SharePoint project builds but will not package

  • It might be good idea to add problem to your question then give link to it :) and what error does it throw when you try to deploy it Commented Jan 13, 2014 at 11:24
  • @MuhammadRaja, see the updated question. Commented Jan 13, 2014 at 11:33
  • Check what is it deploying @package, seems like it's has reference to some dll, which isn't already in GAC, at least that's what happened in my case, just to be on safe side, add that dll as safe controls within your package and then see if it makes any difference Commented Jan 13, 2014 at 11:38
  • @MuhammadRaja thanks, but that did not help. Commented Jan 13, 2014 at 12:50

1 Answer 1


I fixed the issue by removing the dll references which were added using "Project references" and then added the references by browsing to bin folder. Source:



A better approach is to make sure that order of the assemblies is correct as mentioned in this question: SharePoint project builds but will not package

You need to change the order of Additional Assemblies defined on the SharePoint package since in Visual Studio 2013, this now makes a difference. My issue (and I suspect yours) was that several of my non-SharePoint projects had dependencies on each other and had to be built in a particular order. This was not an issue in Visual Studio 2012.

To change the order in which the assemblies are built when you attempt to package/deploy your SharePoint project,

First find out the order you want the non-SharePoint projects to be built based on the dependencies. In Visual Studio, open the Package.package file in the /Package folder of the SharePoint project. Click on the Advanced tab. Delete all of your non-SharePoint project references (the Deployment should work at this point in time). Add all of your non-SharePoint project references in the order that you determined in Step 1. If any of your non-SharePoint assemblies needs to be marked as a Safe Control, remember to add it in the Safe Controls section in the Add Assembly from Project Output dialog. Your application should deploy and work normally now.

ALL credit to David K http://ddkonline.blogspot.com/2013/10/build-and-packagepublish-behaviour.html

  • Could you confirm that you readded them in the exact same order? Otherwise, I would said that the fix is not having the reference pointing to bin, but having them in the right order, like what Ryan/David claims in the question you linked (here). I am asking for evidences because I had your same problem on a migrated solution 2010->2013 and I solved my problem by following Ryan suggestion. I guess you solution may also work because the file are already present when the buil&package process starts.
    – SPArcheon
    Commented Jan 14, 2015 at 10:48
  • @SPArchaeologist, the order of the assemblies wasn't correct. The answer in that post did help me resolve the issue. I was doing a POC at that time and adding the assemblies from bin looked like an easy option. But later when we did the actual migration, we changed the order of the assemblies. Commented Jan 14, 2015 at 11:01
  • ok, thanks - I just wanted to be sure. So yes, probably having the references pointing to bin somehow circumvent this "bug/feature". Thanks Nadeem
    – SPArcheon
    Commented Jan 14, 2015 at 11:17

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.