CLYDE BARRETTO's BLOG - .NET etc.

Home

CLYDE BARRETTO's BLOG - .NET etc. - WebPart

Visual Studio/.NET/Smart Client/SharePoint

Blogroll

Contact

Email Me

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

Saturday, January 23, 2010

'jQuery' is undefined error in Sharepoint

We are currently using the jQuery library as part of providing a SharePoint solution. We are using the library to provide the client with a rich interface in the browser.

We had included the references to the jQuery library in our Master Page for the site. We had had developed several Sharepoint web parts which in some cases needed the jQuery library.

Since we started using it we have seen our SharePoint pages get 'stuck' very often - mostly we have had to kill our browser sessions. The behavior is inconsistent and there is not specific way to trigger it off - just loading a page does it. The first pointer to us that it it had to do with something related to loading the jQuery libraries was when our browser in some instances started throwing the error below - we were using Internet Explorer 7.

Error: 'jQuery' us undefined

Code:0

Current Solution: We copied all the jQuery to the local web server and everything seems to be working properly now. I will find a long term solution, but for now this will do.

1/23/2010 1:27:51 AM (Eastern Standard Time, UTC-05:00)

Comments [4] .NET 2.0 | jQuery | SharePoint | WebPart |

Thursday, November 05, 2009

Tips for Debugging SharePoint WebPart\WebParts during Code Development

When adding a web part to a Web Page in DESIGN MODE OR implicitly RUNNING a web part when you load a page,you might face issues like the page not loading due to recent code changes in the web part code.

Here are some basic steps to troubleshoot and Debug the code in your SharePoint web part.

** IMPORTANT NOTE: The steps should ONLY be really used in your DEVELOPMENT ENVIRONMENT. Once you are done with your debugging\troubleshooting – please REVERT your edits. If these changes get into your production site they could cause security\performance issues. To make it simple make a copy of your web.config before you start.

Viewing the CALL STACK on your web page – Open your SharePoint Web Site’s web.config

Find the tag <SafeMode MaxControls="200" CallStack="false". Change the CallStack value to true
Find the tag <customErrors, set the mode=”RemoteOnly”
Run your web page

DEBUGGING CODE in your Web Part using Visual Studio 2005\2008

Set the debug flag to true in web.config < compilation batch="false" debug="true">
Open your Web Part Code Solution in Visual Studio
- Go to Project properties, in the Debug tab make sure your “Start browser with URL” points to your SharePoint site where your web part is hosted
- Make sure your break points are set. Click F5.

11/5/2009 1:55:32 PM (Eastern Standard Time, UTC-05:00)

Tuesday, November 03, 2009

Cannot see Newly Created\Deployed SharePoint WebParts\WebParts to add to a Page or WebPart Zone in a MOSS environment

Just got a request from someone that they could only see only certain Custom Web Parts not all (developed in Visual Studio 2008) for selection in SharePoint . They were trying to add the web part to a web zone on a page. They created a new solution and were deploying their web part using VSeWSS 1.3. The ‘Deploy’ option in Visual Studio option did not error out so there was not issue there.

The first thing we checked was did the SharePoint DLL get copied in the appropriate folder in our case C:\Inetpub\wwwroot\wss\VirtualDirectories\<portnumber>\bin. It did. The date time stamps were also reasonably in sync.

Next we checked if the DLL contained web part definitions, we did this by using StartàAll ProgramsàMicrosoft Visual Studio 2008àVisual Studio ToolsàVisual Studio Command Prompt. Type in ILDASM, this will open the .NET Framework Disassembler à Open the SharePoint WebPart DLL from the bin directory mentioned above. The WebPart Definitions were not there!

That meant that deploy was not copying the files to the right location. Next thing was to check the location where the files were being deployed Open the solution in Visual Studio 2008à Project Properties à Debug tab. The start browser was set to http://localhost/ which was not the SharePoint site where the web part was support to be deployed it was supposed to be deployed at http://localhost:<portnumber>. We changed the URL and the web parts were now visible!

So the question was why did the Web Part DLL exist in the wrong directory in the first place, the answer turned out to be there were older versions of the Web Part project which had their URL’s set correctly which were still being compiled by developers currently hence the confusion.

Moral of the story: Check your URL First, then the contents of the DLL to check if the Web Parts are being deployed correctly. Off course you could have a host of other issues that could prevent your web parts from being shown, but this is what happend in this case.

11/3/2009 12:50:08 PM (Eastern Standard Time, UTC-05:00)