Add information about how the clipboard/dataobject changes in .NET 10

.github/copilot-instructions.md

@@ -2,48 +2,34 @@
 
 ## Disclosure
 
-IMPORTANT: For any Markdown files generated by AI, always disclose that they were created with the assistance of AI. Add the following frontmatter key/value pair:
+IMPORTANT: For any Markdown files generated by AI, always disclose that they were created with the assistance of AI. If missing, add the `ai-usage` frontmatter key/value pair:
 
-```markdown
-ai-usage: ai-generated
-```
-
-## Terminology
+- When reviewing a PR not created by AI:
 
-- Unless otherwise specified, all .NET content refers to modern .NET (not .NET Framework).
+  ```markdown
+  ai-usage: ai-assisted
+  ```
 
-## Writing Style
+- When Copilot generates the article through GitHub without the use of a human:
 
-Follow [Microsoft Writing Style Guide](https://learn.microsoft.com/en-us/style-guide/welcome/) with these specifics:
+  ```markdown
+  ai-usage: ai-generated
+  ```
 
-### Voice and Tone
+- When using an IDE with a human guiding AI:
 
-- Active voice, second person addressing reader directly.
-- Conversational tone with contractions.
-- Present tense for instructions/descriptions.
-- Imperative mood for instructions ("Call the method" not "You should call the method").
-- Use "might" instead of "may" for possibility.
-- Use "can" instead of "may" for permissible actions.
-- Avoid "we"/"our" referring to documentation authors or product teams.
+  ```markdown
+  ai-usage: ai-assisted
+  ```
 
-### Structure and Format
+## New articles
 
-- Sentence case headings (no gerunds in titles).
-- Be concise, break up long sentences.
-- IMPORTANT: Oxford comma in lists.
-- Number all ordered list items as "1." (not sequential numbering like "1.", "2.", "3.", etc.)
-- IMPORTANT: Use bullets for unordered lists.
-- VERY IMPORTANT: Ordered and unordered lists should use complete sentences with proper punctuation, ending with a period if it's more than three words.
-- Avoid "etc." or "and so on" - provide complete lists or use "for example".
-- No consecutive headings without content between them.
+- New articles must follow a template in the /.github/projects/article-templates/ folder.
+- If you don't know which template to use, ask.
 
-### Formatting Conventions
+## Terminology
 
-- **Bold** for UI elements.
-- `Code style` for file names, folders, custom types, non-localizable text.
-- Raw URLs in angle brackets.
-- Use relative links for files in this repo.
-- Remove `https://learn.microsoft.com/en-us` from learn.microsoft.com links.
+- Unless otherwise specified, all .NET content refers to modern .NET (not .NET Framework).
 
 ## API References
 
@@ -66,11 +52,66 @@ For snippets >6 lines:
 1. Create examples in both C# and Visual Basic unless the article referencing the snippet resides in the in the `csharp`, `fsharp`, and `visual-basic` language folders.
 1. When you add code, use code comments sparingly because they don't get localized. You can use them to briefly clarify code-specific details (such as logic, parameters, or edge cases). Put any critical information and context in the markdown text of the referencing article.
 
+## .NET Framework vs .NET differences
+
+When documenting differences between .NET Framework and .NET (like .NET 6 and newer), choose the appropriate system:
+
+### Use Tabs
+Use tabbed content when the differences are code-based:
+
+```markdown
+# [.NET](#tab/dotnet)
+
+<how it works in .NET>
+
+# [.NET Framework](#tab/dotnetframework)
+
+<how it works in .NET Framework>
+
+---
+```
+
+### Use Pivots
+Use zone pivots when there are conceptual differences that can't easily be explained with tabs and a note. Pivots allow for more comprehensive explanations of different approaches or methodologies.
+
+To use zone pivots:
+
+1. Add `zone_pivot_groups: dotnet-version` to the article's frontmatter
+2. Use zone pivot syntax in content:
+
+```markdown
+::: zone pivot="dotnet"
+
+Your .NET content here
+
+::: zone-end
+
+::: zone pivot="dotnetframework"
+
+Your .NET Framework content here
+
+::: zone-end
+```
+
 ## File Naming
 
 New Markdown files: lowercase with hyphens, omit filler words (the, a, etc.).
 
+Examples:
+- ✅ Good: `getting-started-with-entity-framework.md`
+- ✅ Good: `configure-logging.md`
+- ✅ Good: `dependency-injection-guidelines.md`
+- ❌ Bad: `Getting-Started-With-The-Entity-Framework.md`
+- ❌ Bad: `configure_logging.md`
+- ❌ Bad: `DependencyInjectionGuidelines.md`
+
 ## Special Cases
 
-- Breaking changes: Include directions from `.github/prompts/breaking-change.md`.
-- When you (Copilot) are assigned an issue in GitHub, after you've completed your work and the workflows (status checks) have run, check to make sure there are no build warnings under the OpenPublishing.Build status check. If there are, open the build report (under View Details) and resolve any build warnings you introduced.
+### GitHub Issue Assignment (AI Workflow)
+When assigned an issue in GitHub:
+1. Complete your work
+2. Wait for workflows (status checks) to run
+3. Check for build warnings in the OpenPublishing.Build status check
+4. If warnings exist:
+   - Click "View Details" to open the build report
+   - Resolve any build warnings you introduced

.github/instructions/Markdown.WritingStyle.instructions.md

@@ -0,0 +1,83 @@
+---
+applyTo: 'dotnet-desktop-guide/**/*.md'
+description: 'Follow these comprehensive writing style guidelines when creating or editing Markdown documentation. Apply active voice, conversational tone, Oxford commas, and specific formatting rules to ensure consistency and readability across all documentation.'
+---
+
+# Markdown Writing Style Instructions
+
+When writing or editing Markdown documentation, follow these style guidelines:
+
+## Voice and Tone Requirements
+
+ALWAYS write using:
+- Active voice with second person ("you")
+- Conversational tone with contractions
+- Present tense for instructions and descriptions
+- Imperative mood for instructions (write "Call the method" NOT "You should call the method")
+- "might" for possibility (NOT "may")
+- "can" for permissible actions (NOT "may")
+
+NEVER use:
+- "we" or "our" when referring to documentation authors or product teams
+- Jargon or overly complex technical language
+- Weak phrases like "you can" or "there is/are/were" unless they add value
+
+ALWAYS:
+- Write like you speak using everyday words
+- Create a friendly, informal tone
+- Start statements with verbs when possible
+
+## Structure and Format Rules
+
+### Headings and Content
+- Use sentence case headings (capitalize only first word and proper nouns)
+- Never use gerunds in titles
+- Never place consecutive headings without content between them
+- Lead with the most important information first
+- Front-load keywords for scanning
+
+### Lists and Punctuation
+- **CRITICAL: Use Oxford comma in ALL lists (item1, item2, and item3) - NO EXCEPTIONS**
+- **MANDATORY: Number ordered lists using "1." for every item (NOT 1., 2., 3.) - ALWAYS USE "1."**
+- **REQUIRED: Use bullets for unordered lists - NEVER use numbers for unordered content**
+- **ESSENTIAL: Write complete sentences in lists with proper punctuation**
+- **MUST: End list items with periods if more than three words - THIS IS NON-NEGOTIABLE**
+- Skip end punctuation on titles, headings, and UI elements (3 words or fewer)
+
+### Spacing and Layout
+- Add blank lines around Markdown elements (but don't add extra if they exist)
+- Use only one space after periods, question marks, and colons
+- Use no spaces around dashes (word—word)
+- Break up long sentences for clarity
+
+### Prohibited Terms
+- Never write "etc." or "and so on" - provide complete lists or use "for example"
+- Use "for example" instead of "e.g."
+- Use "that is" instead of "i.e."
+
+## Formatting Conventions
+
+Apply these formatting rules:
+- **Bold text** for UI elements
+- `Code style` for file names, folders, custom types, and non-localizable text
+- Raw URLs in angle brackets
+- Relative links for files in this repository
+- Remove `https://learn.microsoft.com/en-us` from Microsoft Learn links
+
+## Word Choice Requirements
+
+### Verb Selection
+- Choose simple verbs without modifiers
+- Avoid weak verbs: "be," "have," "make," "do"
+- Use precise verbs (write "tell" NOT "inform")
+
+### Conciseness Rules
+- Use one word instead of multiple when possible (write "to" NOT "in order to")
+- Choose words with one clear meaning (write "because" NOT "since" for causation)
+- Omit unnecessary adverbs unless critical to meaning
+- Use one term consistently for each concept
+
+### Contraction Guidelines
+- Use common contractions: "it's," "you're," "that's," "don't"
+- Avoid ambiguous contractions: "there'd," "it'll," "they'd"
+- Never form contractions from noun + verb (avoid "Microsoft's developing")

.github/instructions/Snippets.Migrate.instructions.md

@@ -0,0 +1,142 @@
+---
+description: Migrate code from the old ~/samples/snippets/ location to the relative ./snippets location.
+---
+
+# Migrate code snippets
+
+**IMPORTANT**: Unless otherwise asked to, **only** edit the article file in context. At the end of your operations you may ask for permission to edit other articles referencing the same snippets.
+
+## Repository structure for code snippets
+
+**IMPORTANT**: This repository has TWO different locations for code snippets:
+
+### Old location (legacy - to be migrated FROM)
+- Path: `~/samples/snippets/`
+- Example: `~/samples/snippets/csharp/VS_Snippets_Winforms/System.Windows.Forms.Clipboard/CS/form1.cs`
+- Status: Legacy, should be migrated to new location
+
+### New location (current standard - migrate TO)
+- Path pattern: `./snippets/{doc-file}/[net-or-framework]/{code-language}/`
+- Example: `./snippets/how-to-add-data-to-the-clipboard/net/csharp/form1.cs`
+
+**Path components explained:**
+- `{doc-file}`: The markdown article filename WITHOUT the `.md` extension
+  - Example: For article `how-to-add-data-to-the-clipboard.md` → use `how-to-add-data-to-the-clipboard`
+- `[net-or-framework]`: Choose based on target framework:
+  - `net`: For .NET (.NET 6 and newer)
+  - `framework`: For .NET Framework (4.8 and older)
+  - **Rule**: Only include this subfolder when the article demonstrates BOTH .NET and .NET Framework approaches
+- `{code-language}`: 
+  - `csharp`: For C# code
+  - `vb`: For Visual Basic code
+
+## Legacy code characteristics (migrate FROM these)
+
+**Location**: `~/samples/snippets/` folder
+**Problems with legacy code:**
+- Written for .NET Framework (outdated)
+- Often incomplete or non-compilable
+- May lack project files
+- Uses outdated syntax and patterns
+
+**Legacy article references look like this:**
+```markdown
+[!code-{code-language}[description](~/samples/snippets/{path-to-file}#{snippet-identifier})]
+```
+
+## Current code requirements (migrate TO these)
+
+**Location**: `./snippets/{doc-file}/[framework]/{code-language}/`
+
+**Requirements for current code standards:**
+- ✅ MUST be complete and compilable
+- ✅ MUST include a project file
+- ✅ MUST target appropriate .NET version (see targeting rules below)
+- ✅ MUST provide BOTH C# and Visual Basic versions
+- ✅ MUST use appropriate syntax for the target framework
+- ✅ MUST use meaningful, descriptive snippet identifiers in CamelCase format
+  - **Examples** of good snippet identifiers: `BasicClipboardData`, `CustomDataFormat`, `ClipboardImageHandling`
+  - **Avoid** simplistic identifiers like `1`, `2`, `code1`, or `snippet1`
+
+**Current article references look like this:**
+```markdown
+:::code language="{code-language}" source="{file-path}" id="{snippet-identifier}":::
+```
+
+**Framework targeting rules:**
+- **Migration vs. Modernization**: 
+  - **Migration**: Move code to new location with minimal changes
+  - **Modernization**: Update code to use latest .NET features and best practices
+- **When to migrate only**: When article has `ms.service: dotnet-framework` frontmatter or is specifically about .NET Framework features
+- **When to modernize**: When article demonstrates both .NET and .NET Framework, or when specifically requested
+- **Default targeting**: 
+  - For .NET Framework-specific articles: Keep targeting .NET Framework
+  - For general articles: Target latest .NET version (e.g., .NET 10)
+  - For mixed articles: Create separate snippets in `net/` and `framework/` subfolders
+
+## Migration steps (follow in order)
+
+**WHEN TO MIGRATE**: Migrate code when you encounter articles with references to `~/samples/snippets/` paths.
+
+**STEP-BY-STEP PROCESS:**
+
+### 1. Analyze existing code and article context
+- **Find**: Locate the legacy snippet file in `~/samples/snippets/`
+- **Check frontmatter**: Look for `ms.service: dotnet-framework` in the article's frontmatter
+- **Determine scope**: 
+  - If frontmatter has `ms.service: dotnet-framework` → this is likely a .NET Framework-specific article
+  - if frontmatter has `ms.service: dotnet-desktop` or similar → this is likely a dual-framework or general article
+  - If article demonstrates both .NET and .NET Framework → prepare for dual targeting
+  - If article is general purpose → consider targeting current .NET
+- **Identify**: Determine the programming language (C# or Visual Basic)
+- **Extract**: Note the snippet identifier used in the article reference
+
+### 2. Create new folder structure
+- **Pattern**: `./snippets/{doc-file}/[net-or-framework]/{code-language}/`
+- **Example**: For article `clipboard-operations.md` → create `./snippets/clipboard-operations/net/csharp/`
+- **Decision tree for framework folder**:
+  - Article has `ms.service: dotnet-framework` frontmatter → use `./snippets/{doc-file}/framework/{code-language}/`
+  - Article shows ONLY current .NET examples → use `./snippets/{doc-file}/{code-language}/` (omit framework folder)
+  - Article shows BOTH .NET and .NET Framework → create both `./snippets/{doc-file}/net/{code-language}/` and `./snippets/{doc-file}/framework/{code-language}/`
+
+### 3. Migrate and update code
+- **Copy**: Copy only the snippet code (and any supporting code to compile the snippet) to the new location
+- **Update approach**:
+  - **For .NET Framework articles**: Migrate with minimal changes, keep .NET Framework targeting
+  - **For dual-framework articles**: Create both versions with appropriate targeting and update frontmatter to `ms.service: dotnet-desktop`
+  - **For general articles**: Update to target current .NET only if specifically requested or if article demonstrates modernization
+- **Complete**: Ensure code is fully functional and compilable
+- **Project file**: Create or update project file with appropriate target framework
+
+### 4. Create both language versions
+- **Requirement**: MUST provide both C# and Visual Basic versions
+- **C# path**: `./snippets/{doc-file}/[framework]/csharp/`
+- **VB path**: `./snippets/{doc-file}/[framework]/vb/`
+
+### 5. Update article references
+- **Replace**: Change from legacy `[!code-...]` format to modern `:::code...:::` format
+- **Before**: `[!code-csharp[description](~/samples/snippets/path/file.cs#snippet1)]`
+- **After**: `:::code language="csharp" source="./snippets/doc-name/net/csharp/file.cs" id="BasicClipboardData":::`
+- **Note**: Use meaningful CamelCase identifiers instead of simple numbers
+
+### 6. Validate
+- **Build**: Ensure all code compiles successfully
+- **Test**: Verify snippet references work in the article
+- **Clean**: Remove unused legacy files (if no other articles reference them)
+
+### 7. Delete
+- **Identify**:
+  - Check if the old snippet file is used by any other articles
+  - Some articles may use a relative path to the `samples` folder, so simply search for links to `samples/snippets/...`
+  - Be confident that all legacy snippets use a `samples/snippets` folder structure
+- **Delete**: If old snippet is no longer used by any article, delete it.
+
+## Common mistakes to avoid
+
+- ❌ **Don't** assume all code needs to be modernized - check article context first
+- ❌ **Don't** modernize .NET Framework-specific articles unless specifically requested
+- ❌ **Don't** ignore the `ms.service: dotnet-framework` frontmatter indicator
+- ❌ **Don't** forget to create both C# and VB versions
+- ❌ **Don't** mix up the framework targeting (net vs framework)
+- ❌ **Don't** forget to update ALL article references to the migrated code
+- ❌ **Don't** leave incomplete or non-compilable code