.NET Security

Use .NET Setup Packages for package selection, then apply these controls before enabling remote tools.

Package Gating

Keep all-in-one packages and concrete tool packages scoped to local development builds where possible.

<ItemGroup Condition="'$(Configuration)' == 'Debug'">
  <PackageReference Include="Ansight.Maui" Version="0.1.0-pre9" />
</ItemGroup>

Use Ansight.Core for telemetry-only release-like builds. Do not reference Ansight, Ansight.Maui, or Ansight.Tools.* in public release builds unless the build is explicitly internal and guarded.

Remote Tool Build Policy

Use the SDK build policy to make remote tool inclusion intentional.

<PropertyGroup Condition="'$(Configuration)' == 'Debug'">
  <AnsightRemoteToolsPolicy>AllowedWithWarnings</AnsightRemoteToolsPolicy>
</PropertyGroup>

<PropertyGroup Condition="'$(Configuration)' != 'Debug'">
  <AnsightRemoteToolsPolicy>Disallowed</AnsightRemoteToolsPolicy>
</PropertyGroup>

AllowedWithWarnings lets local development builds continue while surfacing remote-tool warnings. Disallowed should be used for protected Release, CI, TestFlight, App Store, Play Store, or other distributable builds that must not contain concrete tool implementations.

Do not manually add ANSIGHT_REMOTE_TOOLS to DefineConstants. The SDK defines it when AnsightRemoteToolsPolicy resolves to Allowed or AllowedWithWarnings.

Runtime Guard

All-in-one setup enables full tool access before your callback runs. Put the release deny-all guard inside the callback.

using Ansight;

var options = Options.CreateBuilder()
    .WithAnsightSdk(ansight =>
    {
        ansight.WithBundledHostConnection(typeof(AppBootstrap).Assembly);

#if DEBUG && ANSIGHT_REMOTE_TOOLS
        ansight.WithReadOnlyToolAccess();
#else
        ansight.WithToolsDisabled();
#endif
    })
    .Build();

For MAUI:

using Ansight.Maui;

builder.UseAnsight<App>(ansight =>
{
#if DEBUG && ANSIGHT_REMOTE_TOOLS
    ansight.WithReadOnlyToolAccess();
#else
    ansight.WithToolsDisabled();
#endif
});

Use WithReadWriteToolAccess() or WithAllToolAccess() only for workflows that need mutation or delete-scoped tools.

Pairing Files

Keep local pairing material out of source control:

ansight.json
*.ans.json
ansight.developer-pairing.json

When using the default ansight.json path beside the app project file, do not add AnsightDeveloperPairingSourceFile or AnsightDeveloperPairingOutputFile; the SDK defaults those paths. Embed the local config conditionally and point bundled host connection discovery at the assembly that contains it.

<ItemGroup>
  <EmbeddedResource Include="ansight.json" LogicalName="ansight.json" Condition="Exists('$(MSBuildProjectDirectory)/ansight.json')" />
</ItemGroup>

If a developer must reuse a pairing config on-device, prefer syncing or importing the signed config at runtime into the app’s platform secure storage, then loading it from there. Use embedded developer pairing only for local Debug builds, and keep it out of protected Release, CI, TestFlight, App Store, Play Store, and other distributable builds.

Platform Permissions

Android developer builds need local network access:

<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />

iOS and Mac Catalyst builds that use local network pairing or discovery need:

<key>NSLocalNetworkUsageDescription</key>
<string>Ansight client needs local network access to discover and connect to the host test harness.</string>

Only add camera permission strings when QR pairing is actually wired.

Checklist

• Scope all-in-one or tool packages to local development builds.
• Set AnsightRemoteToolsPolicy=AllowedWithWarnings only where remote tools are intentional.
• Use Disallowed for protected builds.
• Use WithToolsDisabled() outside developer conditions.
• Keep pairing configs ignored and short-lived.
• Prefer runtime sync/import into platform secure storage over bundled pairing payloads when on-device reuse is required.
• Enable write/delete scopes only for explicit workflows.