💬 EN

#

Can I run a “NuGet.Server” on “Azure App Service” or only on more infrastructure-as-a-service Azure resource types

Yes, you can run a NuGet.Server on Azure App Service. Azure App Service supports hosting ASP.NET applications, including NuGet.Server, which is an ASP.NET application¹. Here are some key points to consider:

1. Azure App Service on Windows hosts uses IIS, which is compatible with ASP.NET applications like NuGet.Server¹.
2. You can deploy NuGet.Server to Azure App Service using standard deployment methods for ASP.NET applications.
3. While it’s possible to host your own NuGet Server on Azure App Service, there are some considerations:
   • You’ll need to handle authentication and security yourself¹.
   • Performance may become an issue as the number of packages grows¹.
   • Maintenance and scalability will be your responsibility.
4. Alternatives to consider:
   • Azure Artifacts, which is part of Azure DevOps, offers a managed NuGet package hosting solution with better scalability and built-in authentication¹.
   • MyGet.org is another third-party service that can be used as a NuGet server².
5. If you decide to use Azure App Service, you’ll need to configure it properly for access, especially if you’re integrating with other systems like Azure DevOps¹.

While hosting NuGet.Server on Azure App Service is feasible, carefully consider your specific needs, especially regarding scalability, security, and maintenance, before choosing this option over managed services like Azure Artifacts.

How would I best host my NuGet packages so that every employee in my Entra directory is authorized to run Register-PSRepository against it? Not every employee is in Azure DevOps, so Azure Artifacts is out of the question.

To host your NuGet packages in a way that allows every employee in your Entra directory to run Register-PSRepository against it, you can set up a NuGet server on Azure App Service with Entra ID (formerly Azure Active Directory) integration. Here’s a recommended approach:

1. Set up a NuGet server on Azure App Service:
   • Create an ASP.NET application using NuGet.Server³.
   • Deploy the application to Azure App Service.
2. Integrate Entra ID with your NuGet server:
   • Register your application in the Azure portal⁴.
   • Configure authentication settings in your ASP.NET application.
   • Set up the necessary redirect URIs and token configuration⁴.
3. Configure NuGet server authorization:
   • Modify the NuGet.Server configuration to use Entra ID for authentication.
   • Ensure that the NuGet API is protected and only accessible to authenticated users.
4. Set up employee access:
   • Assign the appropriate roles or permissions in Entra ID to allow employees to access the NuGet server.
5. Instruct employees to register the repository:
   • Provide them with the following PowerShell command to register the repository:

     $registerPSRepositorySplat = @{
      Name = 'CompanyNuGetRepo'
      SourceLocation = 'https://your-nuget-server.azurewebsites.net/nuget'
      PublishLocation = 'https://your-nuget-server.azurewebsites.net/nuget'
      InstallationPolicy = 'Trusted'
     }
     Register-PSRepository @registerPSRepositorySplat
     

This approach ensures that:

• All employees in your Entra directory can access the NuGet server.
• Authentication is handled securely through Entra ID.
• The NuGet packages are hosted on a scalable Azure App Service.
• Employees can easily register and use the repository for PowerShell modules.

By using this method, you leverage Azure’s infrastructure while maintaining control over access through your existing Entra directory, without relying on Azure DevOps or Azure Artifacts⁵.

The authentication “just works” without them doing anything special while running Register-PSRepository?

No, the authentication for registering a PowerShell repository using Register-PSRepository will not “just work” without requiring some form of user interaction or configuration. Here’s why and how you can address this:

Key Challenges

1. Authentication Prompt: When using a private repository (e.g., hosted on Azure App Service or similar), users typically need to authenticate. This could involve manual login (e.g., device code flow) or providing credentials like a Personal Access Token (PAT)⁶⁷⁸.
2. User-Specific Repository Registration: Repositories registered with Register-PSRepository are user-specific and not system-wide, meaning each user must register the repository individually unless automated⁷⁹.

How to Make Authentication Seamless

To avoid requiring employees to manually authenticate while running Register-PSRepository, you can leverage Entra ID (Azure AD) for seamless Single Sign-On (SSO):

1. Enable Azure AD Authentication on Your NuGet Server:
   • Configure your NuGet server (e.g., hosted on Azure App Service) to use Azure AD for authentication.
   • Use the “App Service Authentication” feature in Azure to enforce Azure AD login.
2. Use Managed Identity or Token-Based Authentication:
   • If employees are logged into their machines with Entra ID accounts, they can authenticate automatically when accessing the NuGet server.
   • Ensure the NuGet server supports token-based authentication using Entra ID tokens.
3. Automate Repository Registration:
   • Pre-register the repository for all users using a startup script or group policy that runs Register-PSRepository with the necessary parameters.
   • Example PowerShell script for automation:

$repoParams = @{
    Name = 'CompanyNuGetRepo'
    SourceLocation = 'https://your-nuget-server.azurewebsites.net/nuget'
    PublishLocation = 'https://your-nuget-server.azurewebsites.net/nuget'
    InstallationPolicy = 'Trusted'
}
Register-PSRepository @repoParams

1. Use System-Wide Configuration:
   • Store repository settings in a shared location accessible by all users (e.g., via a profile script or environment variables).
   • Alternatively, use a custom module that automatically registers the repository when PowerShell is launched.

Limitations

Even with these configurations, some initial setup may still be required to ensure that all machines and users are properly configured to authenticate seamlessly. Additionally, PowerShell’s built-in support for SSO with Entra ID may vary depending on the version of PowerShell and PowerShellGet being used.

By combining Azure AD authentication and automated repository registration, you can minimize manual steps while ensuring secure access to your private NuGet packages.

I love that SSO simplicity when employees are logged into their machines with their Entra accounts. Now how do I provide them that experience and make sure that the NuGet gallery performs and scales well?

To provide a seamless SSO experience for employees logged into their machines with Entra accounts while ensuring the NuGet gallery performs and scales well, you can implement the following approach:

SSO Implementation

1. Set up Azure App Service with Entra ID authentication:
   • Configure your NuGet server on Azure App Service.
   • Enable Azure AD authentication using the “App Service Authentication” feature.
   • This allows employees to authenticate automatically when accessing the NuGet server.
2. Implement SAML-based SSO:
   • Create an Azure AD SSO application for your NuGet server.
   • Configure the SAML settings in Azure AD and your NuGet server application.
   • Use the ACS URL and Audience URI provided by Logto for secure SAML assertion exchange¹⁰.

Performance and Scaling

To ensure your NuGet gallery performs and scales well:

1. Enable Automatic Scaling:
   • Navigate to your web app’s left menu and select “scale-out (App Service Plan)”.
   • Choose “Automatic” and set the “Maximum burst” value.
   • This allows your App Service to automatically scale based on incoming HTTP requests¹¹.
2. Optimize App Service Plan:
   • Use a Premium-tier App Service Plan for better performance and scaling options.
   • Enable Per-App Scaling to allow individual apps to scale independently within the same App Service Plan¹².
3. Implement caching:
   • Use Azure Cache for Redis to cache frequently accessed NuGet packages.
   • This reduces load on your NuGet server and improves response times.
4. Content Delivery Network (CDN):
   • Implement Azure CDN to distribute package content globally.
   • This reduces latency for package downloads and improves overall performance.
5. Database optimization:
   • If using a database for package metadata, ensure it’s properly indexed and optimized.
   • Consider using Azure SQL Database with auto-scaling capabilities.

By combining these SSO and performance optimization techniques, you can provide a seamless authentication experience for your employees while ensuring your NuGet gallery scales and performs well under varying loads.

Oh my. “NuGet.server”’s last release was 3 years ago.

You’re correct. The last release of NuGet.Server was indeed quite some time ago. Based on the search results:

1. The most recent release of NuGet.Server was version 3.4.2, released on July 11, 2022¹³¹⁴. As of the current date (March 20, 2025), this means the last release was approximately 2 years and 8 months ago.
2. This lack of recent updates suggests that NuGet.Server may no longer be actively maintained or developed.
3. Given the age of the last release, it’s important to consider alternatives for hosting NuGet packages. Some options mentioned in the search results include:
   • BaGet: An open-source NuGet server implementation¹⁵
   • Azure DevOps: Offers package management capabilities¹⁵
   • Nexus OSS: A versatile repository manager supporting multiple package formats¹⁵
   • ProGet: Offers additional features like symbol package hosting¹⁵
   • Artifactory: A comprehensive artifact repository manager¹⁵
4. When choosing a NuGet server solution, it’s crucial to consider factors such as performance, security, and scalability, especially given the dated nature of NuGet.Server¹⁶.

Given this information, it may be wise to explore more actively maintained alternatives for hosting and managing NuGet packages in your development ecosystem.

Ugh. BaGet’s last release was even longer ago.

You’re right—BaGet’s last release was on September 23, 2021, which makes it even older than NuGet.Server. This lack of updates indicates that BaGet is also not actively maintained, and relying on it for a production-grade solution might not be ideal, especially given the need for scalability and reliability.

Recommended Alternatives for Hosting NuGet Packages

Given the outdated status of both NuGet.Server and BaGet, here are better-maintained and scalable solutions:

1. Azure Artifacts

• Why Consider It? Azure Artifacts is a managed service that integrates seamlessly with Azure DevOps and supports NuGet packages. While you mentioned not all employees are in Azure DevOps, you can still use Azure Artifacts with Entra ID for authentication.
• SSO Support: With Entra ID integration, employees can authenticate seamlessly without additional configuration.
• Scalability: Fully managed by Microsoft, ensuring high availability and performance.
• Drawback: Requires Azure DevOps licensing for some features.

2. GitHub Packages

• Why Consider It? GitHub Packages supports hosting NuGet packages with seamless integration into GitHub repositories.
• SSO Support: GitHub can authenticate users via Entra ID if integrated with your organization’s directory.
• Scalability: Hosted by GitHub with robust infrastructure.
• Drawback: Requires employees to have GitHub accounts.

3. ProGet

• Why Consider It? ProGet is a self-hosted package management solution that supports NuGet feeds and offers enterprise-grade features like role-based access control and auditing.
• SSO Support: Can integrate with Entra ID for authentication.
• Scalability: Can be deployed on scalable infrastructure like Azure Virtual Machines or Kubernetes.
• Drawback: Requires self-hosting and maintenance.

4. Artifactory

• Why Consider It? JFrog Artifactory is an enterprise-grade artifact repository manager supporting NuGet packages.
• SSO Support: Integrates well with Entra ID for authentication.
• Scalability: Highly scalable and supports clustering for large-scale deployments.
• Drawback: Licensing costs can be high for enterprise features.

5. NuGet.org (Private Feeds)

• If you want simplicity, consider using NuGet.org’s private feeds. You can restrict access to packages using API keys or tokens tied to Entra ID authentication.

Hosting Your Own Solution

If you still prefer hosting your own solution:

• Use a modern framework like ASP.NET Core to build a custom NuGet server that integrates directly with Entra ID for SSO.
• Deploy it on Azure App Service or Kubernetes for scalability.
• Implement caching (e.g., Azure Cache for Redis) and CDN (e.g., Azure CDN) to improve performance.

Given the outdated nature of NuGet.Server and BaGet, leveraging managed services like Azure Artifacts or GitHub Packages is likely the best path forward for scalability, security, and ease of use while ensuring seamless SSO integration with Entra ID.

What about Azure File Share? What do I have to do to make that accessible for remote workers, since ISPs often block port 445?

Azure File Share can be made accessible for remote workers even when ISPs block port 445. Here are several approaches to achieve this:

1. Use Azure File Sync:
   • Azure File Sync works over port 443, bypassing the need for port 445¹⁷.
   • It transforms your on-premises Windows Server into a cache for your Azure file share¹⁷.
2. Set up a VPN:
   • Establish a VPN connection to your specific Storage Account¹⁷.
   • This creates a secure tunnel, avoiding direct internet traffic.
3. Utilize REST API-based tools:
   • Azure Files supports REST access over port 443¹⁷.
   • Use tools like Storage Explorer or PowerShell for file operations¹⁷.
4. Implement Azure AD Kerberos authentication:
   • Allows users to connect to Azure Files over the internet without needing connectivity to domain controllers¹⁸.
5. Use third-party solutions:
   • Tools like MyWorkDrive enable remote access to Azure File shares without VPN or port 445¹⁹.
   • These solutions often provide web-based file managers, mobile apps, and mapped drive clients that work over HTTPS¹⁹.
6. Configure a Point-to-Site (P2S) VPN:
   • Set up a P2S VPN connection for each client that needs to connect²⁰.
   • This allows mounting Azure file shares over SMB without opening port 445²⁰.
7. For multiple clients, consider a Site-to-Site (S2S) VPN:
   • More efficient for connecting many clients from your on-premises network²⁰.

When implementing these solutions, ensure you also configure proper authentication and security measures, such as using Azure AD identities and setting up appropriate firewall rules for your storage account²⁰.

What if they can already access SMB shares that are on-prem? Then what are the implications for Azure File Share networking configuration needed?

If employees can already access on-premises SMB shares, it implies that their network environment is configured to allow SMB traffic. This configuration can simplify the process of accessing Azure File Shares. Here are the key implications and networking configurations needed:

1. Direct connection:
   • If port 445 is open for outbound traffic, users may be able to connect directly to Azure File Shares over the internet without additional networking configuration²¹.
   • This is the simplest scenario, requiring only proper authentication and firewall rules for the storage account.
2. VPN or ExpressRoute:
   • If the organization already has a Site-to-Site (S2S) VPN or ExpressRoute connection to Azure, it can be leveraged for Azure File Share access²².
   • This approach provides a secure tunnel between the on-premises network and Azure, bypassing potential internet-related issues.
3. Private endpoints:
   • Implementing private endpoints for the Azure storage account can enhance security and ensure that traffic doesn’t traverse the public internet²².
   • This configuration allows SMB traffic to flow through the existing VPN or ExpressRoute connection.
4. Azure AD authentication:
   • If the on-premises environment uses Active Directory, configuring Azure AD authentication for Azure Files can provide a seamless sign-on experience²³.
   • This requires setting up Azure AD Domain Services or syncing on-premises AD with Azure AD.
5. Firewall considerations:
   • Ensure that the Azure storage account’s firewall settings allow access from the on-premises network IP ranges²¹.
6. DNS configuration:
   • If using private endpoints, update DNS settings to resolve the Azure File Share FQDN to the private IP address²⁴.

By leveraging existing on-premises SMB access configurations, the transition to Azure File Shares can be relatively straightforward. The main focus should be on ensuring secure and efficient routing of traffic between the on-premises network and Azure, whether through direct internet connection, VPN, or ExpressRoute.