Scan Details - Linux-first Docs for Azure

1072

Pages Scanned

48

Pages Flagged

1072

Changed Pages

4.5%

% Pages Flagged

Scan Information

Started At: 2025-09-05 00:00:35

Finished At: 2025-09-05 00:22:48

Status: completed

Target URL: https://github.com/MicrosoftDocs/azure-docs/tree/main/articles

Current Phase: discovery

Problematic Pages

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation provides both Azure CLI and Azure PowerShell instructions for verifying results, but does not offer explicit Linux/macOS shell examples or mention Bash or other Linux-native tools. The PowerShell section uses Windows-style variable assignment, and the prerequisites list Azure PowerShell requirements alongside Azure CLI, which may not be as relevant for Linux users. There are no explicit Linux-specific instructions or parity in tool recommendations.

Recommendations:

Add explicit Bash/Linux shell examples for variable assignment and command usage, especially in the verification steps.
Clarify that Azure CLI is cross-platform and can be used on Linux/macOS, and provide examples using Bash syntax.
Reorder or balance the presentation of Azure CLI and PowerShell, or add a Bash tab to ensure Linux users see their platform represented.
In the prerequisites, clarify that Azure PowerShell is optional and not required for Linux users if they use Azure CLI.
Where file creation or directory navigation is mentioned, provide both Windows (cmd/PowerShell) and Linux (Bash) command examples.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation page demonstrates a Windows bias by primarily referencing Azure PowerShell scripts and commands for migration and preview registration, without providing equivalent Azure CLI (cross-platform) or Bash examples. The only code snippets for registering/unregistering the preview use PowerShell cmdlets, and migration guidance references a PowerShell script in the PowerShell Gallery. There are no explicit Linux/Bash/CLI examples, and the documentation does not mention Linux tooling or workflows. Additionally, the 'Next steps' section lists a PowerShell-based tutorial before mentioning the Azure CLI, reinforcing a Windows-first approach.

Recommendations:

Provide Azure CLI and/or Bash examples alongside PowerShell for all command-line operations, including migration and preview registration/unregistration.
Reference cross-platform tools and workflows (e.g., Azure CLI, Bash scripts) equally or before Windows-specific tools.
Include links to tutorials and modules that use Azure CLI or Bash, not just PowerShell.
Explicitly state that all features and scripts are available and supported on Linux/macOS as well as Windows, where applicable.
Where PowerShell scripts are referenced (such as for migration), provide or link to equivalent Azure CLI or Bash scripts, or clarify if none exist.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a bias toward Windows environments by providing only PowerShell commands for resource cleanup and focusing on IIS (a Windows web server) for validation. There are no Linux/Unix shell (Bash) examples for resource management, nor is there mention of Linux-based web servers (such as Apache or Nginx) for backend validation. The use of IIS and PowerShell without Linux alternatives may hinder parity for users on Linux or macOS.

Recommendations:

Provide equivalent Azure CLI (Bash) commands for resource group deletion, such as 'az group delete --name <your resource group name>'.
Include instructions or notes for validating the deployment using a Linux-based web server (e.g., Apache or Nginx) as an alternative to IIS.
When referencing tools or commands, present both Windows (PowerShell) and Linux (CLI/Bash) options, or link to sections that cover both.
Clarify that the template can be used with both Windows and Linux VMs, and provide guidance for customizing the template for Linux scenarios.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation page demonstrates a strong Windows bias: all migration tools and examples focus exclusively on migrating from Windows environments (specifically IIS servers), with no mention of Linux-based hosting or migration scenarios. All downloadable tools are Windows executables or PowerShell scripts, and there are no Linux command-line or tool equivalents provided. The documentation repeatedly references PowerShell and Windows-specific technologies, with no guidance for users running .NET apps on Linux or using Bash/CLI tools.

Recommendations:

Include guidance and examples for migrating .NET apps hosted on Linux servers (e.g., Apache, Nginx, Kestrel) to Azure App Service.
Provide Linux-compatible migration tools or scripts, or document manual migration steps for Linux environments.
Add Bash or Azure CLI examples alongside PowerShell scripts for discovery and migration tasks.
Clearly indicate in tool descriptions whether Linux is supported, and provide alternative recommendations if not.
Highlight any Azure App Service migration features or best practices that are specific to Linux-based .NET deployments.

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation shows a moderate Windows bias, particularly in the 'Memory resources' and 'Node.js apps' sections. It references Windows-specific tools and patterns (such as web.config and iisnode) without providing equivalent Linux guidance or examples. While there is some mention of Linux (e.g., PM2 for Node.js), Windows-centric configuration is presented first and more thoroughly, and Linux alternatives are not always provided.

Recommendations:

For auto-healing and memory management, provide Linux-native configuration guidance (e.g., app settings, startup scripts, or Linux-specific diagnostic tools) alongside or before Windows/web.config instructions.
In the Node.js section, include Linux-specific configuration and troubleshooting advice, such as using PM2, systemd, or other process managers, and clarify when iisnode is relevant (Windows only).
Wherever Windows tools (like web.config or iisnode) are mentioned, explicitly state their platform scope and offer Linux equivalents or alternatives.
Ensure that all code/configuration examples are provided for both Windows and Linux environments, or clearly indicate when a feature is platform-specific.
Consider a more balanced structure, presenting Linux and Windows options in parallel or in a platform-neutral order.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a moderate Windows bias. Windows terminology and tools (such as PowerShell) are emphasized, and Windows-specific instructions or examples are often presented before Linux equivalents. While Azure CLI examples are provided (which are cross-platform), PowerShell is highlighted as a primary automation tool, and there are no Linux shell (bash) or scripting examples. The portal instructions and screenshots are Windows-centric, and Linux-specific guidance is minimal or absent.

Recommendations:

Provide bash shell scripting examples alongside PowerShell for automation, especially for Linux users.
When listing commands or instructions, alternate the order or present Linux and Windows options together, rather than always listing Windows first.
Include screenshots or instructions for Linux environments (for example, using Azure CLI in a Linux terminal, or referencing Linux-specific deployment patterns).
Clarify when instructions or features are Windows-only, and provide equivalent Linux guidance where possible.
Expand the 'Automate with scripts' section to include bash or shell script examples for Linux users.
Ensure that terminology and tool references are balanced between Windows and Linux (e.g., avoid assuming PowerShell is the default scripting environment).

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a moderate Windows bias. Windows instructions, tools, and troubleshooting steps are often presented first or exclusively, with more detail and screenshots for Windows GUI tools. PowerShell commands are used for connectivity tests, while equivalent Linux commands are not provided. The Windows GUI for Hybrid Connection Manager is featured, but Linux users are limited to CLI with less visual guidance. Some troubleshooting steps and examples are Windows-specific or lack Linux alternatives.

Recommendations:

Present Windows and Linux instructions/examples in parallel, not sequentially or with Windows first.
For every PowerShell command (e.g., Test-NetConnection), provide the Linux equivalent (e.g., nc, telnet, or curl).
Include Linux screenshots or terminal output where Windows GUIs are shown, to provide parity for Linux users.
Expand troubleshooting steps to include Linux-specific guidance and commands.
Clarify any differences in feature support or limitations between Windows and Linux up front.
Where GUI tools are only available on Windows, suggest alternative workflows or monitoring methods for Linux users.
Ensure all code snippets and configuration steps are available for both platforms.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation demonstrates a Windows bias by providing PowerShell scripts as the only automation example for identifying impacted Traffic Manager endpoints, without offering equivalent Bash, Azure CLI, or cross-platform alternatives. References to running scripts assume a Windows/PowerShell environment, and there is no mention of Linux or macOS-compatible instructions. This may hinder users on non-Windows platforms from following the guidance effectively.

Recommendations:

Provide Bash or Azure CLI script alternatives for all PowerShell examples, especially for resource discovery tasks.
Explicitly mention that PowerShell Core is cross-platform, or provide instructions for running scripts on Linux/macOS if PowerShell is required.
When referencing downloadable scripts, offer both PowerShell and Bash versions, or at least note how Linux/macOS users can adapt the scripts.
Ensure that all automation and scripting guidance is platform-neutral or includes both Windows and Linux/macOS instructions.
Instruct users on how to use Azure CLI for resource queries and management wherever possible, as it is cross-platform.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation focuses exclusively on discovering ASP.NET web apps hosted on IIS web servers within VMware environments, which are Windows-centric technologies. There is no mention of Linux-based hosting scenarios, such as .NET apps running on Kestrel, Apache, or Nginx, nor are there any Linux-specific discovery tools or examples provided.

Recommendations:

Include guidance for discovering .NET web apps hosted on Linux servers (e.g., Kestrel, Apache, Nginx).
Provide examples or references for Linux-based discovery workflows, including any supported tools or scripts.
Clarify whether Azure Migrate supports Linux-hosted .NET apps and, if so, document the process.
Mention Linux environments explicitly where applicable, or state current limitations if Linux is not supported.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation is heavily focused on Windows environments, specifically Azure App Service on Windows with iisnode. All configuration and troubleshooting examples reference Windows-specific tools, paths, and patterns (e.g., web.config, node.exe, named pipes, Win32 error codes, IIS, Kudu CMD/PowerShell). There are no Linux equivalents or cross-platform guidance, and Linux scenarios are not mentioned or supported in the examples.

Recommendations:

Add equivalent examples and troubleshooting steps for Node.js applications running on Azure App Service Linux, including configuration and diagnostic tools.
Mention Linux-specific process management (e.g., PM2, systemd) and logging paths, and provide guidance for common Linux deployment patterns.
Include references to Linux error codes and diagnostic commands (e.g., journalctl, tail, top) alongside Windows/PowerShell examples.
Clearly indicate which sections apply only to Windows and provide parity by linking or embedding Linux documentation where relevant.
Provide guidance for debugging and profiling Node.js apps on Linux, including use of tools like node-inspect, strace, or perf.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias primarily through the exclusive mention and prioritization of Windows tools (Azure Storage Explorer with Windows-specific tabs), lack of Linux-specific instructions or examples, and absence of cross-platform alternatives for key steps such as generating SAS tokens and uploading package files. All command-line examples use Azure CLI, which is cross-platform, but GUI instructions and references are Windows-centric.

Recommendations:

Provide explicit instructions and screenshots for using Azure Storage Explorer on Linux and macOS, or mention its cross-platform availability.
Include alternative methods for generating SAS tokens and uploading files using platform-agnostic tools (e.g., Azure CLI, azcopy) with examples for Linux/macOS.
Avoid referencing Windows-specific tabs or features without noting Linux/macOS equivalents.
Add a section or callouts for Linux users, highlighting any differences or additional steps required.
Ensure troubleshooting and FAQ sections address platform-specific issues for both Windows and Linux users.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a Windows bias by focusing on Windows-based deployment and configuration patterns for ASP.NET apps. Examples and instructions reference Windows tools (Visual Studio, Kudu CMD/PowerShell, Windows file paths), and there is a lack of equivalent Linux examples or guidance for ASP.NET apps running on Linux App Service. The documentation assumes a Windows environment for most configuration tasks and does not provide parity for Linux users.

Recommendations:

Add explicit instructions and examples for configuring ASP.NET apps on Linux App Service, including how to check .NET Framework versions and access environment variables.
Provide Linux shell (bash) equivalents for commands currently shown only in CMD/PowerShell.
Mention Linux-specific deployment tools and patterns, such as using VS Code, FTP/SFTP, or Linux-based build pipelines.
Clarify which steps are Windows-specific and offer alternative steps for Linux environments where applicable.
Include screenshots or navigation steps for Linux-based Kudu/SSH consoles if available.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation provides both Linux and Windows instructions for configuring data sources in Tomcat and JBoss on Azure App Service. However, the Windows section is notably more detailed, featuring extensive PowerShell scripting and Windows-specific file paths and tools. The Linux instructions are generally more concise and rely on shell scripting, but lack parity in depth and troubleshooting guidance compared to Windows. Windows tools (PowerShell, cmd) are emphasized, and Windows-specific patterns (copying Tomcat locally, using %LOCAL_EXPANDED%) are described in detail, while Linux equivalents are less elaborated. Some examples (such as advanced configuration and troubleshooting) are only present for Windows, and the Windows configuration steps are presented after Linux but with greater emphasis and length.

Recommendations:

Expand Linux instructions to match the detail and troubleshooting depth of Windows, including more comprehensive shell script examples and explanations.
Provide equivalent Linux automation scripts (e.g., Bash scripts for startup configuration) with step-by-step guidance similar to the PowerShell example.
Include Linux-specific troubleshooting tips and best practices for modifying Tomcat/JBoss configuration files.
Ensure that all advanced configuration scenarios covered for Windows (such as copying Tomcat, marker files, and XSL transforms) are also addressed for Linux, with appropriate tooling (e.g., using rsync/cp, marker files, etc.).
Balance the use of platform-specific tools by offering cross-platform alternatives (e.g., using Python or Java for XML transforms instead of PowerShell or shell-only solutions).
Review the order and emphasis of examples to ensure Linux instructions are not secondary to Windows, and that both platforms are treated with equal importance.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation generally provides parity between Windows and Linux, but there are several areas of Windows bias. Windows examples and tools (like Kudu, FTPS, and web.config) are mentioned explicitly and sometimes before Linux equivalents. Some instructions, especially around process management and diagnostics, are more detailed for Windows (e.g., using Kudu's Process Explorer), while Linux relies on SSH access. Windows-specific notes (such as web.config for Tomcat) are present, but Linux equivalents are not always discussed. There are also references to Windows-specific deployment conventions and tools, and some features (like Tomcat patch version pinning) are described as more configurable on Windows than Linux.

Recommendations:

Ensure that Linux examples are always presented alongside Windows examples, with equal detail and clarity.
Where Windows tools (such as Kudu, FTPS, web.config) are mentioned, provide Linux alternatives (e.g., SSH, SCP, Linux config files) and link to their documentation.
Avoid presenting Windows instructions or tools first unless there is a technical reason; alternate the order or present both together.
Expand Linux troubleshooting and diagnostics sections to match the detail given for Windows (e.g., process management, file access).
Clarify any feature parity gaps (such as patch version pinning for Tomcat) and provide workarounds or roadmap notes for Linux users.
Review all notes and tips for Windows-specific advice and add equivalent Linux guidance where possible.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation demonstrates a Windows-first bias, especially in deployment examples and troubleshooting. Web Deploy (a Windows-specific tool) is featured prominently, and the only explicit agent pool example for Web Deploy uses 'windows-latest'. There are no equivalent Linux-based deployment examples for Web Deploy, and troubleshooting assumes a Windows environment. While some YAML examples use 'ubuntu-latest', advanced deployment scenarios and error messages focus on Windows agents and tools. There is a lack of parity in Linux-specific guidance, especially for .NET and Web Deploy scenarios.

Recommendations:

Provide equivalent Linux-based deployment examples where possible, especially for .NET apps.
Clearly indicate when a feature or tool (such as Web Deploy) is Windows-only, and suggest Linux alternatives (e.g., ZIP deploy, FTP, or Azure CLI).
Add troubleshooting sections for Linux agents, including common issues and solutions.
Ensure that all code snippets and agent pool examples are balanced between 'windows-latest' and 'ubuntu-latest', or clarify OS requirements.
Where Windows tools or patterns are mentioned, provide Linux equivalents or note their absence.
Expand FAQs to address Linux agent scenarios and limitations.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation exhibits a Windows-first bias by referencing Windows directory paths (e.g., D:\home\site\wwwroot) before Linux equivalents, and describing deployment behaviors primarily in terms of Windows file systems. There are no explicit Linux or cross-platform command-line examples, and the documentation assumes familiarity with Windows-style paths and conventions. Linux-specific details are mentioned only parenthetically or not at all, and there are no Linux-specific troubleshooting or deployment instructions.

Recommendations:

Present both Windows and Linux directory paths together and with equal prominence (e.g., D:\home\site\wwwroot (Windows) and /home/site/wwwroot (Linux)).
Include Linux-specific examples and troubleshooting steps, especially where file paths, permissions, or behaviors differ.
Provide cross-platform command-line examples, or explicitly note when commands are OS-agnostic.
Avoid assuming Windows as the default environment; use neutral or dual-path notation throughout.
Add a section or callouts for Linux users, highlighting any differences or considerations unique to Linux App Service environments.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation exhibits a Windows-first bias, with examples and terminology that prioritize Windows scenarios and tools. Windows-specific SKUs, containers, and calculation examples are given, while Linux equivalents are not mentioned or are only referenced generically. Windows tools and patterns (e.g., Visual Studio remote debugging, Web Deploy) are listed without Linux alternatives, and there are no explicit Linux-focused examples or guidance.

Recommendations:

Provide parallel examples and calculations for Linux containers and App Service plans, not just Windows.
List Linux-compatible deployment and debugging tools (e.g., SSH, SFTP, VS Code Remote) alongside Windows tools like Visual Studio and Web Deploy.
Include Linux-specific notes where behaviors or requirements differ (e.g., IP address usage for Linux containers).
Ensure that all examples, tables, and recommendations mention both Windows and Linux scenarios where applicable.
Add explicit Linux command-line examples or references (e.g., using Azure CLI from Bash, Linux networking tools) where relevant.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias, especially in the .NET and Python sections. Windows-centric tools (Visual Studio, Azure PowerShell) are listed first or exclusively, with Linux alternatives appearing later or not at all. For Python, examples and quickstarts default to Windows tabs, and Linux instructions are not clearly highlighted. The 'Next step' call-to-action also prioritizes an ASP.NET (typically Windows-first) workflow. Other stacks (Java, Node.js, PHP) show better Linux parity, but overall, Windows tools and workflows are more prominent.

Recommendations:

Ensure Linux and cross-platform CLI examples are presented before or alongside Windows/PowerShell examples.
Add explicit Linux instructions and tabs for Python quickstarts, not just Windows.
Highlight VS Code and CLI workflows as primary options, with Visual Studio and PowerShell as alternatives.
Balance the order of tool presentation (e.g., list CLI and VS Code before Visual Studio/Azure PowerShell).
Include Linux-specific deployment and troubleshooting examples for all stacks.
Make the 'Next step' call-to-action more inclusive (e.g., offer choices for Linux/CLI and other stacks, not just ASP.NET).

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a Windows bias by primarily referencing Windows-centric development tools and workflows, such as Visual Studio and right-click context menu actions, without providing equivalent instructions for Linux environments. Package installation is described first via the Visual Studio NuGet package manager, with CLI instructions mentioned secondarily. There are no explicit Linux or cross-platform editor examples (e.g., VS Code, JetBrains Rider), nor are Linux-specific commands or patterns (such as file creation via terminal or use of Linux environment variables) provided. The instructions for managing secrets and environment variables focus on the Azure portal and do not mention alternatives like editing configuration files or using CLI tools in Linux shells. Overall, the page assumes a Windows development environment and omits guidance for Linux users.

Recommendations:

Provide explicit instructions for creating and editing files using cross-platform tools (e.g., VS Code, nano, vim) and terminal commands.
Include package installation examples using the dotnet CLI (e.g., 'dotnet add package Microsoft.SemanticKernel') before or alongside Visual Studio NuGet manager instructions.
Describe how to manage environment variables and secrets using CLI tools (e.g., Azure CLI, Bash) and configuration files, not just through the Azure portal UI.
Avoid referencing right-click context menu actions; instead, use instructions that work in any OS (e.g., 'create a new file named OpenAI.razor in the Pages folder').
Mention Linux and macOS as supported platforms for .NET and Azure App Service, and provide troubleshooting tips or links for those environments.
Ensure all code and deployment steps are cross-platform, and clarify any OS-specific requirements or differences.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ windows_first

Summary:

The documentation page demonstrates a Windows bias by exclusively providing PowerShell examples for per-app scaling, with no equivalent examples for Linux-native tools (such as Azure CLI or Bash). The use of PowerShell cmdlets and the absence of cross-platform command-line alternatives may disadvantage Linux or macOS users. Additionally, the documentation references Azure PowerShell before mentioning ARM templates, reinforcing a Windows-centric approach.

Recommendations:

Add equivalent Azure CLI (az) examples for all PowerShell commands, showing how to enable per-app scaling and configure number of workers using the CLI.
Include Bash script examples or generic REST API calls to demonstrate cross-platform approaches.
When presenting multiple tool options, list cross-platform tools (e.g., Azure CLI) before or alongside PowerShell to avoid a 'Windows-first' impression.
Explicitly state that the instructions are applicable to all platforms, and clarify any platform-specific requirements if present.
Consider adding a table or section comparing PowerShell, Azure CLI, and ARM template approaches for per-app scaling.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a Windows bias in several ways: PowerShell examples are provided alongside Azure CLI, but no Linux shell equivalents (e.g., Bash scripts or REST API calls) are shown for tasks like retrieving outbound IP addresses. The outbound IPv6 support section explicitly states that outbound IPv6 is only available for Windows apps, with Linux apps limited to IPv4. Windows-oriented tools (PowerShell) are featured, and Windows-specific features are mentioned before Linux equivalents or limitations.

Recommendations:

Provide Bash and REST API examples for all commands, especially for retrieving IP addresses, to ensure parity for Linux users.
Clarify if PowerShell commands can be run on Linux (via PowerShell Core), or offer equivalent Bash/CLI instructions.
Explicitly mention Linux limitations and roadmap for outbound IPv6 support, and provide alternative solutions for Linux users where possible.
Ensure that examples and instructions are presented in a platform-neutral order (e.g., Azure CLI first, then PowerShell), or grouped by OS.
Where features are Windows-only, suggest workarounds or alternatives for Linux users, and link to relevant documentation.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by referencing Windows-specific paths (e.g., D:\home), using Windows-centric terminology and folder structures, and mentioning Windows containers before Linux containers. There are no Linux-specific examples, commands, or equivalent Linux filesystem paths provided. The only tool mentioned for disk usage is Azure Web Apps Disk Usage, with no mention of Linux alternatives. The documentation does not provide parity for Linux users in terms of examples, troubleshooting, or operational details.

Recommendations:

Include Linux-specific examples, such as Linux filesystem paths (/home/site, /home/LogFiles, etc.) and how local cache works on Linux-based App Service plans.
Mention Linux tools or commands for checking disk usage (e.g., du, df) alongside Azure Web Apps Disk Usage.
Clarify differences in behavior and support for local cache between Windows and Linux App Service environments, including any limitations or alternative features.
Provide troubleshooting steps and environment variable inspection methods for Linux environments (e.g., using SSH, Bash commands).
Ensure that references to containers mention Linux and Windows equivalently, and provide links or instructions for both.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a moderate Windows bias. PowerShell is heavily featured as a primary automation and scripting tool, with numerous examples and dedicated tabs. There are no explicit Linux shell (bash, sh) or platform-specific examples, and Windows-centric tools (PowerShell, Azure PowerShell module) are referenced before or instead of Linux alternatives. The lack of Linux-specific instructions or parity in command-line examples may hinder Linux users, especially those who do not use PowerShell.

Recommendations:

Add explicit bash or shell script examples alongside PowerShell for all CLI operations, especially for token retrieval and identity management.
Clarify that Azure CLI commands work cross-platform and provide sample usage in Linux environments (e.g., with environment variable syntax differences).
Include troubleshooting notes or platform-specific caveats for Linux users, such as file permissions, environment variable access, or REST endpoint invocation.
Where PowerShell is used for scripting, offer equivalent bash scripts or Python snippets for Linux users.
Review and update related tutorials and linked content to ensure Linux parity and visibility.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows-first bias by providing detailed subnet/IP calculations specifically for Windows Containers, mentioning Windows Server Active Directory, and referencing Windows-specific features (e.g., NetBIOS). Linux-specific guidance is minimal and only briefly mentioned (e.g., a single note about Linux continuous deployment network dependencies). There are no Linux container or Linux-specific configuration examples, and troubleshooting steps focus on Azure CLI (cross-platform) but do not provide parity for Linux-specific scenarios or tools.

Recommendations:

Add equivalent subnet/IP calculation examples for Linux containers, highlighting any differences in resource usage or configuration.
Include Linux-specific limitations or considerations (if any), such as integration with Linux authentication or file systems.
Provide Linux-focused troubleshooting steps or references, especially for common issues encountered with Linux-based App Service deployments.
Ensure that Linux and Windows examples are presented with equal prominence, or clarify when guidance applies to both platforms.
Mention Linux equivalents for Windows-specific features (e.g., alternatives to Windows Server Active Directory or NetBIOS for Linux environments).

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation page exhibits Windows bias in several ways. Windows-specific tools, paths, and conventions (such as 'D:\home', 'w3wp.exe', 'applicationHost.config', and references to IIS and Web Deploy/MSDeploy) are mentioned frequently and often before their Linux equivalents. Many environment variables and examples are described in terms of Windows usage, with Linux alternatives either missing, less detailed, or mentioned secondarily. Some features are described as 'native Windows apps only' or default to Windows behaviors, and references to Microsoft documentation (such as time zones) link to Windows-specific resources. Build automation and deployment sections provide more detail for Windows/Kudu than Linux/Oryx. There are also cases where Linux examples or usage patterns are omitted or less emphasized.

Recommendations:

Ensure Linux equivalents are always mentioned alongside Windows-specific instructions, with equal detail and prominence.
Provide Linux-specific examples (e.g., file paths, process names, configuration files) wherever Windows examples are given.
Avoid defaulting to Windows terminology (such as 'D:\home')—use platform-agnostic notation or list both Windows and Linux paths.
Reference Linux documentation (such as time zone lists) in addition to or instead of Windows documentation.
Balance build automation and deployment sections so that Oryx/Linux coverage matches Kudu/Windows coverage.
Where features are Windows-only, clearly indicate Linux alternatives or limitations.
Review all environment variable descriptions for platform bias and add Linux context where missing.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation page demonstrates Windows bias by presenting Visual Studio (a Windows-centric IDE) and its Package Manager Console (PowerShell-based) as the primary method for installing NuGet packages, with these instructions appearing before or alongside the cross-platform .NET CLI. There is no mention of Linux-specific tooling, editors, or package installation workflows. All examples and instructions assume a Windows development environment, omitting Linux alternatives or parity.

Recommendations:

Add explicit instructions for installing NuGet packages on Linux/macOS using the .NET CLI, and clarify that the CLI works cross-platform.
Mention and provide examples for using popular cross-platform editors (e.g., VS Code) and their workflows for package management.
Avoid referencing Windows-only tools (such as Visual Studio's Package Manager Console) without offering Linux/macOS equivalents.
Include notes or sections on running and deploying .NET web apps on Linux-based App Service environments.
Ensure that all command-line instructions are platform-neutral or provide platform-specific alternatives where necessary.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation provides installation instructions for required NuGet packages using both the .NET Core CLI and the Visual Studio Package Manager Console, but the latter is a Windows-only tool and is presented second. There are no explicit Linux-specific instructions or examples, and the only IDE mentioned is Visual Studio, which is primarily associated with Windows. No Linux-native tools or editors are referenced, and there are no bash or shell examples.

Recommendations:

Add explicit instructions for installing the packages on Linux, such as using the .NET CLI in a bash shell.
Mention cross-platform editors like VS Code and provide guidance for users on Linux and macOS.
Clarify that the .NET Core CLI commands work on Windows, Linux, and macOS, and consider listing them first.
Avoid referencing Windows-only tools (like Visual Studio's Package Manager Console) without providing Linux/macOS alternatives.
Include a note or section for Linux/macOS users to ensure parity and inclusivity.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation demonstrates a Windows-first bias by providing more detailed instructions and features for Windows App Service apps, such as web server logging, detailed error messages, and failed request tracing, which are either unavailable or not documented for Linux. Examples and tool references (e.g., Log Parser, W3C log format) are Windows-centric, and Linux-specific guidance is minimal or absent in several sections.

Recommendations:

Provide equivalent Linux examples and instructions for all logging types where supported, or clearly state if a feature is unavailable on Linux.
Include Linux-native tools and patterns for accessing and analyzing logs (e.g., using tail, less, grep, or open-source log viewers) alongside Windows tools.
Ensure that sections such as 'Enable web server logging', 'Log detailed errors', and 'Access log files' contain explicit Linux guidance or alternatives.
Clarify differences in feature availability between Windows and Linux in summary tables and throughout the documentation.
Add code and configuration examples for popular Linux stacks (Node.js, Python, Java) where only .NET/Windows examples are currently provided.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by referencing Windows-specific tools (IIS, Procdump, web.config), focusing on PowerShell for management, and linking to Windows-centric resources. There is little to no mention of Linux equivalents or guidance for Linux-based App Service environments, and examples or instructions for Linux users are missing.

Recommendations:

Include Linux-specific instructions and examples for enabling diagnostics, collecting logs, and troubleshooting (e.g., mention differences in log locations, diagnostic tools, and configuration files for Linux App Service).
When referencing tools like Kudu, clarify differences in available features and commands between Windows and Linux App Service plans.
Provide parity in management examples, such as using Azure CLI or Bash scripts alongside PowerShell, and avoid presenting PowerShell as the only or primary option.
When discussing configuration (e.g., auto-heal via web.config), note the Linux equivalent (such as app settings or other configuration mechanisms).
Link to Linux-focused documentation or sections, and ensure that all referenced tools/resources are applicable to both Windows and Linux, or clearly state platform limitations.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation shows a moderate Windows bias. Windows examples and instructions are consistently presented before Linux equivalents, and some tooling references (such as directory structure and runtime casing) are more Windows-centric. There are also minor inconsistencies and omissions in Linux instructions, such as missing the --sku parameter in one Linux example and using different runtime syntax. Additionally, some advanced troubleshooting steps reference Windows-style navigation and tools, with less detail for Linux environments.

Recommendations:

Alternate the order of Windows and Linux instructions, or present them side-by-side, to avoid always prioritizing Windows.
Ensure parity in all example commands and parameters (e.g., always include --sku for both platforms, use consistent runtime naming conventions).
Provide explicit Linux-specific troubleshooting steps and navigation instructions, especially for file system access and log review.
Clarify any differences in directory structure or command syntax between platforms, and avoid assuming Windows conventions (such as backslashes or case sensitivity).
Where possible, use platform-neutral language and tools, or provide both Windows and Linux alternatives for all steps.

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a moderate Windows bias. While Azure CLI is used for most automation steps (which is cross-platform), several sections reference Windows-centric tools (such as SQL Server Management Studio and Active Directory Integrated authentication), and the only IDE-specific publishing instructions are for Visual Studio (Windows). There are no explicit Linux or macOS examples for local debugging, publishing, or database management, and Windows tools are mentioned first or exclusively in several places.

Recommendations:

Add explicit instructions for local debugging and publishing from Linux/macOS environments, including examples using VS Code, JetBrains Rider, or command-line .NET tools.
Include cross-platform alternatives to SQL Server Management Studio, such as Azure Data Studio, and show how to use sqlcmd on Linux/macOS.
When mentioning authentication flows, clarify how they work on non-Windows platforms and provide examples for those environments.
Avoid referencing Windows-only features (such as Integrated Windows authentication) without also describing Linux/macOS equivalents or alternatives.
Ensure screenshots and step-by-step instructions for portal or CLI actions are not Windows-centric, and add notes for Linux/macOS users where workflows differ.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows bias by prioritizing Windows/Visual Studio workflows, providing PowerShell and Windows tool examples, and omitting explicit Linux development environment instructions. Key steps such as connecting to SQL Database and project modification are described in the context of Windows tools (Visual Studio, PowerShell), with no equivalent Linux or cross-platform guidance. Visual Studio for Windows is featured before cross-platform editors, and there are no examples for Linux-based SQL tools or development environments.

Recommendations:

Add explicit instructions and examples for Linux and macOS development environments, including using VS Code and JetBrains Rider.
Provide SQL Database connection steps using cross-platform tools such as sqlcmd (with installation instructions for Linux/macOS) or Azure Data Studio.
Include CLI-based workflows for project modification and publishing, avoiding reliance on Visual Studio GUI steps.
Ensure all PowerShell examples have Bash or shell equivalents.
Reorder sections to present cross-platform or neutral tooling (e.g., Azure CLI, VS Code) before or alongside Windows-specific tools.
Clarify that all steps can be performed on Linux/macOS, and provide troubleshooting notes for non-Windows environments.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

Summary:

The documentation demonstrates a moderate Windows bias, primarily through the frequent use of PowerShell and Windows-centric tools (e.g., AzPowerShell, AzureCLI with PowerShell Core, dotnet CLI) in both GitHub Actions and Azure Pipelines examples. PowerShell-based commands and terminology (e.g., 'enableAzPSSession', 'PowerShell@2', 'pscore') are used throughout, and the CLI snippets for running Playwright tests use PowerShell syntax. While the workflows run on Ubuntu runners and npm/node commands are cross-platform, the documentation does not provide explicit Linux shell (bash/sh) equivalents or highlight Linux-native patterns, and Windows/PowerShell tools are often mentioned first or exclusively.

Recommendations:

Provide Linux shell (bash/sh) equivalents for all PowerShell commands and scripts, especially for npm install, Playwright test execution, and authentication steps.
Where PowerShell is used in workflow tasks (e.g., AzureCLI@2 with 'pscore', PowerShell@2), also show how to use bash or sh scripts for the same steps.
Avoid using PowerShell-specific flags (like 'enableAzPSSession') in examples unless necessary, or clarify their cross-platform applicability.
Explicitly mention that all commands and workflows are cross-platform, and highlight any differences or additional steps needed for Linux environments.
In code snippets and CLI instructions, provide both Windows (PowerShell) and Linux (bash) command formats where applicable.
If using .NET examples (which are cross-platform), clarify that the commands work on Linux/macOS as well, and provide any OS-specific notes if needed.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows bias by prioritizing Windows-centric tools and workflows, such as Visual Studio Code, PowerShell, and .NET/NUnit, while omitting explicit Linux or cross-platform command-line examples. The use of PowerShell for .NET package installation, references to Visual Studio Code as the primary GUI, and lack of Linux-specific instructions or screenshots suggest an assumption of a Windows development environment.

Recommendations:

Provide explicit Linux/macOS equivalents for all command-line instructions, such as using 'dotnet add package' in a generic shell (bash/zsh) rather than PowerShell, and clarify any OS-specific syntax differences.
Include screenshots or instructions for using the Azure portal and Playwright CLI from Linux/macOS environments, or note that the experience is the same across platforms.
Mention and provide examples for popular Linux editors (e.g., VS Code on Linux, Vim, or JetBrains IDEs) where appropriate, or clarify that the instructions are editor-agnostic.
Ensure that all environment variable setup instructions include both Windows (set/PowerShell) and Linux/macOS (export or .env) methods.
Add a note in the prerequisites or setup sections to clarify that all steps are cross-platform unless otherwise specified, and explicitly call out any platform-specific requirements.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation demonstrates a moderate Windows bias. Windows-specific concepts (e.g., registry keys, Windows services, Windows software, file paths like c:\...) are often discussed in more detail and appear before Linux equivalents. The registry tracking section is exclusively Windows-focused, with no Linux equivalent discussion. Example queries and alerting scenarios use Windows file paths and services first, with Linux examples appearing later or not at all. The use of PowerShell/Windows-centric command syntax is prevalent, and some features (like registry tracking) are only described for Windows, with no mention of Linux alternatives or limitations.

Recommendations:

Provide Linux-specific examples and explanations alongside Windows examples, especially in sections like alerting, file tracking, and service/daemon monitoring.
Balance the order of presentation so that Linux and Windows are treated equally (e.g., alternate which OS is listed first in tables and examples).
For sections that are Windows-only (such as registry tracking), explicitly state the lack of a Linux equivalent and, if possible, suggest analogous Linux features (e.g., tracking changes to /etc or systemd unit files).
Include Linux command-line examples (e.g., bash, systemctl) where relevant, not just PowerShell or Windows CLI.
Expand the alerting/query examples to include more Linux-centric scenarios (e.g., monitoring /etc/passwd, /etc/ssh/sshd_config, or Linux package changes).
Clarify any feature limitations or differences for Linux, and provide guidance or workarounds where possible.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation provides environment variable setup instructions for Windows (cmd and PowerShell) before Linux/macOS, and includes Windows-specific commands (setx, PowerShell syntax). While Linux/macOS commands are present, Windows instructions are consistently listed first and in more detail, and Windows tools (setx, PowerShell) are explicitly mentioned, which may signal a Windows-centric approach.

Recommendations:

Alternate the order of platform instructions (sometimes show Linux/macOS first) or group all OS instructions together in a table for parity.
Provide equal detail for Linux/macOS and Windows, including any caveats (e.g., persistence of environment variables across shells/sessions).
Avoid Windows-specific tools like 'setx' unless a Linux/macOS equivalent is also discussed (e.g., how to persist environment variables in .bashrc/.zshrc).
Consider using expandable sections or tabs for each OS to avoid implicit prioritization.
Explicitly state that all major OSes are supported and tested, and provide troubleshooting tips for each.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation page demonstrates a mild Windows bias. Windows-specific tools (WSL, Windows Terminal) are mentioned prominently, and instructions for Windows users are detailed, including guidance to use WSL to run Linux commands. Azure PowerShell is referenced alongside Azure CLI for retrieving cache keys, and Windows terminology (e.g., 'console', 'terminal') is used more frequently than Linux equivalents. Linux installation instructions are present, but Windows users are directed to use Linux tools via WSL rather than native Windows alternatives. There are no Linux-specific troubleshooting or usage examples, and Azure PowerShell is mentioned before Azure CLI in some places.

Recommendations:

Provide native Windows redis-cli installation instructions (e.g., via pre-built binaries or Chocolatey) rather than requiring WSL.
Ensure Azure CLI examples are given equal prominence to Azure PowerShell, and consider listing CLI before PowerShell for cross-platform parity.
Include Linux-specific troubleshooting or usage examples, such as using redis-cli in a bash shell.
Use neutral terminology for shells and terminals (e.g., 'command prompt', 'terminal') and clarify when instructions apply to all platforms.
Explicitly mention that redis-cli commands are identical across platforms, and highlight any platform-specific caveats.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

Summary:

The documentation provides both Azure CLI and Azure PowerShell examples for automating Premium V3 tier configuration, but it lists PowerShell as a primary automation option and includes a dedicated PowerShell section. The CLI examples are cross-platform, but there is a subtle Windows-first bias in the ordering and inclusion of PowerShell, which is primarily used on Windows. The documentation does not mention Linux-specific tools (e.g., bash scripts) or provide explicit Linux shell examples beyond Azure CLI. The portal instructions are platform-neutral, but the automation section could better highlight Linux parity.

Recommendations:

Explicitly state that Azure CLI commands work on Linux, macOS, and Windows, and recommend it as the primary cross-platform automation tool.
Add bash script examples for Linux users, demonstrating how to automate with shell scripting.
Clarify that PowerShell is available on Linux and macOS, but is more commonly used on Windows.
Reorder automation sections to present Azure CLI before PowerShell, emphasizing cross-platform compatibility.
Mention Linux-native tools or workflows where relevant, such as using bash or integrating with Linux CI/CD pipelines.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

Summary:

The documentation provides both Azure CLI and PowerShell examples for managing access restrictions, but PowerShell examples are frequently presented first and are more prominent in advanced scenarios. There are no explicit Linux shell or Bash-specific examples, and PowerShell is a Windows-centric tool, which may disadvantage Linux users. However, the Azure CLI is cross-platform and included, mitigating some bias. There are no references to Windows-only tools outside of PowerShell, and the documentation does mention Linux App Service workloads, but practical Linux command-line usage is not highlighted.

Recommendations:

Ensure that Azure CLI examples are always presented before or alongside PowerShell examples, as Azure CLI is cross-platform and more familiar to Linux users.
Explicitly mention that Azure CLI commands can be run from Bash or other Linux shells, and provide example command lines in Bash syntax where appropriate.
Add a note clarifying that PowerShell examples are primarily for Windows users, while Azure CLI is recommended for Linux/macOS environments.
Where possible, provide Bash script snippets or usage patterns for Linux users, especially in advanced or automation scenarios.
Review screenshots and UI references to ensure they are not Windows-centric (e.g., avoid showing only Windows browser/desktop UI if possible).

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation page focuses exclusively on assessing ASP.NET web apps, implicitly assuming a Windows environment. There are no examples, tools, or guidance for assessing .NET web apps running on Linux, nor is there mention of Linux-specific considerations or tools. The linked resources and terminology (ASP.NET, App Service) reinforce a Windows-centric perspective, potentially excluding users running .NET Core or ASP.NET Core apps on Linux.

Recommendations:

Include explicit guidance and examples for assessing .NET web apps running on Linux, such as .NET Core or ASP.NET Core apps.
Mention and link to Linux-compatible tools or assessment workflows, if available.
Clarify whether the assessment process applies equally to Linux-hosted .NET apps, and note any differences or additional steps required.
Balance terminology by referencing both Windows and Linux hosting scenarios where applicable.
Add a section or note addressing Linux users, including any prerequisites or limitations.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation exhibits a mild Windows bias by referencing the Windows deployment path (C:\home\site\wwwroot) first and providing a relative path example (auth.json) that is only valid on Windows. The Linux-specific requirement for absolute paths is mentioned only in a note, and no Linux-specific example is given in the main steps. There are no Linux command-line or tooling examples, and the documentation does not provide parity in illustrating Linux deployment patterns.

Recommendations:

Provide both Windows and Linux path examples in the main instructions, not just in a note.
When giving a sample path, include both a Windows (e.g., C:\home\site\wwwroot\auth.json) and a Linux (/home/site/wwwroot/auth.json) version.
Explicitly state the differences in path handling for both platforms in the main step-by-step instructions, not only in a note.
If referencing deployment directories, clarify how these map to both Windows and Linux App Service environments.
Consider including a Linux-focused example or section, especially for common deployment scenarios.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation provides detailed, step-by-step SSH access instructions and CLI examples only for Linux containers, while Windows containers are mentioned only briefly and lack equivalent technical guidance. The Windows section is presented first, but does not offer parity in terms of actionable steps or troubleshooting, potentially leaving Windows users underserved and Linux users as the primary audience.

Recommendations:

Add step-by-step instructions for opening SSH sessions to Windows containers, including any available CLI, PowerShell, or RDP alternatives, or clearly state if such options are unavailable.
If SSH via CLI is not supported for Windows containers, explicitly mention this and suggest any supported remote management alternatives.
Balance the order of presentation by either alternating Linux and Windows sections or providing equivalent depth for both platforms.
Include troubleshooting tips and example outputs for Windows containers, similar to those provided for Linux.
Where features are not available for Windows, provide clear guidance and links to feature requests or roadmap information.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page shows a subtle Windows bias: in the prerequisite links and quickstart references, the 'windows' tab is listed first, and there are no explicit Linux-specific instructions or examples for environment variable setup, deployment, or local development. While the content is mostly cross-platform, it assumes familiarity with the Azure portal and does not provide parity for Linux command-line or deployment workflows.

Recommendations:

Ensure that all quickstart and prerequisite links include both Windows and Linux tabs, and consider listing Linux first or equally.
Add explicit Linux (bash) command-line examples for setting environment variables and deploying to Azure App Service.
Include instructions for using Linux-native tools (e.g., export for environment variables, bash scripts) alongside or before Windows/portal-based instructions.
Clarify that all steps are cross-platform and, where differences exist (such as file paths or command syntax), provide both Windows and Linux variants.
If referencing the Azure portal, note any differences in experience for Linux-hosted App Service plans.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

Summary:

The documentation presents both Azure PowerShell and Azure CLI examples, but consistently lists PowerShell (a Windows-centric tool) before CLI in all code sections. There are no explicit Linux or Bash-specific examples, and PowerShell is given prominence, which may suggest a Windows-first approach. However, the inclusion of Azure CLI examples does provide cross-platform parity, as CLI is available on Linux, macOS, and Windows.

Recommendations:

Alternate the order of PowerShell and Azure CLI tabs or present Azure CLI first, as it is cross-platform and widely used on Linux.
Explicitly mention that Azure CLI commands work on Linux, macOS, and Windows, and consider adding Bash-specific notes or examples where relevant.
Add a brief section or note highlighting that all steps can be performed from Linux or macOS using Azure CLI, and link to relevant setup guides for non-Windows environments.
If possible, include screenshots or terminal output from Linux environments to reinforce parity.
Avoid language that assumes Visual Studio or other Windows-only tools as the default workflow; mention cross-platform alternatives where applicable.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation assumes a development environment based on GitHub Codespaces and .NET, which are cross-platform, but it lacks explicit Linux-specific instructions or examples. All terminal commands and deployment steps are shown in a generic way, but there are subtle Windows-first assumptions, such as references to 'Open in Browser' (a Codespaces UI feature, but not a standard Linux terminal operation) and no mention of Linux-specific tools or alternative workflows. There are no PowerShell-specific commands, but the absence of Linux shell (bash) or self-hosted deployment examples may make Linux users feel less directly supported.

Recommendations:

Add explicit Linux shell (bash) command examples where relevant, especially for running and deploying the app outside Codespaces.
Include instructions for running the sample app locally on Linux (e.g., using bash terminal, systemd, or Docker), not just in Codespaces.
Mention and provide examples for Linux-native tools (such as curl or wget for testing endpoints) alongside browser-based Swagger UI instructions.
Clarify that all .NET CLI commands work cross-platform, and provide troubleshooting tips for common Linux-specific issues (e.g., permissions, environment variables).
If referencing UI actions (like 'Open in Browser'), provide alternative command-line instructions for users working in a pure terminal environment.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation demonstrates environment-specific configuration using ASP.NET Core and Azure App Configuration, but it assumes a Windows development environment by referencing 'launchSettings.json' and does not provide equivalent Linux/macOS instructions or examples. There are no mentions of Linux-specific environment variable management or cross-platform development patterns.

Recommendations:

Include instructions for setting environment variables on Linux/macOS (e.g., using export in the shell or .env files) alongside the 'launchSettings.json' method.
Mention that 'launchSettings.json' is primarily used by Visual Studio and may not apply in all environments, especially on Linux.
Provide examples of running the application and setting ASPNETCORE_ENVIRONMENT from the command line on Linux/macOS, such as 'ASPNETCORE_ENVIRONMENT=Production dotnet run'.
Clarify that the steps apply to all platforms and highlight any platform-specific differences where relevant.

Create pull request

Bias Types:

⚠️ windows_first

Summary:

The documentation presents default values for DNS configuration with 'Windows default value' listed before 'Linux default value' in the property table. However, the overall content and examples are platform-neutral, using Azure CLI commands applicable to both Windows and Linux environments. There are no PowerShell-specific examples, Windows-only tools, or missing Linux examples. The only explicit Windows-specific mention is in the limitations section, which is appropriate.

Recommendations:

In the property table, consider listing 'Linux default value' before 'Windows default value', or present both in parallel columns without implied priority.
Explicitly state that all CLI examples are cross-platform to reassure Linux users.
Where differences exist (such as the limitation for Windows), ensure similar Linux limitations (if any) are also mentioned for parity.
Continue to avoid Windows-specific tools or commands unless Linux equivalents are also provided.

Create pull request

Bias Types:

⚠️ windows_first

Summary:

The documentation page lists configuration provider libraries for multiple languages and platforms, but the ordering and emphasis place .NET (and by extension, Windows-centric technologies) first, with detailed links and samples for .NET Standard, ASP.NET Core, Azure Functions, and .NET Framework before mentioning Java, Python, JavaScript, and Go. There are no explicit Linux or cross-platform command-line examples, but the structure implicitly prioritizes Windows/.NET ecosystems.

Recommendations:

Reorder the provider library table to rotate or randomize the order of languages/platforms, or group by language family (e.g., statically typed, dynamically typed) rather than placing .NET/.NET Framework first.
Add explicit mention of cross-platform compatibility for each provider, especially for .NET Core and ASP.NET Core, which are cross-platform.
Include Linux/macOS-specific notes or examples where relevant, such as how to use these providers in Linux containers or on non-Windows environments.
Ensure parity in sample links and documentation depth for non-Windows platforms and languages.
Consider adding a section or callout highlighting Linux and containerized deployment scenarios, which are common in modern cloud-native development.

Create pull request

No problematic pages found in this scan. All pages appear to be Linux-friendly! 🐧