Tag Info

Hot answers tagged

11

F5 debugging is pretty cool, but for small and not complicated projects. You know, that by pressing F5 your solution will be deployed again, including all steps - add solution, install solution, activate features. And it often takes really long time. There is a couple of extensions for visual studio that makes your life easier. As for me, I use CKS DEV ...


6

Append ?contents=1 to the end of your query string to delete broken web parts from the page.


5

My biggest issue with testing timer jobs was getting the job to start so that I could debug it. It seems like I when I reset the timer service whenever I deployed new code and when the service restarted, even though I had my job to run every minute, sometimes it would take up to an hour for it to "catch up" and get around to running my timer job. I think ...


5

You best chance is to try at least four things while debugging: Use logging library "SharePoint Sandbox Logging" to log errors on feature activation, as you probably know logging capabilities on Sandbox are limited. Have Correlation Id with your error? contact Microsoft support Review SharePoint logs for on-premises Sandbox to check for any errors, ...


4

This sounds like you're studying for TS: SharePoint 2010 Application Development 70-573. The part that says what's included are actually practices any development in SharePoint, not specific to Web Parts. It seems strange to me though, that their list doesn't include the most powerful debugging utility available to a developer - Attaching to w3wp and ...


4

If you're getting this error on sharepoint/wss specific pages, you also have to add following fragment to your web.config to view the stacktrace: <SharePoint> <SafeMode MaxControls="200" CallStack="true" DirectFileDependencies="10" TotalFileDependencies="50" AllowPageLevelTrace="false"> <PageParserPaths> ...


4

You'd have to use something like .NET Reflector and its Visual Studio plugin in order to actually step through the code in the debugger. With something like ILSpy you can take a look at the code, but not step through it, which may well be enough to discover what's going wrong without spending money.


4

According to this post How to debug Feature Receiver you can add this line of code to the method you are trying to debug: System.Diagnostics.Debugger.Launch();


4

I would check the ULS logs with a tool like the ULS Viewer. Start a trace, load the page again and check the viewer. It may reveal more details about what's happening to cause the problem. Here's a link: http://archive.msdn.microsoft.com/ULSViewer


3

Please follow this tutorial, I have done it thousands of time and it always work the same way. http://msdn.microsoft.com/en-us/library/ff798479.aspx


3

The problem is that in SharePoint, you have no idea how many web servers is running your site, and therefore you've no idea how many web.config's could be running (not you in particular, but in general, SharePoint can handle dozens of web front end servers). In order manage changes to the web.config file, the object model is design such that any and all ...


3

If you are using VS2010 to deploy the feature, try changing the Active Deployment Configuration in the Project Properties\SharePoint tab to "No Activation". When you run the application with debugging (F5), it will deploy the package and activate it before the debugger attaches to the process. Turning off automatic activation will allow you to attach to ...


3

You can use System.Diagnostics.Debugger.Launch(); to attach a debugger (Visual Studio) instead of attaching the timer job in VS. Also i tend to use DebugView alot to just write out asserts or messages like System.Diagnostics.WriteLine("sometext","MYCATEGORY"); Another tip for testing is to encapsulate the logic in its own class. Then you can test ...


3

This is why i only work from VM's, they're easily replaced, and my host OS (Server 2008R2) remains clean and fast. I have a whole domain running in multiple VM's and only have the bare minimum installed directly on my laptop (Only Office basically). Whenever a new version of a product is released, i create a new VM and test / try it in there. If it breaks, ...


3

I am not pretty sure how you are debugging your SharePoint portals right now. But I would suggest you look at the Visual Studio 2010 extensions and different techniques that make debugging life easier. Please go through this post where all these are consolidated at one go. ...


3

When the piece you are debugging can run from a sandboxed solution, F5 debugging is much faster. For one thing, you don't have to recycle the application pool. To me, that feels much more like the typical plain asp.net debugging situation. Not every solution can fit in the sandbox and benefit from this speed up. Sometimes, the incompatability with the ...


3

I have seen this behavior before when IIS is not cycled after VS builds and deploys to the GAC. In those cases, it is using a cached copy of the code and thus the breakpoints do not line up. An occasional IISReset will flush this through. The other thing to try is manually attach to ALL W3WP.exe processes and see if it hits your breakpoints then. If it ...


3

Just to be clear - you want to debug an already deployed Sandboxed solution, you need to attach the SPUCWorkerProcess.exe proccess manually and hit F5 to debug! Occasionally a VS restart helps as well as a good old stop/start of the Sandbox Service via SharePoint CA!


3

You have two options: Catch all errors in your web part and then log them to ULS, show in hidden div, ... Develop you web part in a Sandboxed solution, then SharePoint will take care of protecting the rest of the page To elaborate on the first. It can be implemented using this pattern: Add a string variable errorMessage string errorMessage; Write ...


3

Napa was created with the objective to facilitate a 'lightweight, in-browser experience' to build SharePoint or Office web app in the same browser where they would run. Ergo, it was designed to kind of complement the inherent features of the browser. For advanced tooling, one would have to turn to Visual Studio 2012 You can debug code like any javascript: ...


3

As strange as it may seem, this error is often experienced when you are debugging a SharePoint App and you never had published your solution (so the solution package has not been created). Use the "Publish" command to create the package and debugging should work normally afterward. Notice that the deploy functionality works even without the publish step so ...


3

If it is a user control, you can just replace the .acsx file in the Layouts folder. But if it is a C# file, you need to build the project without changing the assembly version and copy that into the GAC (assembly folder). There are some third party VS tools such like CKSDev.


2

A couple of small things you have probably already considered. Stop and restart the Timer service as part of the pre-build event to release any of your solution's GAC dlls. Rather than attaching to the process using the debugger I prefer to use System.Diagnostics.Debugger.Break(); For other SharePoint related guidelines, check out our free SharePoint ...


2

As both Anders and Steve have pointed out, write the main processing of your timer job in a separate Class Library. For debugging "wrap" a Console App around it, and when you're happy wrap it in a timer job. If at a later point you want to debug, you use your Console App again - F5 and there you go. On a related note, check out SharePoint Layered ...


2

Are your symbols available? You might need to copy the PDB file to the GAC. Here are some articles on the subject: http://blogs.msdn.com/b/markarend/archive/2008/09/09/debugging-web-parts-and-other-sharepoint-custom-code.aspx You also might want to try inserting a line of code that pops up a window asking if you want to debug it. From ...


2

Also the dlls are deployed in GAC , so make sure change the settings. Follow this article http://www.sharepointnutsandbolts.com/2007/03/how-to-debug-sharepoint-feature.html


2

I have been able to create a workaround, although the reason for the failure is still unknown. I suspected that the Sandboxed code service was acting up because my code performs a lot of requests in a short amount of time (it has to, since it creates a site from scratch). I still don't have an explanation why it works on the server installation, the sandbox ...


2

Why would you debug a solution to SharePoint Server Farm, which I assume should be a Test, UAT or Production Farm (God forbid)?? You should have been debugging your solution in development environment. It's just doesn't make any sense when you have the tools such Visual Studio 2010 and onward versions to help you with debugging with simply a click of F5 ...


1

Couple of extra suggestions: I assume you are debugging locally on the machine that is running central admin. If there are multiple servers in the farm, just make sure you are on the server that is actually running central admin. Try killing the vssphost4 process, and then restart visual studio. I have found that the method VS (which is 32 bit) uses to ...



Only top voted, non community-wiki answers of a minimum length are eligible