CODEWITHSUNDEEP
asp.netsharepointdebugging
axk
axk

Reputation: 5394

How to make the process of debugging ASP.NET Sharepoint applications less time consuming?

I'm comparing it Java where you can start your application server in debug mode, then attach your IDE to the server. And you can change your code "on the fly" without restarting the server. As long as your changes don't affect any method signatures or fields you can just hit recompile for a class and the application server (servlet container) will reload the class.

I suppose this is impossible in ASP.NET since all classes are packed into assemblies and you cannot unload/reload assemblies, can you ?

So when you have an .aspx page and an assembly deployed to GAC and your codebehind changes you have to redeploy the assembly and reset IIS. I'm talking about Sharepoint applications in particular and I'm not sure whether you have to do iisreset for private assemblies but I guess you have too.

So the best way to debug aspx pages with code behind I guess would be to get rid of the codebehind for the time of active debugging and move into the page, then when it is more or less working move it back to codebehind. (This would be applicable only for application pages in Sharepoint, site pages don't allow inline code )

How do you approach debugging of your ASP.NET applications to make it less time consuming?

Upvotes: 6

Views: 3493

Answers (8)

Artem Tikhomirov
Artem Tikhomirov

Reputation: 21696

Yes private assemblies DO NOT require reset of the IIS. So you should just to xcopy new version to the application's Bin directory and refresh the page (e.g. by VS post build event as I did). But there are some trade offs. You should decrease trust level in application web.config file: 

<system.web>
    ...
    <trust level="WSS_Medium" originUrl="" />
    ...
</system.web>

By the way. I do not suggest to deploy like this. It's just workaround for comfort write-test-debug cycle length.

Upvotes: 4

Henry
Henry

Reputation: 1

What it seems like you're trying to do is tell Sharepoint "When I start debugging in Visual Studio, use the version of the DLL that was compiled in the project's /bin/debug directory instead of the version of the DLL that is registered in the GAC." I haven't solved that problem, but here is how I debug Sharepoint.

A developer machine is Win2008, IIS 7, MOSS 2007, VisStudio 2008, and WSP Builder installed. Inside VS2008, a button is added to attach to w3p.exe process, Andrew's HOWTO attach to w3p

The solution file has two projects:
* First project is the .WSP that deploys all the app pages, including the DLL. Use WSPBuilder menu items for handling the .WSP creation and deployment.
* Second project is for the DLL behind the pages.

If you want the DLL to be copied to the GAC regularly, add a post-build event to the DLL's project that copies from /bin/Debug to the GAC.

But, these days, I find I have just been recompiling the solution and then deploying the .WSP using the menu items, and then starting up the debugger using the button. It takes me an F-key and 3 clicks and about a minute for most of my projects, but I suppose it could be quicker.

Upvotes: 0

SharePoint
SharePoint

Reputation:

WSPBuilder Extensions has a "deploy to GAC" shortcut, unfortunately it never works for me. But it's a really quick way to code->compile->test.

If you're not using WSPBuilder Extensions, you can instead open a command prompt and run

gacutil /u yourassemblynamegoeshere gacutil /i yourdllgoeshere.dll

If you do this often, you can put it in a post-build event or in a batch file. Also, I'm unclear whether the gacutil /u (to remove the DLL first) is necessary.

Upvotes: 0

SharePoint
SharePoint

Reputation:

Use an automated testing framework (NUnit) to write integration tests. This won't work for everything, but of course, it depends on what you're testing.

If you also have TestDriven.NET installed, you can run individual tests with the debugger. This has been helpful.

Upvotes: 0

DylanW
DylanW

Reputation: 848

First, develop on a computer running SharePoint. Preferably, this means running Windows Server 2003 on Virtual PC or VMWare. This will let you deploy and debug SharePoint code directly, rather than having to copy files between servers and use the remote debugger.

Use a VS add-in to simplify the process of deployment and debugging. I've been using WSPBuilder but I think there are others out there. WSPBuilder has commands to deploy solutions, package them as WSPs, and attach your debugger to the local IIS process. It won't allow you to add/remove assemblies on the fly, but you can set breakpoints and run code through the Immediate window in VS.

Depending on how your production server is configured, it's usually a good idea to develop on a server with full/trust security settings, including disallowing code blocks in ASPX files. This makes debugging a little more difficult, but it reduces the number of nasty surprises you'll have when your code is finally deployed to production.

Upvotes: 1

Nat
Nat

Reputation: 14295

From Matt Smiths blog on how to get F5 debugging with sharepoint. A very cool trick.

  1. Create a web application project in Visual Studio (File -> New -> Project -> ASP.Net Web Application, not File -> New -> Web Site).
  2. Move the .csproj and .csproj.user files, along with the Properties folder, into C:\inetpub\wwwroot\wss\virtualdirectories\, where is the name or number of the web application corresponding to the SharePoint site you'd like to debug on.
  3. Attach the project to an existing solution (e.g. STSDEV project).
  4. Set as startup project (right-click project name, "Set as Startup Project").
  5. Access project properties (right-click project name, "Properties") and click
  6. Under the "Servers" setting, click "Use IIS web server", then enter the URL to the SharePoint web application you want to debug on, e.g. http://mymachine:99.

Upvotes: 5

Matt Bishop
Matt Bishop

Reputation: 1487

If you are using the GAC, you can at least do iisapp.vbs /a "App Pool Name" /r instead of iisreset (it's quicker to recycle a single app pool than to restart IIS).

Upvotes: 3

Yaakov Ellis
Yaakov Ellis

Reputation: 41490

And you can change your code "on the fly" without restarting the server

You can accomplish this with ASP.net if you make a Web Site project (as opposed to a Web Application Project). Using a Web Site project, you can post changes to code-behinds without having to refresh anything on the server, and the server does the compile work for you on all code changes. See here for more info on this.

This should also solve your difficulties with deploying the assembly to the GAC. As the server handles all compilations for Web Site projects, you wont have to redeploy any assemblies when changing files.

Upvotes: 0

Related Questions