Azure Functions
711
Total Pages
610
Linux-Friendly Pages
101
Pages with Bias
14.2%
Bias Rate
Bias Trend Over Time
Pages with Bias Issues
233 issues found
Showing 126-150 of 233 flagged pages
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/durable/durable-functions-unit-testing.md
...re-functions/durable/durable-functions-unit-testing.md
Medium Priority
View Details →
Detected Bias Types
Windows First
Missing Linux Example
Summary
The documentation provides only C#/.NET in-process examples, with all code samples and testing frameworks (xUnit, moq) focused on the .NET ecosystem. There is no mention of Linux-specific tools, cross-platform test runners, or guidance for running tests on Linux. The use of localhost URLs and .NET-centric libraries may implicitly favor Windows environments, and there are no explicit instructions or examples for Linux users.
Recommendations
- Add explicit guidance for running unit tests on Linux, including any required dependencies or differences in setup.
- Mention and provide examples for running xUnit tests using cross-platform .NET Core CLI commands (e.g., 'dotnet test') rather than assuming Visual Studio or Windows-based workflows.
- Clarify that all tools and frameworks used (xUnit, moq) are cross-platform and provide links or instructions for installing them on Linux.
- Include a note or section on running Durable Functions unit tests in Linux environments, possibly with Docker or WSL, to ensure parity.
- If possible, provide equivalent examples or references for other supported languages/runtimes (e.g., Python, JavaScript) that are popular on Linux.
Create Pull Request
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/errors-diagnostics/diagnostic-events/azfd0010.md
...tions/errors-diagnostics/diagnostic-events/azfd0010.md
Medium Priority
View Details →
Detected Bias Types
Windows First
Missing Linux Example
Summary
The documentation suggests switching to Windows as the primary workaround for timezone support, without offering Linux-specific alternatives or examples. There are no Linux-friendly solutions or guidance, and the only actionable recommendation is to use Windows.
Recommendations
- Provide Linux-compatible workarounds or alternatives for timezone handling, such as using UTC or handling time zone conversion within the application code.
- Include explicit examples or references for Linux users, clarifying what is and isn't supported and how to achieve common scenarios.
- Avoid recommending Windows as the only solution; instead, present it as one of several options, with equal emphasis on Linux approaches.
- Link to or describe best practices for time zone management in Linux-based Azure Functions.
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/functions-bindings-documentdb-output.md
...zure-functions/functions-bindings-documentdb-output.md
Medium Priority
View Details →
Detected Bias Types
Windows First
Missing Linux Example
Summary
The documentation page focuses exclusively on .NET/C# examples and NuGet packages, which are most commonly used on Windows. There are no examples or guidance for Linux-based development environments, such as using Azure Functions with Python, Node.js, or other languages, nor are there any references to Linux-specific tools or workflows. All code samples and setup instructions assume a Windows-centric development stack.
Recommendations
- Add examples for other supported languages (e.g., Python, JavaScript/Node.js) to demonstrate cross-platform usage.
- Include instructions for setting up Azure Functions projects on Linux (e.g., using VS Code, CLI, or Docker), not just .NET in-process worker model.
- Reference package managers and installation steps relevant to Linux (e.g., pip for Python, npm for Node.js) alongside NuGet.
- Clarify that Azure Functions and DocumentDB bindings are supported on both Windows and Linux, and provide parity in documentation.
- Add troubleshooting or environment setup notes for Linux users, such as permissions, environment variables, or common issues.
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/functions-bindings-mcp.md
...ain/articles/azure-functions/functions-bindings-mcp.md
Medium Priority
View Details →
Detected Bias Types
Windows Tools
Missing Linux Example
Summary
The documentation page demonstrates a mild Windows bias by only providing an Azure CLI example for retrieving the system key, without mentioning or providing equivalent commands for common Linux shells (e.g., Bash) or cross-platform alternatives. There are no explicit PowerShell examples, but the use of Azure CLI is more common on Windows, and no Linux-specific tools or shell commands are referenced. No Linux-specific installation or usage notes are present, and the documentation does not clarify cross-platform compatibility for local development tools.
Recommendations
- Provide explicit Bash and/or cross-platform shell examples for retrieving the system key, in addition to or instead of Azure CLI.
- Clarify that Azure CLI is cross-platform and provide installation links or notes for Linux/macOS users.
- Add notes or examples for running Azure Functions Core Tools on Linux, including any prerequisites or common troubleshooting steps.
- Ensure that all command-line examples are tested and work on both Windows and Linux environments.
- Where relevant, mention Linux package managers (e.g., apt, yum, brew) for installing dependencies.
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/functions-bindings-openai-assistantpost-input.md
...tions/functions-bindings-openai-assistantpost-input.md
Medium Priority
View Details →
Detected Bias Types
Powershell Heavy
Windows Tools
Summary
The documentation provides dedicated PowerShell examples and configuration details, including a function.json and run.ps1, but does not offer equivalent Linux shell (e.g., Bash) examples or mention Linux-specific tools or patterns. This may unintentionally favor Windows users by assuming PowerShell as the default scripting environment for operational tasks, while omitting parity for Linux users.
Recommendations
- Add equivalent Bash or shell script examples alongside PowerShell for operational tasks, such as invoking the function or managing configuration.
- Clarify that PowerShell examples can be run cross-platform, but also provide Linux-native alternatives where appropriate.
- Mention Linux tools or patterns (e.g., environment variable configuration via .env files, use of curl or wget for HTTP requests) in relevant sections.
- Ensure that all configuration steps (such as editing function.json) are described in a way that is platform-agnostic, or provide platform-specific instructions for both Windows and Linux.
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/functions-create-first-java-gradle.md
.../azure-functions/functions-create-first-java-gradle.md
Medium Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Summary
The documentation exhibits a Windows bias by specifying 'os = windows' in the Gradle configuration without mentioning Linux or cross-platform alternatives. The runtime example defaults to Windows, and there is no discussion of Linux deployment or configuration, despite Java 21 being supported only on Linux. The instructions and examples do not address Linux-specific considerations or parity, and the Azure portal workflow is presented without mention of CLI alternatives that may be more common on Linux.
Recommendations
- Add explicit examples and instructions for deploying to Linux by showing 'os = linux' in the Gradle configuration and discussing any differences.
- Mention that Java 21 is supported only on Linux and provide guidance for users who wish to use this version.
- Include notes or sections on verifying deployments and managing function apps using Azure CLI or other cross-platform tools, not just the Azure portal.
- Ensure that all steps and screenshots are platform-neutral or provide alternatives for both Windows and Linux environments.
- Clarify any platform-specific requirements or limitations, especially for local development and deployment.
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/functions-create-maven-intellij.md
...les/azure-functions/functions-create-maven-intellij.md
Medium Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Summary
The documentation shows a mild Windows bias, primarily by referencing Windows as the default or first platform in key steps (e.g., suggesting 'Windows-Java 17' as the platform during Azure Function App creation) and using Windows-centric terminology (e.g., referencing 'Settings/Preferences' dialog with Windows keyboard shortcuts). There are no explicit Linux or macOS examples, and Linux is only mentioned in passing (e.g., Java 21 support). However, the instructions are largely cross-platform due to the use of IntelliJ IDEA and Maven, which are available on all major OSes.
Recommendations
- When referencing platform selection (e.g., 'Platform: Windows-Java 17'), provide Linux and macOS equivalents, or clarify that Linux and macOS are supported and how to select them.
- Include keyboard shortcuts and navigation instructions for macOS and Linux alongside Windows (e.g., mention Cmd+, for Preferences on macOS).
- If there are any OS-specific steps (such as setting JAVA_HOME), provide explicit instructions or links for Linux/macOS users.
- Where possible, use neutral language (e.g., 'Preferences' instead of 'Settings/Preferences') and avoid defaulting to Windows-first terminology.
- Add a note in the prerequisites or relevant sections confirming that all steps are valid for Linux and macOS, and highlight any differences.
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/functions-create-private-site-access.md
...zure-functions/functions-create-private-site-access.md
Medium Priority
View Details →
Detected Bias Types
Windows First
Missing Linux Example
Summary
The documentation demonstrates Windows bias by exclusively guiding users to create a Windows Server VM, with no mention of Linux VM alternatives or examples. All screenshots and instructions for VM creation are Windows-centric, and there are no Linux-specific steps or parity in the walkthrough. This may unintentionally suggest that Windows is the default or preferred platform for this scenario, potentially alienating Linux users.
Recommendations
- Include instructions and screenshots for creating a Linux VM (e.g., Ubuntu) alongside the Windows VM steps.
- Explicitly mention that either Windows or Linux VMs can be used for accessing Azure Functions within a virtual network.
- Provide parity in examples for connecting to the VM (e.g., SSH for Linux, RDP for Windows) and clarify Bastion supports both.
- Where VM OS selection is discussed, present Windows and Linux options equally, not Windows-first.
- Add troubleshooting or notes relevant to Linux users (e.g., browser access, command-line tools).
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/functions-how-to-use-nat-gateway.md
...es/azure-functions/functions-how-to-use-nat-gateway.md
Medium Priority
View Details →
Detected Bias Types
Windows First
Missing Linux Example
Summary
The documentation demonstrates a Windows bias by explicitly recommending Windows as the operating system for the function app and providing no guidance or examples for Linux-based deployments. There are no Linux-specific instructions, notes, or parity checks, and the only runtime stack mentioned is .NET. This may lead Linux users to believe the tutorial is not applicable to them or that Linux is not supported.
Recommendations
- Provide explicit instructions and notes for both Windows and Linux operating systems when creating the function app, including any differences in configuration or limitations.
- Include examples or screenshots for Linux-based function apps where the Azure portal UI or workflow differs.
- Clarify whether the tutorial steps and code samples are applicable to Linux, and if not, specify any limitations or required changes.
- Mention Linux as a supported option in the prerequisites and throughout the tutorial, ensuring parity in recommendations.
- If there are platform-specific behaviors (e.g., outbound IP address handling), document them clearly for both Windows and Linux.
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/functions-reliable-event-processing.md
...azure-functions/functions-reliable-event-processing.md
Medium Priority
View Details →
Detected Bias Types
Missing Linux Example
Windows Tools
Summary
The documentation does not provide explicit examples or instructions for either Windows or Linux environments, but it does reference .NET/C#-specific libraries (e.g., Polly) and does not mention Linux-specific tools, patterns, or code samples. There are no PowerShell or Windows command-line examples, but the focus on C# and Azure-centric tools may implicitly favor Windows developers. No Linux-first or cross-platform parity is demonstrated.
Recommendations
- Include code samples in multiple languages (e.g., Python, JavaScript) that are popular on Linux, not just C#.
- Reference cross-platform retry and resilience libraries (e.g., Tenacity for Python, or libraries for Node.js) alongside Polly.
- Explicitly mention that Azure Functions and Event Hubs triggers are supported on both Windows and Linux, and provide any Linux-specific considerations if applicable.
- Add examples or links for deploying and managing Azure Functions from Linux environments (e.g., using Azure CLI/Bash scripts).
- Ensure that all guidance (such as error handling and circuit breaker patterns) is language- and platform-agnostic, or provide parity across platforms.
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/monitor-functions-reference.md
...rticles/azure-functions/monitor-functions-reference.md
Medium Priority
View Details →
Detected Bias Types
Missing Linux Example
Windows First
Summary
The documentation page demonstrates a bias toward Windows by omitting Linux-specific monitoring examples and by noting that certain metrics are unavailable on Linux Consumption plans without providing Linux alternatives or workarounds. The documentation implicitly assumes Windows as the default environment, with Linux support mentioned only as an exception.
Recommendations
- Provide explicit Linux examples and guidance for monitoring Azure Functions on Linux Consumption plans.
- Clearly indicate which metrics and features are supported on Linux, and suggest alternative monitoring strategies or tools for unsupported metrics.
- Ensure that Linux and Windows are presented with equal prominence, including parallel documentation sections or tabs for both platforms.
- Add troubleshooting or FAQ sections addressing common Linux-specific monitoring limitations and solutions.
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/run-functions-from-deployment-package.md
...ure-functions/run-functions-from-deployment-package.md
Medium Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Summary
The documentation consistently mentions Windows paths and deployment patterns before Linux equivalents (e.g., 'c:\home\site\wwwroot' before '/home/site/wwwroot'), and references Windows-specific tools and terminology (e.g., MSDeploy, c: drive paths). There are no explicit Linux command-line examples or Linux-first workflows, and the guidance is generally Windows-centric, with Linux support described as exceptions or alternatives.
Recommendations
- Alternate the order of Windows and Linux paths and examples to avoid always listing Windows first.
- Provide Linux-specific command-line examples (e.g., using Bash, zip, or Linux-native tools) alongside or before Windows/Powershell equivalents.
- Reference Linux deployment patterns and tools (such as SCP, rsync, or Azure CLI on Linux) where appropriate.
- Clarify when a feature or setting behaves differently on Linux, and provide Linux-first guidance where Linux is the primary or only supported platform (e.g., Consumption plan).
- Avoid exclusive references to Windows tools like MSDeploy; mention Linux alternatives or clarify cross-platform options.
- Include screenshots or UI walkthroughs from both Windows and Linux environments where relevant.
Azure Functions
Guide for running C# Azure Functions in an isolated worker process
...icles/azure-functions/dotnet-isolated-process-guide.md
Low Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Powershell Heavy
Summary
The documentation provides a generally cross-platform guide for running C# Azure Functions in an isolated worker process, but there are several areas where Windows tools, patterns, and examples are mentioned first or exclusively. Windows-specific instructions (such as PowerShell and Visual Studio) are often listed before Linux equivalents, and some CLI commands are presented in a Windows-centric manner. While Linux is supported and referenced, Windows approaches are sometimes prioritized or explained in greater detail.
Recommendations
- Ensure that Linux and macOS equivalents are always presented alongside Windows instructions, especially in sections about deployment, debugging, and performance optimizations.
- When listing tools or methods (e.g., Visual Studio, Azure CLI, PowerShell), alternate the order or explicitly state cross-platform applicability.
- Add more explicit Linux/macOS examples for CLI commands, file paths, and environment variable configuration.
- Where PowerShell is referenced, provide Bash or shell equivalents.
- Clarify any platform-specific limitations or differences, and link to Linux/macOS-specific guides where appropriate.
Azure Functions
App settings reference for Azure Functions
...ain/articles/azure-functions/functions-app-settings.md
Low Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Summary
The documentation is generally cross-platform and covers both Windows and Linux scenarios for Azure Functions app settings. However, there are minor instances of Windows bias: Windows-specific syntax (e.g., %HOME% in AzureWebJobs_TypeScriptPath) is used without a Linux equivalent, and Windows-only settings (e.g., WEBSITE_NODE_DEFAULT_VERSION) are described before Linux alternatives. Azure CLI and PowerShell are mentioned as preferred tools for managing settings, but Linux-native tools (e.g., Bash) are not referenced. Overall, Linux parity is strong, but minor improvements could be made.
Recommendations
- For settings with OS-specific syntax (e.g., AzureWebJobs_TypeScriptPath), provide both Windows and Linux examples.
- When mentioning Windows-only settings (e.g., WEBSITE_NODE_DEFAULT_VERSION), explicitly state Linux alternatives or link to relevant Linux documentation.
- When recommending Azure CLI or PowerShell for managing settings, also mention Bash or other Linux-native scripting tools.
- Review the order of examples and settings to ensure Linux and Windows are treated equally (e.g., in WEBSITE_TIME_ZONE, Linux is listed second; consider listing both together or alternating order).
Azure Functions
Azure Functions networking options
...ticles/azure-functions/functions-networking-options.md
Low Priority
View Details →
Detected Bias Types
Powershell Heavy
Windows First
Summary
The documentation provides both Azure CLI and PowerShell examples for configuring virtual network triggers, but the PowerShell example is given equal prominence and detail. The Hybrid Connections feature is explicitly Windows-only, but this is clearly stated and justified. In the automation section, only Azure CLI and ARM template examples are provided, which are cross-platform. Throughout the page, there is no evidence of Windows-only tools or patterns being mentioned exclusively or before Linux equivalents, but the PowerShell example is present alongside CLI. The subnet sizing recommendations for Windows and Linux are clearly differentiated, with Linux guidance provided. Overall, minor bias is present due to the inclusion of PowerShell examples and Windows-first language in some sections, but Linux parity is generally maintained.
Recommendations
- Where PowerShell examples are given, ensure that equivalent Azure CLI examples are always provided and shown first, as CLI is cross-platform.
- Consider adding bash or Linux-specific scripting examples where relevant, especially in automation sections.
- Continue to clearly indicate Windows-only features (such as Hybrid Connections) to avoid confusion.
- Review the order of examples to ensure CLI (cross-platform) is prioritized over PowerShell (Windows-centric).
Azure Functions
Migrate Consumption plan apps to Flex Consumption in Azure Functions
...unctions/migration/migrate-plan-consumption-to-flex.md
Low Priority
View Details →
Detected Bias Types
Windows First
Summary
The documentation provides parallel, detailed instructions for both Linux and Windows users throughout, with clear pivots and tabs for each platform. However, in several sections (notably the 'Assess your existing app' and 'Migration Steps'), the Windows/portal/CLI instructions are presented before the Linux equivalents, and some advanced configuration scripts and troubleshooting steps are more detailed for Windows. There are no missing Linux examples, and Linux-specific migration tooling (such as the az functionapp flex-migration CLI) is highlighted. No critical steps are Windows-only, and Linux users can complete the migration end-to-end.
Recommendations
- Where possible, present Linux and Windows instructions in parallel or alternate which platform appears first in each section to avoid implicit prioritization.
- Ensure that advanced troubleshooting and configuration examples are equally detailed for both platforms.
- Continue to clearly mark platform-specific features and tools, and maintain parity in depth and clarity of examples.
Azure Functions
Troubleshoot Python function apps in Azure Functions
...n/articles/azure-functions/recover-python-functions.md
Low Priority
View Details →
Detected Bias Types
Windows First
Powershell Heavy
Windows Tools
Summary
The documentation generally maintains good cross-platform coverage, but there are several instances where Windows tools, commands, or patterns are presented before their Linux equivalents, or with more detail. In some troubleshooting sections, PowerShell and Windows command-line examples are given first, and Windows-specific tools (like 'py') are referenced before Unix equivalents. However, Linux/macOS guidance is present throughout, and critical tasks are not Windows-only.
Recommendations
- When providing command-line examples, present Linux/macOS (bash) and Windows (PowerShell/cmd) examples side-by-side or in parallel tabs, rather than listing Windows first.
- When referencing tools like 'py' (Windows Python launcher), clarify that 'python3' is the equivalent on Linux/macOS, and consider listing 'python3' first since Azure Functions runs on Linux.
- In sections where PowerShell or Windows commands are given, ensure bash/Linux equivalents are always present and not secondary.
- Where possible, use neutral language and avoid implying Windows as the default development environment, especially since Azure Functions Python apps run on Linux.
- Review all code snippets and instructions to ensure Linux/macOS users are equally supported and not required to infer their own equivalents.
Azure Functions
How to target Azure Functions runtime versions
...b/main/articles/azure-functions/set-runtime-version.md
Low Priority
View Details →
Detected Bias Types
Windows First
Powershell Heavy
Summary
The documentation provides both Windows and Linux guidance, but Windows/PowerShell examples are often presented first or alongside Azure CLI, while Linux-specific instructions are separated and sometimes less prominent. Azure PowerShell is given as a primary option for viewing and updating settings, even though it is not supported for some Linux-specific tasks. Linux instructions rely more heavily on Azure CLI and are sometimes described as requiring support intervention for advanced scenarios.
Recommendations
- Ensure Linux examples are presented with equal prominence and clarity as Windows/PowerShell examples.
- Where possible, provide Linux-specific instructions alongside Windows instructions, rather than in separate sections or pivots.
- Clarify when Azure PowerShell is not supported for Linux apps, and offer alternative CLI or scripting solutions.
- Add more explicit Linux portal instructions if available, or clarify portal limitations for Linux users.
- Consider showing Azure CLI examples first, as it is cross-platform, before PowerShell examples.
Azure Functions
Storage considerations for Azure Functions
...ain/articles/azure-functions/storage-considerations.md
Low Priority
View Details →
Detected Bias Types
Windows First
Powershell Heavy
Summary
The documentation generally covers storage considerations for Azure Functions across platforms, but there are minor signs of Windows bias. Windows-specific plans and settings are mentioned before Linux equivalents in several places, and PowerShell examples are provided alongside Azure CLI, sometimes with Windows-focused language. However, Linux-specific guidance is also present, especially in the section about mounting file shares, which is clearly marked as Linux-only.
Recommendations
- Ensure that Linux and macOS examples are provided wherever Windows/PowerShell examples are given, especially in sections about configuration and deployment.
- When describing settings or plans, avoid listing Windows options first unless there is a technical reason.
- Clarify parity between Windows and Linux for features like Azure Files, deployment settings, and scaling, and explicitly note any limitations or differences.
- Where PowerShell is mentioned, also provide Bash or CLI equivalents for Linux/macOS users.
- Consider adding a summary table or section highlighting feature parity and platform-specific limitations.
Azure Functions
Guide for running C# Azure Functions in an isolated worker process
...icles/azure-functions/dotnet-isolated-process-guide.md
Low Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Summary
The documentation provides a generally cross-platform guide for running C# Azure Functions in an isolated worker process, with explicit instructions and examples for both Windows and Linux. However, there are minor instances of Windows bias: Windows deployment/configuration commands and runtime identifiers are presented before Linux equivalents, and some CLI examples default to Windows terminology. Windows tools (e.g., Visual Studio) are mentioned before Linux alternatives (e.g., VS Code, Azure CLI), and some ReadyToRun and debugging instructions are Windows-centric before Linux is addressed.
Recommendations
- Ensure Linux examples and instructions are presented alongside or before Windows equivalents, especially in deployment, configuration, and performance optimization sections.
- Where CLI commands are shown, provide both Windows and Linux syntax in parallel tabs or sections.
- Highlight cross-platform tools (VS Code, Azure CLI) equally or before Windows-only tools (Visual Studio) when listing options.
- In tables and lists, alternate the order of Windows and Linux to avoid implicit prioritization.
- Add explicit notes that all major features and workflows are supported on both Windows and Linux, unless otherwise stated.
Azure Functions
App settings reference for Azure Functions
...ain/articles/azure-functions/functions-app-settings.md
Low Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Summary
The documentation is generally cross-platform and includes Linux-specific content and settings. However, there are minor instances of Windows bias: some examples and explanations present Windows first (e.g., in the WEBSITE_TIME_ZONE table), and a few settings reference Windows paths or behaviors (e.g., AzureWebJobs_TypeScriptPath uses a Windows-style path). Some legacy or platform-specific settings are clearly marked as Windows-only, but these are not the focus of the page. There is a slight preference for mentioning Windows or Windows tools first in a few places, but Linux parity is mostly maintained.
Recommendations
- When showing OS-specific examples (such as paths or time zones), always provide both Windows and Linux/macOS equivalents, or show Linux first if usage is common.
- For settings like AzureWebJobs_TypeScriptPath, provide a Linux-style path example alongside the Windows one.
- Where behaviors differ between Windows and Linux (e.g., delimiter handling in app setting names), consider highlighting Linux behavior first or equally.
- Continue to clearly mark Windows-only settings as such, and ensure Linux/macOS users are directed to equivalent settings or documentation where applicable.
Azure Functions
host.json reference for Azure Functions 2.x
...b/main/articles/azure-functions/functions-host-json.md
Low Priority
View Details →
Detected Bias Types
Powershell Heavy
Windows Tools
Windows First
Summary
The documentation is mostly cross-platform, but there are some areas of Windows bias. The 'managedDependency' feature is described as PowerShell-only, and references to Windows-specific tools and environment variables (e.g., %TEMP%, LOCALAPPDATA, APPDATA) appear in snapshot configuration. In the explanation of tempFolder and shadowCopyFolder, Windows environment variables are mentioned first, with no explicit Linux/macOS equivalents. The ordering of examples and references sometimes favors Windows conventions (e.g., timespan format, environment variable naming), and there is little explicit mention of Linux/macOS paths or conventions.
Recommendations
- Clarify when features are Windows-only or PowerShell-only, and provide Linux/macOS alternatives or explicitly state when none exist.
- When referencing environment variables or file paths, include both Windows and Linux/macOS equivalents (e.g., $HOME, /tmp).
- Add examples or notes for Linux/macOS users where file paths, environment variables, or behaviors differ.
- Ensure ordering of examples and references does not consistently favor Windows conventions when the feature is cross-platform.
Azure Functions
Storage considerations for Azure Functions
...ain/articles/azure-functions/storage-considerations.md
Low Priority
View Details →
Detected Bias Types
Windows First
Powershell Heavy
Summary
The documentation is generally cross-platform and covers both Windows and Linux hosting scenarios for Azure Functions. However, there are instances of Windows bias, such as Windows-specific plans being mentioned first, and PowerShell examples being provided alongside Azure CLI, even in Linux-only sections. Some minor friction exists for Linux users, but most guidance is applicable to both platforms.
Recommendations
- When listing hosting plans or features, alternate or balance the order between Windows and Linux to avoid implicit prioritization.
- In sections specifically about Linux functionality (e.g., mounting file shares), consider providing Bash or Linux-native examples before PowerShell, or clarify that PowerShell is cross-platform.
- Where PowerShell is shown, ensure that equivalent Bash/CLI examples are present and clearly marked for Linux/macOS users.
- Explicitly note platform differences or limitations where relevant, to help users quickly identify applicable guidance.
Azure Functions
App settings reference for Azure Functions
...ain/articles/azure-functions/functions-app-settings.md
Low Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Summary
The documentation is generally cross-platform and covers both Windows and Linux scenarios. However, there are minor instances of Windows bias: some examples and explanations mention Windows first or use Windows-style paths (e.g., %HOME%\typescript), and Windows-specific settings (like WEBSITE_NODE_DEFAULT_VERSION) are called out, sometimes before Linux equivalents. The recommendation to use Azure CLI or Azure PowerShell for programmatic management mentions PowerShell, but does not equally highlight Bash/CLI for Linux users. There are no critical sections that are Windows-only, and Linux/macOS users can complete all tasks described.
Recommendations
- When providing example paths, include both Windows and Linux formats (e.g., %HOME%\typescript and $HOME/typescript).
- When referencing tools for managing settings, mention Azure CLI and Bash scripts equally with PowerShell.
- Where settings are OS-specific, clearly label them and provide Linux/macOS equivalents or note if not applicable.
- In lists or tables, avoid always listing Windows first; alternate or group by OS.
- Ensure that all examples and sample values are provided for both Windows and Linux where differences exist.
Azure Functions
Deployment technologies in Azure Functions
...s/azure-functions/functions-deployment-technologies.md
Low Priority
View Details →
Detected Bias Types
Windows First
Powershell Heavy
Windows Tools
Summary
The documentation generally presents deployment methods and examples in a cross-platform manner, but there is a subtle Windows bias. Windows-based deployment technologies (such as Kudu, source control, FTPS, and local Git) are mentioned as 'Windows-only' or with Windows as the default context, and Windows hosting plans are often listed first. Visual Studio (Windows-centric) is frequently referenced before Visual Studio Code or CLI tools. Some deployment instructions and tables list Windows options before Linux, and certain features (like source control and FTPS) are available only on Windows, but this is clearly indicated. Linux deployment methods are covered, but sometimes appear after Windows equivalents.
Recommendations
- Ensure Linux deployment examples and instructions are presented with equal prominence and clarity as Windows examples.
- When listing deployment technologies or methods, alternate the order or explicitly state Linux and Windows support side-by-side.
- Provide explicit Linux/macOS command-line examples (e.g., bash, zsh) where appropriate, not just Azure CLI or Visual Studio/PowerShell.
- Clarify when a deployment method is cross-platform and provide links to Linux/macOS-specific guides where available.
- Highlight Linux-specific deployment scenarios and troubleshooting tips in parity with Windows coverage.