18

I am using Visual Studio 2010 Ultimate and SharePoint 2010. The debugging process itself is okay but the startup takes really long. Are there any options or hidden-hints to make this faster?

Edit: I'm debugging by just pressing F5, with the standard visual studio procedure.

LMW-HH
  • 890
  • 13
  • 25

5 Answers5

14

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 extensions. How cks dev can increase debugging and even overall development process:

  • it has quick deploy actions - copy to gac\bin, copy to sharepoint root, recycle app pool, iisreset and so on
  • it adds new useful deployment steps (copy gac\bin, copy to sharepoint root, recycle app pool, iisreset, call powershell script, attach to w3wp processes, attach to other sharepoint process and many other steps)
  • and also it adds new sharepoint project items (SPI) available in add new item window

Example how I use cks dev. To debug code, I've created new deployment configuration with this steps:
1.Copy to gac\bin
2.Recycle app pools
3.Warm up sharepoint site
4. Attach to IIS worker process.
Now every time I click deploy, I have updated dll in the gac, visual studio attached to w3wp and ready to debug. This of course works faster than full redeploy cycle. If I need only update files in 14 hive I use copy to sharepoint root command form context menu.

Sergei Sergeev
  • 11,618
  • 5
  • 32
  • 49
4

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.

http://pholpar.wordpress.com/2010/05/20/visual-studio-2010-extension-for-helping-sharepoint-2010-debugging/

Otherwise you can also think about adding - Using System.Diagnostics;

in your code and then add Debugger.Launch() wherever required for a debugging prompt.

Deepu Nair
  • 6,536
  • 2
  • 22
  • 29
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 sandbox may be a small piece that you can extract and remove temporarily. If you're doing a lot of debugging, it may be worth it to extract the piece you're working on the most to run it in the sandbox during development.

I also suggest looking at the Microsoft Patterns and Practice groups documentation and code samples for logging. Logging can be a big help when debugging is slow, like for GAC assemblies that require app pool recycles on low resourced dev machines.

Tom Resing
  • 3,589
  • 3
  • 29
  • 51
1

one quick tip:
after recycling the application pool of the project. in the attach to process window you can sort desc process by name and choose the first w3wp.exe to attach and no need to select all of them.
in 90 percent of times it work just fine.

Jalali Shakib
  • 811
  • 2
  • 14
  • 28
1

There are a few things I'd suggest:

  • CKS:Dev - as above. It's great. It simplifies attaching to your W3WP, OWSTimer service, and UserCode service (for debugging sandbox solutions).
  • Consider writing a Diagnostics service so you can write to the ULS logs in a structured way.
  • Use SPMonitoredScopes and SPCriticalTraceCounters. They can be useful, though I tend to user compiler directives to exclude them from my 'Release' builds.
  • SharePoint Manager is a nice application for getting an easy view into the guts of SharePoint. I use it as a quick way to check properties, schemas, etc..
  • ULSViewer can be useful for viewing the ULS logs, oddly enough.

And not really SharePoint specific, but useful anyway:

  • Stick an automatically generated version number into your AssemblyFileVersion - and make sure you can see it somewhere, even if it's just an HTML comment in the page source. And use the AssemblyFileVersion, 'cos then the strong name is unchanged.
  • Ctrl-Alt-E brings up the exceptions dialog, where you can configure what ones are trapped. I like Visual Studio to break on handled exceptions, as well as unhandled ones.
Andy Burns
  • 4,949
  • 15
  • 20