.NET: Add ITextSearch<TRecord> with LINQ filtering and deprecate legacy ITextSearch (#10456)

[alzarei]

.NET: Add LINQ-based ITextSearch interface and deprecate legacy ITextSearch (#10456)

Summary

This PR implements Option 3 from the architectural decision process for Issue #10456: introduces a new generic ITextSearch<TRecord> interface with type-safe LINQ filtering while maintaining the legacy ITextSearch interface marked as [Obsolete] for backward compatibility.

Zero breaking changes - existing code continues working unchanged.

What Changed

New Generic Interface (Recommended Path)

public interface ITextSearch<TRecord>
{
    Task<KernelSearchResults<string>> SearchAsync(
        string query, 
        TextSearchOptions<TRecord>? searchOptions = null, 
        CancellationToken cancellationToken = default);
    
    // + GetTextSearchResults and GetSearchResults methods
}

// Type-safe LINQ filtering with IntelliSense
var options = new TextSearchOptions<CorporateDocument>
{
    Filter = doc => doc.Department == "HR" && 
                   doc.IsActive && 
                   doc.CreatedDate > DateTime.Now.AddYears(-2)
};

Benefits:

• ✅ Compile-time type safety
• ✅ IntelliSense support for property names
• ✅ Full LINQ expression support
• ✅ No RequiresDynamicCode attributes
• ✅ AOT-compatible (simple equality/comparison patterns)

Legacy Interface (Deprecated)

[Obsolete("Use ITextSearch<TRecord> with LINQ-based filtering instead. This interface will be removed in a future version.")]
public interface ITextSearch
{
    Task<KernelSearchResults<string>> SearchAsync(
        string query, 
        TextSearchOptions? searchOptions = null, 
        CancellationToken cancellationToken = default);
}

// Legacy clause-based filtering (still works)
var options = new TextSearchOptions 
{ 
    Filter = new TextSearchFilter().Equality("Department", "HR") 
};

Migration Message: Users see deprecation warning directing them to modern ITextSearch<TRecord> with LINQ filtering.

Implementation Details

Dual-Path Architecture

VectorStoreTextSearch<TRecord> implements both interfaces with independent code paths:

Legacy Path (Non-Generic):

async IAsyncEnumerable<VectorSearchResult<TRecord>> ExecuteVectorSearchAsync(
    string query, TextSearchOptions options)
{
    var vectorOptions = new VectorSearchOptions<TRecord>
    {
        #pragma warning disable CS0618 // VectorSearchFilter is obsolete
        OldFilter = options.Filter?.FilterClauses != null 
            ? new VectorSearchFilter(options.Filter.FilterClauses) 
            : null
        #pragma warning restore CS0618
    };
    // ... execute search
}

Modern Path (Generic):

async IAsyncEnumerable<VectorSearchResult<TRecord>> ExecuteVectorSearchAsync(
    string query, TextSearchOptions<TRecord> options)
{
    var vectorOptions = new VectorSearchOptions<TRecord>
    {
        Filter = options.Filter  // Direct LINQ passthrough
    };
    // ... execute search
}

Key Characteristics:

• Two independent methods (no translation layer, no conversion overhead)
• Legacy path uses obsolete VectorSearchFilter with pragma suppressions (temporary during transition)
• Modern path uses LINQ expressions directly (no obsolete APIs)
• Both paths are AOT-compatible (no dynamic code generation)

Files Changed

Interfaces & Options

• ITextSearch.cs: Added ITextSearch<TRecord> interface, marked legacy ITextSearch as [Obsolete]
• TextSearchOptions.cs: Added generic TextSearchOptions<TRecord> class

Implementation

• VectorStoreTextSearch.cs: Implemented dual interface pattern (~30 lines for both paths)

Backward Compatibility (Pragma Suppressions)

Added #pragma warning disable CS0618 to 27 files that use the obsolete interface:

Production (11 files):

• Web search connectors (Bing, Google, Brave, Tavily)
• Extension methods (WebServiceCollectionExtensions, TextSearchExtensions)
• Core implementations (TextSearchProvider, TextSearchStore, VectorStoreTextSearch)

Tests/Samples (16 files):

• Integration tests (Agents, AzureAISearch, InMemory, Qdrant, Web plugins)
• Unit tests (Bing, Brave, Google, Tavily)
• Sample tutorials (Step1_Web_Search, Step2_Search_For_RAG)
• Mock implementations

Tests

• Added 7 new tests for LINQ filtering scenarios
• Maintained 10 existing legacy tests (unchanged)
• Added DataModelWithTags to test base for collection filtering

Validation Results

• ✅ Build: 0 errors, 0 warnings with --warnaserror
• ✅ Tests: 1,581/1,581 passed (100%)
• ✅ Format: Clean
• ✅ AOT Compatibility: All checks passed
• ✅ CI/CD: Run #29857 succeeded

Breaking Changes

None. This is a non-breaking addition:

• Legacy ITextSearch interface continues working (marked [Obsolete])
• Existing implementations (Bing, Google, Azure AI Search) unchanged
• Migration to ITextSearch<TRecord> is opt-in via deprecation warning

Multi-PR Context

This is PR 2 of 6 in the structured implementation for Issue #10456:

• PR1 ✅: Generic interfaces foundation
• PR2 ← YOU ARE HERE: Dual interface pattern + deprecation
• PR3-PR6: Connector migrations (Bing, Google, Brave, Azure AI Search)

Architectural Decision

Option 3 Approved by Mark Wallace and Westey-m:

"We typically follow the pattern of obsoleting the old API when we introduce the new pattern. This avoids breaking changes which are very disruptive for projects that have a transient dependency." - Mark Wallace

"I prefer a clean separation between the old and new abstractions. Being able to obsolete the old ones and point users at the new ones is definitely valuable." - Westey-m

Options Considered:

1. Native LINQ Only: Replace TextSearchFilter entirely (breaking change)
2. Translation Layer: Convert TextSearchFilter to LINQ internally (RequiresDynamicCode cascade, AOT issues)
3. Dual Interface ✅: Add ITextSearch<TRecord> + deprecate legacy (no breaking changes, clean separation)

See ADR comments in conversation for detailed architectural analysis.

Migration Guide

Before (Legacy - Now Obsolete):

ITextSearch search = ...;
var options = new TextSearchOptions 
{ 
    Filter = new TextSearchFilter()
        .Equality("Department", "HR")
        .Equality("IsActive", "true")
};
var results = await search.SearchAsync("query", options);

After (Modern - Recommended):

ITextSearch<CorporateDocument> search = ...;
var options = new TextSearchOptions<CorporateDocument> 
{ 
    Filter = doc => doc.Department == "HR" && doc.IsActive
};
var results = await search.SearchAsync("query", options);

Next Steps

PR3-PR6 will migrate connector implementations (Bing, Google, Brave, Azure AI Search) to use ITextSearch<TRecord> with LINQ filtering, demonstrating the modern pattern while maintaining backward compatibility.

[alzarei]

ADR1 (PR2)

status: superseded-by-option-3 (ADR2)
contact: @alzarei
date: 2025-10-17
deciders: architecture-team
consulted: @westey-m, @roji
informed: @markwallace-microsoft

RequiresDynamicCode on ITextSearch Interface

Context and Problem Statement

VectorStoreTextSearch implementation of ITextSearch<TRecord> processes LINQ expressions directly, requiring RequiresDynamicCode attributes on its methods. However, the interface definition lacks these attributes, causing 31 IL3051 compilation errors:

IL3051: Member 'VectorStoreTextSearch.SearchAsync(...)' with 'RequiresDynamicCodeAttribute' 
implements interface member 'ITextSearch<TRecord>.SearchAsync(...)' without 'RequiresDynamicCodeAttribute'. 
Annotations must match across all interface implementations or overrides.

Issue #10456 aims to eliminate technical debt by modernizing from legacy TextSearchFilter to direct LINQ processing, but this creates an architectural mismatch between interface contracts and implementation requirements.

Decision Drivers

• IL3051 Compliance: Resolve compilation errors preventing Issue .Net MEVD: Modify ITextSearch to react to the new LINQ-based vector search filtering #10456 completion
• Interface Contract Accuracy: TextSearchOptions<TRecord>.Filter accepts Expression<Func<TRecord, bool>>
• Performance: Direct LINQ processing eliminates conversion overhead in VectorStoreTextSearch
• Architecture Consistency: Align with Microsoft.Extensions.VectorData patterns

Considered Options

Option A: Add RequiresDynamicCode to Interface (Recommended)

public interface ITextSearch<TRecord>
{
    [RequiresDynamicCode("LINQ filtering requires dynamic code generation for expression trees.")]
    Task<KernelSearchResults<string>> SearchAsync(string query, TextSearchOptions<TRecord>? searchOptions = null, CancellationToken cancellationToken = default);
    // ... other methods
}

Advantages:

• Resolves IL3051 compilation errors
• Interface contract matches implementation requirements
• Enables direct LINQ processing in VectorStoreTextSearch
• Documents AOT constraints accurately

Disadvantages:

• Interface metadata change (runtime behavior unchanged)
• Restricts AOT compilation scenarios

Option B: Convert VectorStoreTextSearch to Adapter Pattern

Force VectorStoreTextSearch to use LINQ → Legacy conversion like other implementations.

Advantages:

• No interface changes required
• Maintains AOT compatibility

Disadvantages:

• Contradicts Issue .Net MEVD: Modify ITextSearch to react to the new LINQ-based vector search filtering #10456 objective of eliminating technical debt
• Introduces unnecessary conversion overhead
• Creates architectural inconsistency with MEVD foundation

Decision

Option A: Add RequiresDynamicCode to ITextSearch interface methods

Rationale

1. Interface Contract: TextSearchOptions<TRecord>.Filter is Expression<Func<TRecord, bool>>? - dynamic code generation is inherent to the contract
2. Performance: VectorStoreTextSearch is the primary implementation and benefits from direct LINQ processing
3. Precedent: Entity Framework uses same pattern - RequiresDynamicCode on interfaces with LINQ contracts
4. Compatibility: Adapter implementations can continue existing patterns with minimal changes

---

Implementation Impact

Immediate:

• Resolves 31 IL3051 compilation errors
• Enables direct LINQ processing in VectorStoreTextSearch
• No runtime breaking changes for consumers

Implementation Requirements:

• Add RequiresDynamicCode attribute to interface methods
• Existing adapter implementations add attribute (reflects current behavior)
• Update XML documentation for AOT implications

References

• Issue #10456: Modify ITextSearch to use LINQ-based filtering
• PR #10273: Foundation LINQ filtering implementation
• .NET RequiresDynamicCodeAttribute

[alzarei]

ADR2 (PR2)

status: "accepted", decision makers: @markwallace-microsoft , @westey-m, date: 2025-10-23
contact: @alzarei
date: 2025-10-17
deciders: architecture-team
consulted: @westey-m @roji @markwallace-microsoft
informed:

Dual Interface Pattern for Text Search Filtering

Context and Problem Statement

Issue #10456 aims to modernize text search filtering by adding LINQ-based type safety. However, analysis revealed that forcing both generic and non-generic interfaces through LINQ conversion creates unnecessary technical debt and architectural violations.

Decision

Implement Dual Interface Pattern with Clear Separation:

Generic Interface: Modern LINQ Path

ITextSearch<TRecord> → TextSearchOptions<TRecord> → Expression<Func<TRecord, bool>> → Direct LINQ

• Uses RequiresDynamicCode (inherent to LINQ expressions)
• Provides compile-time type safety and IntelliSense
• Targets modern applications requiring type safety

Non-Generic Interface: Legacy Compatibility Path

ITextSearch → TextSearchOptions → TextSearchFilter → VectorSearchFilter → Legacy Processing

• No RequiresDynamicCode needed (no LINQ conversion)
• Maintains backward compatibility for existing applications
• Direct path to obsolete API for compatibility

Rationale

1. Technical Debt Clarity: We preserve legacy path for compatibility while providing modern alternative
2. Performance: Each interface uses its optimal processing path without conversion overhead
3. Architecture Separation: Clear distinction between legacy and modern approaches
4. IL3051 Resolution: Non-generic interface doesn't need LINQ, eliminating warnings
5. Developer Choice: Teams can migrate to generic interface when ready

Implementation Impact

• Non-generic methods: Revert to direct VectorSearchFilter usage (original baseline approach)
• Generic methods: Continue using direct LINQ expressions
• No breaking changes: Existing code continues working unchanged
• Clear migration path: Developers can upgrade interface when adopting type safety

This approach eliminates IL3051 warnings correctly while maintaining the intended architectural benefits of Issue #10456.

[alzarei]

See some comments below, but I think there's a more fundamental design decision to be made here...

The approach in this PR reimplements the existing ITextSearch API (TextSearchOptions.Filter, which relies on TextSearchFilter for expressing filters, via LINQ. The other possibility (which I originally had in mind) is to do the same as we did in Microsoft.Extensions.VectorData (MEVD) itself, i.e. obsolete the current filtering mechanism and introduce a new, LINQ-based one.

Exposing LINQ to the user via ITextSearch would allow them to express any filter, rather than the current highly-restricted mechanism based on FilterClause (this is the original reason we switched to LINQ in MEVD). If we go this way, then for VectorStoreTextSearch we'd simply flow the LINQ expression tree from the ITextSearch implementation to MEVD - no translation/work necessary. For other ITextSearch implementations, we'd need to implement very basic LINQ providers which translate the LINQ expression tree (just like we did in MEVD). This may represent a bit more work, but seems like the right way forward, assuming we want ITextSearch to have a robust filtering story.

(incidentally, this approach would also avoid any NativeAOT/trimming issues, as we wouldn't need to generate any LINQ expression nodes).

@markwallace-microsoft @westey-m what do you think?

@roji @westey-m @markwallace-microsoft

@roji, Thank you for raising this architectural question and adding details to the original Issue #10456 vision to help determine a strategic decision.

Context: Option 3 Implementation While Awaiting Decision

While awaiting guidance on the architectural direction, I implemented Option 3 to demonstrate how the dual interface approach works end-to-end. The current state of this PR (commit d1f2733) shows a complete working implementation that avoids breaking changes while the team decides on the long-term path.

The Breaking Change Dilemma

// The obsolete class at the center of this:
[Obsolete("Use VectorSearchOptions.Filter instead of VectorSearchOptions.OldFilter")]  
public sealed class VectorSearchFilter

// Our choices:
// 1. Native LINQ: Replace TextSearchFilter entirely → BREAKING CHANGE (API change)
// 2. Dual Pattern + Avoid Obsolete: Keep TextSearchFilter but convert → BREAKING CHANGE (RequiresDynamicCode)  
// 3. Dual Pattern + Use Obsolete: Keep TextSearchFilter, use obsolete API → NO BREAKING CHANGE

The Three Options with Tradeoffs

Option 1: Native LINQ Only:

• Replace TextSearchFilter entirely with Expression<Func<T, bool>>
• Remove non-generic ITextSearch interface
• BREAKING CHANGE: Requires user migration
• Benefits: Best long-term architecture, unlimited expressiveness, type safety, eliminates obsolete API

Option 2: Dual Interface + Translation Layer (This PR minus the last commit (commit d1f2733)):

• Keep both ITextSearch and ITextSearch
• Convert TextSearchFilter to LINQ internally (approximately 150 lines)
• BREAKING CHANGE: RequiresDynamicCode cascades to all TextSearch APIs, extension methods, plugins
• Benefits: Avoids obsolete API usage

Option 3: Dual Interface + Use Obsolete (This PR):

• Keep both ITextSearch and ITextSearch
• Use obsolete VectorSearchFilter directly with pragma warnings
• NO BREAKING CHANGE: Existing code unaffected
• Trade-off: Maintains obsolete API dependency

AOT Connection & Ecosystem Impact

The RequiresDynamicCode issue adds tradeoff dimensions to the full scope of the architectural decision. Option 2's translation layer forces dynamic code generation for ALL filtering operations AND propagates through the entire API surface:

// The cascading effect:
ITextSearch.SearchAsync()                    // [RequiresDynamicCode] 
→ textSearch.CreateSearch()                  // Must add [RequiresDynamicCode]
→ textSearch.CreatePlugin()                  // Must add [RequiresDynamicCode] 
→ kernel.Plugins.AddFromTextSearch()         // Must add [RequiresDynamicCode]
→ ANY consumer code using TextSearch plugins // Gets AOT warnings

This makes the entire TextSearch plugin ecosystem AOT-incompatible, while Option 1 (native LINQ) would keep simple operations AOT-compatible.

Option 3 Implementation Details (This PR)

To demonstrate how Option 3 works end-to-end, this PR implements:

// Legacy interface (unchanged - backward compatible)
public interface ITextSearch
{
    Task<KernelSearchResults<string>> SearchAsync(string query, TextSearchOptions? options = null);
    // Uses TextSearchFilter (clause-based) → VectorSearchOptions.OldFilter (obsolete)
}

// New generic interface (modern LINQ filtering)
public interface ITextSearch<TRecord>
{
    Task<KernelSearchResults<string>> SearchAsync(string query, TextSearchOptions<TRecord>? options = null);
    // Uses Expression<Func<TRecord, bool>> → VectorSearchOptions.Filter (not obsolete)
}

// Both implemented by VectorStoreTextSearch<TRecord> with separate code paths
public class VectorStoreTextSearch<TRecord> : ITextSearch, ITextSearch<TRecord>
{
    // Legacy path: Direct use of obsolete API with pragma suppression
    async IAsyncEnumerable<VectorSearchResult<TRecord>> ExecuteVectorSearchAsync(
        string query, TextSearchOptions options)
    {
        var vectorOptions = new VectorSearchOptions
        {
            #pragma warning disable CS0618
            OldFilter = options.Filter?.FilterClauses != null 
                ? new VectorSearchFilter(options.Filter.FilterClauses) 
                : null
            #pragma warning restore CS0618
        };
    }

    // Modern path: Direct passthrough of LINQ expression
    async IAsyncEnumerable<VectorSearchResult<TRecord>> ExecuteVectorSearchAsync(
        string query, TextSearchOptions<TRecord> options)
    {
        var vectorOptions = new VectorSearchOptions
        {
            Filter = options.Filter  // No conversion, no RequiresDynamicCode
        };
    }
}

Key aspects:

• Two independent code paths - no translation layer, no conversion overhead
• Both paths are AOT-compatible - no RequiresDynamicCode anywhere
• Existing code continues working unchanged

Analysis

All paths except Option 3 involve breaking changes - the question is which provides the most value:

Option 1 advantages:

• Better AOT story (simple operations remain AOT-compatible)
• Aligns with Microsoft.Extensions.VectorData patterns
• Eliminates technical debt permanently

Option 3 advantages:

• Unblocks PR3-PR6 (Bing, Google, Azure AI Search connectors)
• Enables gradual LINQ adoption without forced migration
• Can migrate to Option 1 later with proper planning

Decision Needed

Which approach should we take:

1. Native LINQ only (remove legacy interface)
2. Native LINQ + Translation Layer (avoid obsolete API)
3. Native LINQ + Legacy (use obsolete API) - This PR

Questions:

• @roji - Should we pursue the native LINQ approach from Issue .Net MEVD: Modify ITextSearch to react to the new LINQ-based vector search filtering #10456?
• @westey-m @markwallace-microsoft - What is your view on timing and migration strategy?
• Team - If we accept Option 3, should we add [Obsolete] to ITextSearch (non-generic) immediately or in next release?

[alzarei]

@roji @markwallace-microsoft @westey-m while waiting for the architecture decision input from you, I am entertaining and validating option 3.

[markwallace-microsoft]

@roji @markwallace-microsoft @westey-m while waiting for the architecture decision input from you, I am entertaining and validating option 3.

We typically follow the pattern of obsoleting the old API when we introduce the new pattern. This avoids breaking changes which are very disruptive for projects that have a transient dependency.

[westey-m]

@alzarei, I prefer a clean separation between the old and new abstractions. Being able to obsolete the old ones and point users at the new ones is definitely valuable. Then we can remove the obsoleted code after a period of time.

[alzarei]

@roji @westey-m @markwallace-microsoft

Thank you all for the excellent feedback! After your review and architectural guidance, we pivoted from Option 2 (translation layer, commits c2c783b - a802eaa) to Option 3 (dual interface pattern) in commit d1f2733.

This removed the ~150 lines of translation layer code that had the issues you identified. Current implementation:

Legacy path: Direct OldFilter usage with pragma (lines 284-289)
Modern path: Direct LINQ passthrough (line 305)
No dynamic code generation, no exception handling, no RequiresDynamicCode
The architectural discussion led to the current solution - Option 3 with [Obsolete] marking (commit e333850). Thank you for the input and guidance!

[roji]

@alzarei can you please push your changes into a single PR? I'm getting a bit confused as to which branch corresponds to which PRs (there are quite a few), and this PR represents incremental work on top of something else. This is all making reviewing quite complex.

Just to raise the obvious: this PR adds the new LINQ-based filter support to VectorStoreTextSearch, but all the other implementations are left implementing the now-obsolete non-generic ITextSearch; it's problematic for these implementations to not have a non-obsolete way of being used. I can see that ultimately a feature-text-search-linq is being targeted - it's indeed a good idea to do this work in a feature branch so that everything can be done across all providers and samples before releasing anything.

[alzarei]

@roji @westey-m @markwallace-microsoft

All review feedback has been addressed. PR is ready for final review.

Validation Results

All validation steps completed successfully:

Format Check - PASSED

dotnet format SK-dotnet.slnx --verify-no-changes

• Status: PASSED (no formatting changes needed)

Build with Warnings as Errors - PASSED

dotnet build SK-dotnet.slnx --configuration Release --warnaserror

• Errors: 0
• Warnings: 0
• Matches GitHub Actions CI/CD requirements

Core Unit Tests - PASSED

dotnet test SemanticKernel.UnitTests.csproj --configuration Release --no-build

• Failed: 0
• Passed: 1,581
• Skipped: 0
• Total: 1,581
• Duration: 2 seconds

AOT Compatibility - PASSED

dotnet publish --configuration Release (SemanticKernel.AotTests)

• Errors: 0
• Warnings: 0
• Successfully published to win-x64

[alzarei]

@alzarei can you please push your changes into a single PR? ...

@roji Thanks for the feedback! Let me clarify the multi-PR strategy:

This is Part 2 of 6 in Issue #10456

PR Chain (all target feature-text-search-linq):

PR	Status	Scope
PR #13175	Merged (Oct 7)	Add ITextSearch<TRecord> interface
PR #13179	This PR	VectorStoreTextSearch
PR #13188	Addressing feedback	Migrate BingTextSearch
PR #13190	Validating chagnes	Migrate GoogleTextSearch
PR #13191	Validating changes	Migrate Tavily & Brave
PR #13194	validating changes	Update samples & docs

Your Concern About Obsolete Implementations

"all the other implementations are left implementing the now-obsolete non-generic ITextSearch"

You're absolutely right to raise this! PR3-PR6 address exactly this issue.

After all 6 PRs merge, every implementation will have both interfaces:

• VectorStoreTextSearch: ITextSearch<TRecord> (modern) + ITextSearch (legacy)
• BingTextSearch: ITextSearch<BingWebPage> (modern) + ITextSearch (legacy)
• GoogleTextSearch: ITextSearch<GoogleWebPage> (modern) + ITextSearch (legacy)
• TavilyTextSearch: ITextSearch<TavilyWebPage> (modern) + ITextSearch (legacy)
• BraveTextSearch: ITextSearch<BraveWebPage> (modern) + ITextSearch (legacy)

Pattern (Option 3 - applied consistently in all PRs):

#pragma warning disable CS0618 // ITextSearch is obsolete - backward compatibility
public sealed class BingTextSearch : ITextSearch, ITextSearch<BingWebPage>
#pragma warning restore CS0618
{
    // Modern LINQ path
    Task<KernelSearchResults<string>> ITextSearch<BingWebPage>.SearchAsync(...) { }
    
    // Legacy path (backward compatible)
    Task<KernelSearchResults<string>> ITextSearch.SearchAsync(...) { }
}

Why Separate PRs?

1. Each connector has unique patterns: Bing REST URLs, Google JSON API, Tavily/Brave web search - distinct conversion logic
2. Easier review: 5 focused PRs (~15-30 files) vs 1 massive PR (~93 files)
3. Parallel development: Independent CI/CD validation per connector
4. Clear separation: Architecture (PR2) vs implementations (PR3-6)

Review Approach

Suggested: Review PR2 for the deprecation pattern architecture, then PR3-6 will apply it consistently across connectors.

Alternative: I can consolidate if you prefer to see everything in one PR.

Does this clarify the strategy? Happy to adjust if you have an approach in mind that makes it easier to reviewe!

Thanks!

[alzarei]

@westey-m @roji @markwallace-microsoft

The integration deployment went through successfully 🎉 and all feedback has been addressed. Feel free to take a look, and if everything looks good, let's move forward. I'm wrapping up the next PRs in this batch to stay aligned with the ADRs we made here. Thank you!