locked
Problem with VS2012 and Sharepoint 2013 Solution RRS feed

  • Question

  • Hello everyone

    I've got a problem that's driving me crazy. I'm migrating a Sharepoint 2010/Visual Studio 2010 Solution to Sharepoint 2013/visual Studio 2012 with the developer tools.

    My solution consists of 3 class libraries (common, data access layer and business logic) and a Sharepoint 2013 project containing the features, and the webparts using the output of the class libraries. The references inside projects are set through "Add Reference -> Solution -> Projects". I want a wsp-file containing the sharepoint artifacts and the assemblies from my class libraries. (those are added through the package explorer -> Advanced). If i use Build/Rebuild on the Solution it compiles fine, as it should.

    If i use the "deploy" or "publish" command on visual studio to create a solution package, the build fails with the message:

    "The type or namespace name 'whatever' does not exist in the namespace 'Xyz.Project'' (are you missing an assembly reference?)

    I can't find out what's wrong. if i deploy anything manually everything works fine. building/rebuilding my whole solution works fine. Everything is set to .NET 4.5. It seems to be that "wsp-package"-building process that has a problem.

    Any hint/idea would be welcome.

    Greetings
    Carlos

    Tuesday, December 11, 2012 12:38 PM

Answers

  • Hi,

    Does the missing assembly name is one of the 'common', 'data access' or 'business logic' project? Also can rename the output wsp file to cab file and then try to find out if your wsp included the dll inside it.

    As well as, you can check your Visual studio solution's package configuration page, to find out if your other three dlls are configured to include in the output package. Visual studio doesn't add external dependencies (even, referenced assemblies) to the output wsp pckage automatically 


    Thanks,
    Sohel Rana
    http://ranaictiu-technicalblog.blogspot.com

    • Marked as answer by Jack-Gao Tuesday, January 8, 2013 9:44 AM
    Friday, December 14, 2012 8:11 AM

All replies

  • Hi,

    Does the missing assembly name is one of the 'common', 'data access' or 'business logic' project? Also can rename the output wsp file to cab file and then try to find out if your wsp included the dll inside it.

    As well as, you can check your Visual studio solution's package configuration page, to find out if your other three dlls are configured to include in the output package. Visual studio doesn't add external dependencies (even, referenced assemblies) to the output wsp pckage automatically 


    Thanks,
    Sohel Rana
    http://ranaictiu-technicalblog.blogspot.com

    • Marked as answer by Jack-Gao Tuesday, January 8, 2013 9:44 AM
    Friday, December 14, 2012 8:11 AM
  • Why is the above reply marked as answered?  The OP has not provided any feedback.  We've had this particular problem as well and the only thing that helped was cleaning the solution (Right-click on solution in Solution Explorer > Clean Solution) and deploy again.
    Friday, March 15, 2013 8:19 AM
  • Honestly... it's a major pain (you know where) to work with Class Libraries and SharePoint solutions.

    I'm sick and tired of struggling with solution deployments every 5 minutes!

    Apart from "type or namespace not found" my personal favorite error message is "xyz does not implement interface member". In reality though the interface member has been implemented hours ago. Why can't we have solutions deployments like those back in VS 2008 / SP 2007 where you simply included a reference and "Copy local" to true and you were set.

    FIX IT!


    I realized I can fix those build errors by temporarily unloading all C# class libraries type projects. Awesome.
    • Edited by Venenum Thursday, April 18, 2013 8:48 AM
    Tuesday, April 16, 2013 12:45 PM
  • I am getting the same issue and unable to resolve it using any of the solutions..unload-reload/adding references properly...did you get any resolution on this ?
    Monday, May 13, 2013 9:43 AM
  • I've had this same problem... We have various SharePoint projects all referencing a "common" code library. The projects all build fine in Visual Studio 2012, but when you publish / deploy the references no longer resolve and you get the following build errors:

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

    To fix this, simply remove the reference to your "common" code library and re-add it as an assembly reference (as opposed to a project reference). I.e. Select 'Add reference...' and then browse to the 'bin' folder of your "common" library.

    • Proposed as answer by Tye Peel Thursday, July 18, 2013 3:12 PM
    Tuesday, May 14, 2013 9:59 AM
  • The same issue...20 additional DLLs for my Sp2013 project, tried to unload/reload - rebuilds OK, publish - fails with ridiculous message.
    • Edited by Senglory Thursday, June 27, 2013 8:16 PM some typos
    Thursday, June 27, 2013 8:15 PM
  • For anyone else seeing this error, the answer by Nick is the only thing that has worked for us so far. Thanks Nick!
    • Edited by Tye Peel Thursday, July 18, 2013 3:16 PM Reply moved to bottom of thread
    Thursday, July 18, 2013 3:13 PM
  • To fix this, simply remove the reference to your "common" code library and re-add it as an assembly reference (as opposed to a project reference). I.e. Select 'Add reference...' and then browse to the 'bin' folder of your "common" library.

    I did in fact consider that. But it can hardly considered good style and you lose a lot of benefits. The biggest of all being that you can never be sure you are working with latest versions of your common class libraries.

    While unloading/reloading worked in VS 2012 things are worse in VS 2013. In VS 2013 the solution doesn't package anymore at all. No matter what you do. Cleaning, rebuilding, reloading... I tried all of that in vain.

    Edit: And while I'm at it... great job in marking a totally irrelevant posting as answer. Another trigger happy content moderator. I really wonder if their financial goals are tied to the number of postings they mark as answered.

    Solution: See  here: http://ddkonline.blogspot.de/2013/10/build-and-packagepublish-behaviour.html

    The key thing is - your common project assemblies need to be added in a particular order (in the order your assemblies need to be built)

    • Edited by Venenum Tuesday, February 18, 2014 10:09 AM
    Tuesday, February 18, 2014 7:34 AM