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

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

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

1. Set the debug flag to true in web.config < compilation batch="false" debug="true">
2. 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.

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.

If you create a web part using Visual Studio 2008 extensions for Windows SharePoint Services 3.0, v1.3 you may not be able to Deploy your Web Part to your SharePoint web site (WSS\MOSS).  Your first step off course should be to read the release notes posted by Microsoft as suggested by the error message. In my case the issue turned out to the security account that was linked to the VSeWSS WCF Service did not have administrator permissions.

 

Steps that caused the error

1.       Create new web part project and solution, choose deployment to bin directory.

2.       Choose the Deploy option by right clicking on the solution in the Solution Explorer.

 

Solution that worked for me à Added the ‘Network Service’ account to the Administrators group.

 

Finding Root Cause and Solving it (if it was similar to mine)

1.       Open IIS and navigate to the Web Sites folder. Select VSeWSS.

2.       Open the properties window for VSeWSS. Note the Application Pool value under the Home Directory tab.

3.       Under IIS go to the Application Pools folder, locate the Application Pool for VSeWSS.

4.       Open the properties window for the Application Pool. Note the Security Account value under the Identity tab.

5.       Open Computer Management. Locate the Administrators Group under Local Users and Groups.

6.       Make sure the Security Account is added to the Administrators group.

·          If the security account is not under the Administrators group your root cause should be similar to mine.

·          Helpful Note: If you are working on a Virtual\Local Server you may not be able to find your security account e.g. you may not be able to find your Network Service account, make sure you are searching for the account in the right spot by choosing the right Location (Network or local machine) when the Add Users… dialog comes up.

7.       Restart IIS if you had to add the security account and try deploying your web part again.

 

My Error Description (When trying to Deploy the web part)

“Error       1              VSeWSS Service Error: Assembly C:\Documents and Settings\username\My Documents\Visual Studio 2008\Projects\MyWebPartsOne\bin\Debug\MyWebParts.dll not found. This may occur because the VSeWSS WCF Service does not have local administrator permissions. Please review the release notes.

VSeWSS Service Logging Error: Access to the path 'C:\Documents and Settings\Default User\Application Data\Microsoft\VSeWSS 1.3' is denied.

Logging failed attempting to write to C:\Documents and Settings\Default User\Application Data\Microsoft\VSeWSS 1.3\VSeWSS1.3 service.log. This may occur because the VSeWSS WCF Service does not have local administrator permissions. Please review the release notes. “

 

URL for Visual Studio 2008 extensions for Windows SharePoint Services 3.0, v1.3

http://www.microsoft.com/downloads/details.aspx?FamilyID=B2C0B628-5CAB-48C1-8CAE-C34C1CCBDC0A&displaylang=en

I have used events in the past extensively when developing windows applications. I just discovered a new feature recently when developing a windows workflow application. The ability to execute Code when Host Programs Add\Remove\Raise Events in your custom control\object.

I have developed a sample project to demonstrate the custom event feature. When you run the solution click on the "Add Handler" and "Remove Handler" buttons, you will see custom code getting invoked. One needs to be familiar with the base windows event\delegate model before your understand what is happening here to appreciate it fully. 

Download CustomEvents.zip, unzip it and run the solution.

CustomEvents.zip (36.98 KB)

Team Foundation Server, setting up your version control folders and branch relationships to properly merge code in the model

Somebody asked me a question how to make a form immovable once it is loaded - I am sure this is not a very common request...I looked at the form properties but did not come across any property at the form level that achieves this...so I wrote some code to do it - it seems to work. Throw this code into your form code...

'Trap Initial Form Load to capture initial form coordinates
Dim originalLocation As System.Drawing.Point

Protected Overrides Sub OnLoad(ByVal e As System.EventArgs)
   MyBase.OnLoad(e)
   originalLocation = Location
End Sub

'After location changes restore back to original location
Protected Overrides Sub OnLocationChanged(ByVal e As System.EventArgs)
   MyBase.OnLocationChanged(e)
   Location = originalLocation
End Sub

I picked up this month’s MSDN magazine and came across an interesting article. The article described a way to test .NET Classes though the command line!!! Who would have thought of that - obviously Microsoft did and is achieved through a free downloaded program called Window PowerShell. This excited me due to its potential of Unit testing objects. Here is the link to the article http://msdn.microsoft.com/msdnmag/issues/07/05/TestRun/default.aspx

 

Here is what I did first

• Downloaded Windows PowerShell for XP from http://www.microsoft.com/windowsserver2003/technologies/management/powershell/download.mspx
• Open Windows PowerShell through your Start Menu. The first things I tried to do was type in old DOS command like dir etc. and they worked. In fact the tool gave me more information on the files e.g. was the file in the listing read-only etc.
• The first programming I try to do is to write a program\profile that executes on start up – here is how I got it working
  • The article mentions that you can view your profile file (startup script file) when you type notepad.exe $profile. But that does not quite work since it seems the file does not exist by default.
  • Type $profile in the command line. This will show you the path of the startup script file
  • Create the directory and file physically in the path show e.g. My Document\WindowsPowerShell\Microsoft.PowerShell_profile.ps1
  • Now go back to the power shell prompt and type notepad $profile – this opens up the profile file correctly now
  • In the profile file type in the text below and save. Open power shell the script should execute…
    • C:
    • C:\
    • write-host "My first windows power shell script"
  • Well it won’t execute by default. Power shell disables script execution by default for security reasons – to enable scripts to execute, I executed the command
    • set-executionpolicy unrestricted
  • Re open the Windows PowerShell program, you will now see the message “My first windows power shell script” and notice that your default directory is C:\
  • !!SUCCESS!!!

 

More to follow tomorrow\this week – this is exciting cannot wait to start unit testing….

My First Windows Mobile 5.0 Program using Visual Studio 2005 - T-Mobile Dash Smartphone - Steps for beginners and sample first program with source code

If your .NET solution contains projects that contain custom/user controls for windows/web forms these controls are automatically loaded into the toolbox so that they can be utilized on your forms. In some cases when there are a large number of controls in your project the solution seems to compile slowly or the toolbox seems to take quite some time to load. If you are facing such issues turn off the AutoToolboxPopulate property on the ToolsàOptionsàWindows Forms DesigneràGeneral tab.

Writing Cross-Language .Net Solutions in VB.Net, Visual C# and Visual J#

I have uploaded the Mirosoft Reston Code Camp presentation and source code for my talk on custom controls (with data binding) at http://www.knowthycode.com/Downloads/20060608/WinForms_Custom_Controls_Presentation_Clyde.zip

The schedule and details for the Reston Code Camp can be viewed at http://www.madcodecamp.com/schedule/codecampmain.htm. Hope to see you there.

Geoff Snowman and Lamont Harrington are going to host a, what I believe to be an excellent session on Biz Talk integration. So if you are a novice, expert or simply want to know more about Biz Talk and how it integrates with other microsoft products come on over. Find out more at http://caparea.net/Meetings+and+Events/509.aspx

Boosting performance when using solutions that contain large Visual Basic projects in Visual Studio 2005

HOTFIX: For Visual Studio 2005 crashing/compile errors message while Debugging using Edit and Continue or ASP.Net

Designing and Testing a User Control in Visual Studio 2005 using the Test Container

Smart Client Custom Controls Powerpoint Presentation and Source Code