Autorest generates Client Sdk that needs a beta package - azure

Question

I use Autorest to generate a Client Sdk for an Azure Function.
After that the Client Sdk should be packed and pushed to our nuGet feed.
These steps will all be done with a yaml pipeline for Azure DevOps.
This works really good for the last months. But recently Autorest has stopped working as usual.
Unfortunately autorest generates a project file that needs a beta nuGet package.
<PackageReference Include="Microsoft.Azure.AutoRest.CSharp" Version="3.0.0-beta.20210205.2" />
Of course, nuGet pack is not able to pack a project with beta or pre-release dependencies.
Does anyone have the same issue with autorest?
Can i configure autorest, not to use beta packages?
The generated project file looks like this:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
<TreatWarningsAsErrors>true</TreatWarningsAsErrors>
<Nullable>annotations</Nullable>
</PropertyGroup>
<PropertyGroup>
<LangVersion>8.0</LangVersion>
<IncludeGeneratorSharedCode>true</IncludeGeneratorSharedCode>
<RestoreAdditionalProjectSources>https://azuresdkartifacts.blob.core.windows.net/azure-sdk-tools/index.json</RestoreAdditionalProjectSources>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.Azure.AutoRest.CSharp" Version="3.0.0-beta.20210205.2" />
</ItemGroup>
<ItemGroup>
<PackageReference Include="Azure.Core" Version="1.6.0" />
</ItemGroup>
</Project>
The Pipeline that generates, packs and push the Client Sdk looks like that:
steps:
- powershell: 'npm install -g autorest#latest'
displayName: "Install AutoRest"
- task: AzurePowerShell#4
displayName: "Download Swagger"
inputs:
azureSubscription: ${{parameters.subscription}}
scriptType: 'InlineScript'
azurePowerShellVersion: 'LatestVersion'
inline: |
$context = New-AzApiManagementContext -ResourceGroupName "${{parameters.apimResourceGroup}}" -ServiceName "${{parameters.apim}}"
Export-AzApiManagementApi -Context $context -ApiId "$(appName)-development" -SpecificationFormat OpenApi -SaveAs "$(Build.ArtifactStagingDirectory)\definition-$(version).yaml"
- powershell: 'autorest --verbose --v3 --csharp --add-credentials --input-file="$(Build.ArtifactStagingDirectory)\definition-$(version).yaml" --output-folder="$(Build.Repository.LocalPath)\Api\src\ClientSdk" --namespace="ClientSdk" --override-client-name="Client"'
displayName: 'Run AutoRest'
- task: DotNetCoreCLI#2
displayName: "Pack Projects"
inputs:
command: "pack"
arguments: "--configuration $(buildConfiguration) --include-symbols"
packagesToPack: "**/ClientSdk.csproj"
versioningScheme: "off"
verbosityPack: "Normal"
- task: DotNetCoreCLI#2
inputs:
command: 'push'
packagesToPush: '$(Pipeline.Workspace)/**/*.nupkg;!$(Pipeline.Workspace)/**/*.symbols.nupkg'
nuGetFeedType: 'internal'
publishVstsFeed: ${{parameters.nugetfeed}}
The nuGet pack task failes with this error
1>C:\Program Files\dotnet\sdk\5.0.102\Sdks\NuGet.Build.Tasks.Pack\build\NuGet.Build.Tasks.Pack.targets(207,5): error NU5104: A stable release of a package should not have a prerelease dependency. Either modify the version spec of dependency "Microsoft.Azure.AutoRest.CSharp [3.0.0-beta.20210205.2, )" or update the version field in the nuspec.

Answer 1

Using a pre-release package in a release package is unstable and dangerous. This error is there to prevent this from happening. There are a couple options you can employ:
Mark your package as pre-release
Assuming your project is still in development and needs to utilize this latest dependency that's still in development, simply mark your package as in development as well. From the Microsoft docs:
If your project uses PackageReference: include the semantic version
suffix in the .csproj file's PackageVersion element:
<PropertyGroup>
<PackageVersion>1.0.1-alpha</PackageVersion>
</PropertyGroup>
If your project has a packages.config file: include the semantic
version suffix in the .nuspec file's version element:
<version>1.0.1-alpha</version>
Use the last stable build
Fall back to the last version of your dependencies that use release packages. This is generally safer, as in-development dependencies may introduce serious issues that are yet unknown. If the project developers believed their project to be safe for production use they would mark it as such.