@softlion ## Issue Analysis

You've identified a valid C# namespace design issue for the planned maui-iap library. The problem is that having both:

A namespace OpenIap.Maui.Iap (likely for organizing types and utilities)
A class OpenIap.Maui.Iap (the main API class)

...creates a naming conflict where the namespace shadows the class, forcing users to use the workaround using IapApi = OpenIap.Maui.Iap;.

Recommended Solution

Rename the main API class to avoid the conflict. Common C# patterns:

Option 1: Use a non-conflicting class name

// Instead of: public class Iap { }
// Use: public class IapApi { }

namespace OpenIap.Maui.Iap
{
    public class IapApi
    {
        public async Task<PurchaseResult> PurchaseAsync(string productId) { }
    }
}

// Users can now use it naturally:
using OpenIap.Maui.Iap;
var iap = new IapApi();

Option 2: Use a service suffix

namespace OpenIap.Maui.Iap
{
    public class IapService
    {
        public async Task<PurchaseResult> PurchaseAsync(string productId) { }
    }
}

// Usage:
using OpenIap.Maui.Iap;
var service = new IapService();

Option 3: Move the class to a parent namespace

namespace OpenIap.Maui
{
    public class Iap
    {
        public async Task<PurchaseResult> PurchaseAsync(string productId) { }
    }
}

namespace OpenIap.Maui.Iap
{
    // Utilities, models, interfaces here
}

// Usage:
using OpenIap.Maui;
var iap = new Iap();

Recommendation

Option 1 (IapApi) is the best choice because:

✅ Keeps the logical namespace organization (OpenIap.Maui.Iap)
✅ Class name clearly indicates it's the API entry point
✅ No workarounds needed for users
✅ Follows common library patterns (e.g., HttpClient, SqlConnection)

This eliminates the namespace/class name collision while maintaining clean, intuitive code organization.

🤖 Generated by gitdog.dev · Have more questions? Tag @gitdog and let me know!

Uh oh!