18

I have a SharePoint project that references (and includes in its package) a non-SharePoint project.

There is a class in my SharePoint project that references the non-SharePoint project, so has a using MySolution.MyNonSharePointProject; directive at the start of the file.

When I build my SharePoint project, it builds prefectly happily.

When I try to package my SharePoint project - via Deploy or Publish - I get build errors The type or namespace name 'MyNonSharePointProject' does not exist in the namespace 'MySolution' (are you missing an assembly reference?)

How does building my project via Build differ from building it via Deploy or Publish? Why am I getting this error?

Alex Angas
  • 5,961
  • 9
  • 49
  • 89
Rawling
  • 880
  • 2
  • 10
  • 25
  • Do you have the other project build settings correct? ie: Any CPU, .NET 4? – James Love Jun 05 '13 at 10:33
  • 1
    Yup, they're all .NET 4.5 and Any CPU. Correct me if I'm wrong, but I believe a standard Build would fail if these were incorrect. – Rawling Jun 05 '13 at 10:36
  • Yeah it would fail. Last I saw stuff like this was in VS 2008... solution back then was to restart VS. Does doing this help at all? – James Love Jun 05 '13 at 10:38
  • 1
    I've tried that a couple times and on this occasion it doesn't help. I've also tried my other workaround for this problem - usually if you do a Clean then you can do a Deploy once before it breaks again - but again, on this occasion it doesn't help. – Rawling Jun 05 '13 at 10:49
  • Have you found any workaround here? – Serhiy Aug 19 '13 at 19:36
  • 1
    Another workaround is to use CKS Dev and do a "Copy to GAC/Bin" instead of a full deploy. – Rawling Aug 19 '13 at 23:16
  • 1
    This happens in SP2010 solutions as well so I removed the 2013 tag. It seems to be do to with Visual Studio. – Alex Angas May 02 '14 at 05:38

4 Answers4

14

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,

  1. First find out the order you want the non-SharePoint projects to be built based on the dependencies.
  2. In Visual Studio, open the Package.package file in the /Package folder of the SharePoint project.
  3. Click on the Advanced tab.
  4. Delete all of your non-SharePoint project references (the Deployment should work at this point in time).
  5. 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 Klein (http://ddkonline.blogspot.com/2013/10/build-and-packagepublish-behaviour.html)

Ryan Shripat
  • 436
  • 4
  • 20
  • 2
    It's a nice idea, but (as tagged) I'm using Visual Studio 2012. – Rawling Dec 04 '13 at 13:51
  • 1
    I had the similar issue and was so frustrated. I was using VS2013 on SP2013. I fixed the issue following Ryan Shripat's post. It worked well and my solution is working as expected. Thanks Ryan!! -Karu – Karu Sep 02 '14 at 22:34
  • @Karu, good to know that this works for SP2013 as well! – Ryan Shripat Sep 03 '14 at 11:08
  • I have the same problem in VS2012 - SP2010 project. I have tried removing the project references, that helps, when I return the least dependent, it works and when I follow it with the second least dependent it fails no matter what order I choose. We also have some 3rd party custom assemblies there which I have placed in the right order above all the project assemblies. – Santhos Jun 24 '15 at 16:49
  • Didn't work for me: I had to reorder the references in Package.package by hand. – mhbuur Feb 02 '16 at 12:50
  • +1 This little nugget was very helpful. I was finding nothing when searching for reference errors when upgrading to a newer version of VS – leigero Dec 01 '17 at 17:06
0

I experienced similar symptoms within an VS2012 project targeting SP2010 after I separated some code into a new class library within the VS solution. After separating the code, I could no longer get the automatic pre-deploy build to run in the correct order. I tried everything in this thread. But I stumbled into a solution. Normally I right-click on the project in VS and select 'Deploy'. Since this wasn't working, I tried the "Deploy MySolutionName" item under the Visual Studio BUILD menu. This one actually allowed the deployment to proceed. I'm not sure what the functional difference is, but it seems to work in my case.

Bryan
  • 11
  • 2
0

This happens because the order of items in the package influences the way the wsp/publishing process compiles the assemblies.

Often you cannot get around that by adding assemblies to the "advanced" section.

You need to unload the project and reorder the items in the Package.package xml file. Make sure the order of the references to items in different projects matches the real dependency order.

When I encounter this error, it is almost certain that an item in a project that requires another project is being listed before the other project. I simply order the references (under features and projectItems) and reload the project.

mhbuur
  • 549
  • 2
  • 6
  • 22
-1

I tried all solutions described above, but none of them worked for me, what i did is removing all features from my solution package (sandbox solution with more than 100 features), then publish the package (no errors), and started to add the features again, a few each time and publishing again, i was doing this trying to detect a failing feature but then when i finished to add them all, the "publish solution" is working again... i tried it twice with different solutions and is working...

Please let me know if that worked for you

Fernando Rodríguez
  • 11
  • 2