Best practices for the local, stand-alone SharePoint development environment
1. Plan ahead. Do not let the ease of use of SharePoint Products and Technologies guide your development.
2. Until your code is running as expected, avoid using production components (such as Active Directory) in development environments.
3. Document your code with good comments for future problem solving.
4. Avoid logging events in the operating system event files, because in case of a problem – it is hard to detect operating system issues. General logging practices are provided in the Patterns and Practices reference at the end of the article.
5. Clean up/dispose of SPWeb and SPSite objects (for more information, see Best Practices: Using Disposable Windows SharePoint Services Objects).
6. Avoid using the SPWeb.AllowUnsafeUpdate property, as setting this property to true can leave your code open to security risks, potentially introducing cross-site scripting vulnerabilities.
7. Avoid any direct access to the SharePoint databases. (For more information, see Support for changes to the databases that are used by Office server products and by Windows SharePoint Services).Accessing these databases programmatically or manually can cause unexpected locking within Microsoft SQL Server that can result in overall performance problems.
8. For code access security, use the following table to help you determine where to install your assemblies, either in the Bin directory or global assembly cache.
Bin |
Global assembly cache |
|
Trust level |
As specified in web.config file. Can specify detailed policies. |
Grants Full trust to your assembly without affecting the trust level of assemblies installed in the BIN directory. |
Scope / availability |
Web application (Internet Information Services (IIS) Web site). |
Affects the whole physical server. |
Strong name |
Optional |
Required |
Requires restart |
No |
Restart IIS or at least recycle the application pool each time you recompile assemblies. |
Tighten security |
This option is less secure. Assemblies installed in the global assembly cache are available to all virtual servers and applications on a server running Windows SharePoint Services. This could represent a potential security risk as it potentially grants a higher level of permission to your assembly across a larger scope than is needed. |
|
Licensing |
Licensing issues may arise due to the global availability of your assembly. |
|
Upgrade from SharePoint 2003 |
Gradual upgrade does not upgrade items to the new \BIN folder, so you must redeploy your Web Parts. |
|
Existence |
If a Bin directory does not exist, you must add one. Do not store Web Parts in the _app_bin directory. |
Exists |
Comments
- Anonymous
March 18, 2008
PingBack from http://stevepietrekweblog.wordpress.com/2008/03/18/links-3182008/