locked
Debugging techniques with SharePoint 2013 Apps RRS feed

  • Question

  • Hello, Experts

         I am trying to debug a SharePoint app, but as i try F5 or F10 - it goes into .aspx page right away

    one article I was trying to follow is possible debugging techniques, however, it is marked as Retired Content:

    Retired Content

    This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

     

    any suggestions / recommendations would be greatly appreciated 

    -Alex

      


    AlexF

    Monday, December 3, 2012 3:43 PM

Answers

  • The appmanifest is really just an XML file that tells SharePoint where to find the remote web site where the code is.  Put breakpoints in the files under ShareTabbedWeb and think of this like any other ASP.NET web site project.  Its not expanded, but if you are looking for the first thing in the APP that will see if there is a code file under the Default.aspx file.  Other than that if you make sure you attach to the right w3wp process manually you should be able to put code breaks in any of the .cs files.  For debugging any of the .js I would use the tracing in IE developer toolbar.  Take a look at the debugging section in this article.

    http://blogs.msdn.com/b/officeapps/archive/2012/08/10/building-apps-with-windows-azure.aspx


    Paul Stork SharePoint Server
    MVP Principal Solutions Architect: BlueChip Consulting Group
    Blog: http://dontpapanic.com/blog
    Twitter: Follow @pstork
    Please remember to mark your question as "answered" if this solves your problem.


    Wednesday, December 5, 2012 1:06 PM

All replies

  • By SharePoint App do you mean SharePoint hosted app or is this either a provider hosted or auto hosted app.  If its provider hosted or auto hosted then you need to make sure that you are attaching to the w3wp process where the App is actually running.  For a SharePoint hosted app remember its all going to be client side code so you'll probably need to do your debugging in JavaScript.  I find it easier to do that using the developer toolbar in IE than Visual Studio.

    Paul Stork SharePoint Server
    MVP Principal Solutions Architect: BlueChip Consulting Group
    Blog: http://dontpapanic.com/blog
    Twitter: Follow @pstork
    Please remember to mark your question as "answered" if this solves your problem.

    Monday, December 3, 2012 3:51 PM
  • this app is auto hosted;

    should i be using manual debugging or remote debugging section from the possible debugging techniques to attach to the w3wp process  or is there a better techniques available ?  

    i am new to the SharePoint development, having done mostly development/debugging of Win apps;                   

        if my app is not SharePoint hosted, should i still be using IE developer toolbar for debugging JavaScript and VS for debugging C# ?


    AlexF

    Monday, December 3, 2012 4:17 PM
  • This might help, http://msdn.microsoft.com/en-us/library/jj841104.aspx, it was just published last week.

    Thanks


    Program Manager, Office Developer Platform.

    Monday, December 3, 2012 7:55 PM
  • auto hosted apps are designed to be hosted in Azure eventually.  But while you are working on them they will automatically be hosted on a dynamically created web site in your own server.  So if you are careful about the w3wp process that you attach to you should be able to step through any server code right in Visual Studio.  But as I mentioned the new SharePoint App model tends to use a lot more client side code.  If your app is using client side code then as I said I find IE developer toolbar the easiest place to debug.  Its a matter of understanding what code you are trying to debug and where it is actually running.  Once you know that you can use the same debugging tools you always do.

    Paul Stork SharePoint Server
    MVP Principal Solutions Architect: BlueChip Consulting Group
    Blog: http://dontpapanic.com/blog
    Twitter: Follow @pstork
    Please remember to mark your question as "answered" if this solves your problem.

    Monday, December 3, 2012 8:03 PM
  • attached is a snapshot of Solution i was given to try to debug / understand / make some modifications to going forward; based on this info, it is not feasible to tell, if majority of the code is client based or server based ?

    i wrote a back end logic for this Solution in C#/ASP.NET, then it was hooked into SharePoint and given back to me 

    i would like to debug this entire solution is possible; it is my understanding that initial starting point of any project is AppManifest.xml, but i can't put any breakpoints there; not sure how to proceed


    AlexF

    Tuesday, December 4, 2012 5:33 PM
  • The appmanifest is really just an XML file that tells SharePoint where to find the remote web site where the code is.  Put breakpoints in the files under ShareTabbedWeb and think of this like any other ASP.NET web site project.  Its not expanded, but if you are looking for the first thing in the APP that will see if there is a code file under the Default.aspx file.  Other than that if you make sure you attach to the right w3wp process manually you should be able to put code breaks in any of the .cs files.  For debugging any of the .js I would use the tracing in IE developer toolbar.  Take a look at the debugging section in this article.

    http://blogs.msdn.com/b/officeapps/archive/2012/08/10/building-apps-with-windows-azure.aspx


    Paul Stork SharePoint Server
    MVP Principal Solutions Architect: BlueChip Consulting Group
    Blog: http://dontpapanic.com/blog
    Twitter: Follow @pstork
    Please remember to mark your question as "answered" if this solves your problem.


    Wednesday, December 5, 2012 1:06 PM
  • not sure how to mark this as an answer

    Wednesday, December 5, 2012 9:43 PM