1. Know When to Cross

A problem that occurred early in the development of SharePoint was how best to interact with other systems. Because SharePoint is a composite application platform, this question is one you may have to answer frequently. Looking at the SharePoint architecture, starting at the Web application level is the easiest way to get started. An instance of SharePoint contains multiple Web applications. If you are unfamiliar with SharePoint application architecture, you should check out SharePoint Services

2. Advantage with native SharePoint features

Two scenarios can result from development teams taking advantage of the full native functionality in SharePoint. For the first time, since SharePoint is such a large platform, you may find it easier to build custom solutions rather than spend time understanding what SharePoint provides without custom coding. Second, business owners tend to create detailed requirements, wireframes, and application behaviors that allow little flexibility when using out-of-the-box (OOB) functionality.

But even the resulting deliverables are slightly significantly different from the original requirements using the SharePoint platform usually offers pay dividends. The key to gaining this advantage is for the development team to have a thorough understanding of the technology and, even more importantly, to clearly communicate the value and the business owner's specific implementation compromises.

3. Know important SPDev tasks and information

This section is intended to elucidate common tasks that every SharePoint developer may need to complete during software development. This is not a tool check, nor is it intended to elevate one tool over another. Instead, we provide suggestions for tools for accomplishing common SharePoint development tasks.

Building a SharePoint solution is one approach you take. Ted Pattison sums it up nicely on his Office Space column " Solution Deployment with SharePoint 2007 " as he writes, "Packaging setup, and deploying using solution packages in the WSS development process is best practice and knows how to perform Basic skills that should be considered for this operation". Manually creating manifest.xml and Diamond Directive files (DDFs), using Windows SharePoint Services 3.0 Tools for Visual Studio projects to package your SharePoint solution, are: Visual Studio 2005/2008 Extensions (VSeWSS).

Using VSeWSS projects is easier than manually creating DDFs. However, some alternatives are available especially for commercial or enterprise deployments, including WSPBuilder, STSDev, SPDeploy, and DDFGenerator. Evaluate various tools to find the one that best suits your needs. The key is to manually create solution package deployments, not deploy code components.

4. Develop solutions for servers shutting down

As much as possible, you should build solutions with no dependencies that SharePoint development typically implements. By using Visual Studio Development Server, ASP.NET Web Parts framework support, SharePoint Web services, and third-party tools, you can do most of your development on a standard workstation and a computer running SharePoint.

Because SharePoint runs on top of IIS and ASP.NET, the Web Development Server that ships with Visual Studio is an excellent starting point for your SharePoint development in bulk. It is, for example, a relatively lightweight environment in which you can develop Web Parts, HTTP Handlers, and Web Controls.

5. Test the code, and manage dependencies

The widespread adoption of unit testing frameworks and related testing tools to SharePoint development has naturally made its approach. Unit testing and integration testing are the two main categories of testing. These two test types exhibit different characteristics and require the use of different tools and techniques.

When writing unit or non-server tests, it's best to mock and replace external dependencies such as stubs or mocks. By imitating the incoming in the object of external dependencies, the test becomes faster and more focused on the problem you are testing. To be effective, this approach requires you to follow the principles of testable, object-oriented design, or use a dedicated framework in your solution in order to isolate tightly coupled components.

Determine behavior and separate infrastructure and ensure you have business rules for testing these policies in isolation. Find out the details of interoperating with SharePoint, a database or a Web service that can be introduced into the repository pattern to abstract away the back-end system. These repository objects can be passed to higher-level components through Inverted Control (IoC) and Dependency Injection (DI) principles. For IoC and DI information, see " Tame your software dependencies for a more flexible application ."

To improve the testability component of your presentation, implement the Model-View-Presenter (MVP) pattern. For more information on testable code patterns, see " Designing for Testability ."

The other major challenge for the SharePoint developer is when unit testing deals with the SharePoint object model. Simply put, testing these components in isolation is an important task. It is a direct result of a limited number of interfaces and abstractions and a large number of sealed classes, classes that use internal dependencies or classes that do not have public constructors.

6. Continuous integration and automatic generation

Keeping code in source control, relying on continuous integration, and automating the build process are essential steps for effective versions of high-quality code assets. SharePoint makes this environment challenge, set at least. The most important starting point for this tip is in the " Team Development Overview " topic.

Later in the overview, you will see the SharePoint guide topic "How to: Create an Automated Build and Deployment Solution with a Team Foundation Server Build" This topic focuses on how to create a build target that builds and deploys a solution. While this approach has on-site, it is not typically used in an enterprise when the TFS build and the SharePoint server do not reside in the same environment. Building packages that use target-in-solutions restricts the use of packages for automated build environments and therefore discourages early development and testing of packages by developers.

The workaround is to use post-build events in Visual Studio. The same packaging steps can be performed as an MSBuild target and allow developers to set up post-build events to deploy the build package to their own sandbox environment. This method also uses third-party tools such as WSPBuilder and STSDEV.

Versioning solution packages may also need to be considered when deploying to an enterprise. Putting the current build version in the solution version is one way. This is simplified by using custom application code that runs in the AfterBuild MSBuild event or after the build event. Also consider the automatic generation of solution IDs and whether new IDs are generated with each release. This decision affects your ability to upgrade your solution in the future. A new solution ID is generated as a general rule assembly version change. Otherwise, keep the solution ID the same as the version ID is static between builds.

7. Has SharePoint Admin custom configuration settings

Like any application, SharePoint solutions rely on configuration settings to function properly. Custom applications can be easily managed manually using only a few configuration settings. Conversely, when developing an enterprise or business application in SharePoint, this number of configuration settings can be quite large.

Understanding the different setup types and how to manage these is important for developing, deploying, and managing applications for the results. The best way to do this is to increase the settings for SharePoint management and reduce manual administration.

Knowing the types of settings helps determine what those settings belong to. SharePoint configuration settings are generally divided into three categories: core, custom, and SharePoint settings.

Use the core settings in a SharePoint Web application. The Enterprise Library application block and external web service configuration are examples of typical core setups.

The custom setup is for custom build components. These settings are used to provide configuration settings for a custom component and are not shared outside of that component. For example, custom settings can be used to provide directory server settings for LDAP lookups.

The SharePoint setup is required to make the SharePoint solution work. Settings in this category include SafeControls items, SessionState customization, or registering HttpModules.

After categorizing your setup, you can deploy it to the right location to manage it. The goal is to reduce manual administration. Let SharePoint handle the settings to reduce the number of errors that can occur when deploying applications.

Core settings are most managed in source control. This allows concurrent settings to provide a maintenance settings history of the source fact. Additionally, this approach is used to maintain separate versions of configuration files for development, test, and production environments.

Custom setup installation and management can be automated by using the SharePoint object model and deployment tools. Use the SPWebConfigModification class, solution deployment, and CONFIG catalog under the SharePoint 12 hive to compose your configuration management strategy. See the "Building a Deployable Solution" section of this article for additional details on deploying through solutions.

8. Know the location configuration settings belong to

The previous tip explained the different types of SharePoint configuration settings and how to manage them. As an application is upgraded to an environment, such as from test to production, changes to configuration settings, especially those that point to external systems, will be like a sandy beach while you're feet under. Knowing where a configuration setting belongs allows for more reliable basic management environment settings.

Composite application development has increased dependency configuration settings. The use of power and convenient configuration settings has been thought to lead to its overuse. One way to reduce the constants that change these settings is by inferring the values in the naming conventions such as applying conventions through the configuration pattern. An example that demonstrates how to integrate SharePoint solution packaging into your Visual Studio project is outlined in the "Continuous Integration and Automated Builds" section of the conventions by configuring the pattern. A related example of this example is shown in the Web content prompt "Use relative links whenever possible."

Instance-specific settings are unique to each instance of a Web Part. For example, you might display a list of projects on a Program Manager page, a Web Part that displays project and task details on a developer page. Instance-specific settings are most often stored in a custom tool section, or in a Web Part Misc Tool part properties.

Configuration settings used by multiple components are considered global settings. Examples of settings in this category include URLs for external Web services, business object settings, and data settings. These settings are best kept in Web.config and managed as described in the "Having SharePoint Admin Custom Configuration Settings" section.

9. Scaling and Maintenance of Branded SharePoint

Branding a SharePoint site provides the user with the most obvious visual indication of the application's purpose. Branding includes pages, content pages, page layouts, site definitions, and CSS using different items such as master shapes. For tips on creating a custom master page, see the online tip "Creating a Custom Master Page."

resource

Microsoft Office SharePoint Server 2007 and Windows SharePoint Services v 3

business data catalog

SharePoint 2007: BDC)</a0> - Business Data Catalog

WebPart class (Microsoft.SharePoint.WebPartPages)

Make sure that your application's scaling and maintenance strategy will consider how these products are managed. For more information about SharePoint branding, see "Microsoft Office SharePoint Server 2007 and Windows SharePoint Server v 3" in the "Resources" sidebar.

Before choosing a tool brand, consider the size of your SharePoint implementation, the professional technical support application developers that work with your product. We'll focus on two tools: SharePoint Designer and Visual Studio.

SharePoint Designer will have its root in FrontPage and is the web design tool for editing master pages and CSS. However, ease of use in SharePoint Designer comes at a price:

10. Build deployable solutions

You can access your components in a number of ways to a SharePoint Web application. This section focuses on how to leverage the packaging and deployment framework provided by SharePoint including Web Solution Packages (Solutions/WSPs, capabilities, and the SharePoint Object Model.

Deciding how to package components depends heavily on deploying components. The solution contains files that will be deployed to the server. Capabilities contain content that will be deployed to the content database.