web part development

I would also suggest using a CAB file project for installing web parts.  it is much more clean and easier to maintain!

Here is a document I created for my team on web part development.  It's a bit overkill for this question, but you may find it useful.


<--------------->




Abstract
     SharePoint is a very robust web application with many feature-rich stock components known as “web parts ”.  These web parts (many provided by Microsoft) can do a great many things, but they cannot be “everything-to-everybody”.  Because of this, Microsoft has allowed its customers to create their own web parts using the exact same API  that Microsoft used to create SharePoint.   The rest of this document will briefly go over a few basic methods for creating, installing and testing web parts; focusing mainly on the creation of web parts from within VS.Net   2003 (Microsoft’s preferred IDE ).
     There are a few steps that need to be done before a web part can be built.  (1) The programmer will need to download the Microsoft.Sharepoint.dll file and register it in their global assembly cache (GAC ).  (2) The programmer will need to download and install SharePoint’s .Net SDK  (wssSdk.exe ).  (3) Finally, the developer will need to download and install Lutz Roeder's .Net Reflector program.



 
Development
Pre-Development
1.     Download and register Microsoft.Sharepoint.dll into the GAC
2.     Download and install the wsssdk.exe
3.     Download and install Lutz Roeder's .Net Reflector program.

Development Steps
1.     Using Visual Studio.Net, create a new SharePoint Web Part Project (wssSDK should have added this option to your Visual Studio Project Manager.
2.     Include reference to Microsoft.sharepoint.dll
3.     Using the sn.exe  command line utility create a KeyPair.snk file
4.     Include a CAB  project into your web part solution
a.     Include Primary Output
b.     Include Content Files
c.     Include KeyPair.snk
d.     Include other files (e.g. resX , gifs , etc)
Note: make sure that the CAB project is a dependent of the web part project
5.     Edit the AssemblyInfo.cs class, change AssemblyVersion(“1.0.0.1”)
6.     Use Lutz Roeder's .Net Reflector  to get the PublicKeyToken ID
7.     Edit the DWP file to include assembly information (e.g. <Assembly>MyWebPartProjectName, Version=1.0.0.1, Culture=neutral, PublicKeyToken=d2d0ae92999983bd</Assembly>
a.     The Assembly name [MyWebPartProjectName] is case sensitive and MUST match the compiled dll name exactly.  
b.     The entire contents of the <Assembly> tags can be copied and pasted from the .Net Reflector program
8.     The version number in the dwp file MUST match the version in the AssemblyInfo.cs file exactly.

Development Notes
1.     All public properties will be serialized and be part of the tool parts property pages.
2.     Public properties should be of the following types: String, Enumeration, Boolean, Date or Numeric.
Property Type     Displays as
String     Text Box
Date     Text Box
Numeric     Text Box
Boolean     Check Box
Enumeration     Drop Down List

 

3.     Each public property should have the following attributes:
Attribute Name     Attribute Resultant
Browsable(<true/false>)     - Displays the property in the tool pane (true or false)
Category(<Text Value>)     - Determines which category this property will appear under.
- If no category is provided, Miscellaneous will be used
- If the entry matches categories that already exist (Advanced, Layout, etc), the entry will be ignored and Miscellaneous will be used.
DefaultValue(<variable>)     - Required for proper initialization
WebPartStorage
(<storage enum value>)     - Determines who sets the value (shared is set by admin, personal is set by user)
FriendlyName(<Text Value>)     - This is the title of the property and it will show up as a label on the tool property pane.
Description(<Text Value>)     - This is the information that will display in the tool tip dialog

4.     Each property should be dependent on two defined variables.  The first is a constant which defines the default value (<private const string defaultVarValue>). The second is the variable that will store the value of the data entered (<private string varValue>).








 
Installation

1.     Copy the recently compiled CAB project to a directory on the SharePoint web server (must be placed on both production web servers).
a.     We are currently storing all of the CAB projects in the following directory:
\\<web server>\Program Files\Common Files\Microsoft Shared\web server extensions\60\WPPACKS

2.     Installing the web part can be as easy as right-clicking the CAB project and “Install Web Part”, or by using the stsadm.exe program (the right-click option is a custom batch program developed by T.Degen)
3.     Using the command line utility stsadm.exe found at: C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\BIN perform the following commands
a.     Add Web Part: stsadm -o addwppack -globalinstall -force -filename C:\<path>\<Cab Project Name>.CAB
b.     Delete Web Part: stsadm -o deletewppack -name <Cab Project Name>.CAB


 
Testing

Task      
     
Verify that you can add the Web Part properly to a Web Part zone.
     
Verify that static Web Parts render appropriately and do not cause the Web Part Page to fail.
     
Verify that the Web Part works correctly regardless of where the Web Part Page is located.
     
Verify that property attributes are correctly defined.
     
Verify that Web Part changes made in personal view are not reflected in shared view.
     
Verify that every public property can handle bad input.
     
Verify that the Web Part handles all of its exceptions.
     
Verify that the Web Part renders correctly in Microsoft Office FrontPage.
     
Verify that Web Part properties displayed in the tool pane are user-friendly.
     
Verify that the Web Part appears appropriately in the search results.
     
Verify that you can import and export the Web Part properly.
     
Verify that the Web Part previews properly.
     
Verify that the Web Part can access its resources in different setup configurations.
     
Verify that Web Part properties are not dependent on each other.
     
Verify that Web Parts work correctly with different combinations of Web Part zone settings.
     
Verify that the Web Part renders appropriately based on user permissions.
     
Verify that adding several instances of the same Web Part to a Web Part Page (or in the same Web Part zone) works correctly.
     
Verify that Web Part caching works correctly.
     
Verify that requests to other HTTP sites or Web services are asynchronous.


Original Source:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odc_SP2003_ta/html/Office_SharePointWebPartsTestingChecklist.asp

 
Appendix

SharePoint Developer to Developer
http://msd2d.com/

Introduction to Web Parts
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odc_SP2003_ta/html/sharepoint_modifyingui.asp

Building a Basic Web Part
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/spptsdk/html/CreateWPToolPart_SV01003711.asp

Web Part Design Considerations
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/modcore/html/deconguidelinesforbuildinggoodwebparts.asp

Advanced Web Part Design
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odc_SP2003_ta/html/sharepoint_modifyingui.asp

Deploying Web Parts
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odc_SP2003_ta/html/sharepoint_deployingwebparts.asp

This issue is still not resolved.  After following all of the above suggestions, making a CAB file, rebooting server, resubmitting the cab file with -force (this places the lates 'dll file on the server).  All changes after the first submission are not reflected.  This is not much use to me if I cannot update dll files and have them reflected on the sharepoint server.

Any help is appreciated.

You can try resetting your IIS server (Start> Run> IISRESET), but this will shut down your IIS server for about a minute.

If rebotting the IIS services did not help, then your new dll is not properly registered in the GAC or is not specified in the Web.Config file correctly.

How many web servers do you have in your farm?  You need to keep in mind that this new dll has to reside on ALL web servers in your farm as well.

IIS reset has been tried.  It is in the web config.  It is not a problem with being a "Safe Control".  The issue is after re-uploading a new .dll file, the web part still looks like the old one.

I am working on a single server development server.

I also had to use the .net configuration tool to give rights to my .dll file to actually query the SQL server database.  Is there some type of waiting period that these changes may propogate?  Is there some service I need to stop and restart?

>> Is there some type of waiting period that these changes may propogate?  Is there some service I need to stop and restart?

No, and no... You see what is odd is that it sounds like you've done everything right.

At the risk of insulting your intelligence, here's the list of steps that need to be done from start to finish.  Perhaps you simply overlooked one of the early steps and now it's causing you grief.

1) Create a web part (use the cab project scenario I provided above, it makes it easier in the long run).

2) Install the cab project using stsadm tool

3) add the web part to a page somewhere

4) Alter web part source code, change the version number in 2 places and compile

5) Uninstall current (now defunct) web part

6) Install the new and improved web part.

7) re-add the web part to the page and view it.

Install web part
stsadm -o addwppack -filename C:\temp\MyWebPart.dll -globalinstall -force

uninstall web part
stsadm -o deletewppack -name MyWebPart

I had been missing trying the uninstall and version changes.  I accomplished both and still no go....any other ideas?  My intention here is to be able to upload a web part make it available to my users and then be able to update the web part without having to remove it from all of the pages it has been added to and readding for each version.  Is this something that should be do-able?

If you change the version number then you need to remove the web part from each and every page and re-add it.

If you keep the same version number, then you need to do an IISRESET for the new version to take affect.

This is, of course, after you perform the un-install and then install the new dll.

OK All,  I have the definitive answer for my problem.  If I place the .dll in the GAC, it requires an IIS reset every time I update the .dll.  Each time I want to update the web part, this requires deleting the .dll from the GAC and placing the new .dll in the GAC, then IISReset again for the update to kick in.

Simpler method is to do the following.

Make sure that the .dwp file is clean and simple.  If a public key token is in the .dwp file, sharepoint is going to look in the GAC which requires iisreset.  You want the .dll in the bin without any reference to the bin.  Make sure to change your security level as needed, most web parts that do anything other than display links or info. (query anything) require at least medium trust.

Problem is.......if business rules change, then web parts must change with them.  If the web part has been placed on 50 - 100 pages...redeploying webparts becomes unbearable.  Two choices here, place it in GAC then iisreset continually or place in bin with a medium trust level.

The only way I see it is either place the .dll in the GAC = full trust or place dll in the bin = medium trust....

My need here is to able to update a webpart easily but keep the trust levels at a minimum.  I suppose if I placed the .ddl in the GAC I would only be allowing each individual webpart to be fully trusted.  Perhaps this is better than allowing medium trust for the entire site.  As it is for now though, my web server is not open to the outside world except through vpn or terminal server access.  I am also trying to get a custom trust policy working.  Perhaps someone has actually done this and can enlighten me.  I have used the MS writeups to no avail so far.