SharePoint Online与本地服务器代码兼容性及FieldType映射问询

Great questions—let’s break this down one by one since SharePoint Online (SPO) and on-premises SharePoint have distinct runtime environments and API differences:

1. Can SharePoint Online-based code run directly on an on-premises server? #

Short answer: No, not without modifications. Here’s why:

• SPO relies on the Client-Side Object Model (CSOM) or modern libraries like PnP Core SDK, while on-premises SharePoint supports both CSOM and the Server-Side Object Model (SSOM). Even if your SPO code uses CSOM, there are critical differences:
  • SPO has exclusive field types (e.g., modern Person columns, JSON columns, or site columns tied to Microsoft 365 services) that don’t exist in on-prem versions (2013/2016/2019).
  • API endpoints and authentication mechanisms differ (SPO uses OAuth/Entra ID, on-prem often uses NTLM or Kerberos).
  • Some CSOM methods or properties available in SPO may be missing or behave differently in on-prem CSOM.

2. Do you need a separate codebase for on-premises adaptation? #

It depends on your scope, but you don’t necessarily need two entirely separate codebases—you can optimize with abstraction:

• Use a layered architecture with a shared data access layer that encapsulates environment-specific logic. For example, create an interface like ISharePointService with implementations for SPO and on-prem.
• Leverage the PnP Libraries (e.g., PnP Framework, PnP Core SDK), which have built-in support for both SPO and on-prem SharePoint. These libraries abstract many low-level differences, but you’ll still need to handle edge cases like field type discrepancies.
• If your code heavily uses SPO-exclusive features (e.g., Microsoft Lists integration, Power Platform hooks), you may need to write conditional logic or alternative implementations for on-prem.

3. Will code automatically convert between SPFieldType and FieldType? #

No, there’s no automatic conversion between these two enums, and they’re not interchangeable:

• SPFieldType belongs to the Microsoft.SharePoint namespace (part of the on-prem SSOM).
• FieldType belongs to the Microsoft.SharePoint.Client namespace (used for SPO CSOM and on-prem CSOM).
• While some enum values share the same name (e.g., Text, DateTime), their underlying integer values may not match, and many types don’t have a direct 1:1 mapping. For example:
  • SPO’s FieldType.TaxonomyField maps to on-prem’s SPFieldType.Taxonomy, but you’ll need to use different classes (TaxonomyField in CSOM vs SPFieldTaxonomy in SSOM) to interact with them.
  • SPO’s modern JSON field type has no equivalent in on-prem SharePoint.

4. Field Type Mapping Reference & Code Example #

Below’s a practical C# example of mapping common SPFieldType (on-prem SSOM) to FieldType (CSOM/SPO):

using Microsoft.SharePoint;
using Microsoft.SharePoint.Client;
using System.Collections.Generic;

public static class FieldTypeMapper
{
    // Map on-prem SPFieldType to CSOM FieldType
    public static Dictionary<SPFieldType, FieldType> OnPremToCsomMapping = new()
    {
        { SPFieldType.Text, FieldType.Text },
        { SPFieldType.Number, FieldType.Number },
        { SPFieldType.DateTime, FieldType.DateTime },
        { SPFieldType.Choice, FieldType.Choice },
        { SPFieldType.Lookup, FieldType.Lookup },
        { SPFieldType.Boolean, FieldType.Boolean },
        { SPFieldType.Currency, FieldType.Currency },
        { SPFieldType.URL, FieldType.Url },
        { SPFieldType.User, FieldType.User },
        { SPFieldType.MultiChoice, FieldType.MultiChoice },
        { SPFieldType.Note, FieldType.Note }
    };

    // Reverse mapping: CSOM FieldType to on-prem SPFieldType
    public static Dictionary<FieldType, SPFieldType> CsomToOnPremMapping = new()
    {
        { FieldType.Text, SPFieldType.Text },
        { FieldType.Number, SPFieldType.Number },
        { FieldType.DateTime, SPFieldType.DateTime },
        { FieldType.Choice, SPFieldType.Choice },
        { FieldType.Lookup, SPFieldType.Lookup },
        { FieldType.Boolean, SPFieldType.Boolean },
        { FieldType.Currency, SPFieldType.Currency },
        { FieldType.Url, SPFieldType.URL },
        { FieldType.User, SPFieldType.User },
        { FieldType.MultiChoice, SPFieldType.MultiChoice },
        { FieldType.Note, SPFieldType.Note }
    };

    // Handle special cases like Taxonomy fields
    public static FieldType MapTaxonomyField(SPFieldTaxonomy onPremField)
    {
        // For CSOM, Taxonomy fields are represented as FieldType.TaxonomyField
        return FieldType.TaxonomyField;
    }
}

Key Notes for Special Field Types: #

• Taxonomy/Managed Metadata: Use TaxonomyField (CSOM) or SPFieldTaxonomy (SSOM) instead of relying solely on enums—you’ll need to interact with their specific properties (e.g., TermSetId).
• Modern Fields: SPO-exclusive types like JSON, Image, or Location have no on-prem equivalents. You’ll need to either skip these fields in on-prem implementations or use alternative column types (e.g., Note fields for JSON).

内容的提问来源于stack exchange，提问作者Stephen McCormick