search

Azure / azure-sdk-for-net

This repository is for active development of the Azure SDK for .NET. For consumers of the SDK we recommend visiting our public developer docs at https://learn.microsoft.com/dotnet/azure/ or our versioned developer docs at https://azure.github.io/azure-sdk-for-net.
MIT License
5.49k stars 4.81k forks source link

AutoRest does not load the correct version of extension '@autorest/csharp' #35230

Open pshao25 opened 1 year ago

pshao25 commented 1 year ago

Repro steps:

  1. At any time of this repo, clean all the cache, for example at that time the Microsoft.Azure.AutoRest.CSharp version is 3.0.0-beta.20230328.2.
  2. Run dotnet msbuild /t:GenerateCode under an arbitrary project. The version autorest is loading should be 3.0.0-beta.20230328.2.
  3. Change the Microsoft.Azure.AutoRest.CSharp version to 3.0.0-beta.20230329.1.
  4. Run dotnet msbuild /t:GenerateCode again, you would see the Microsoft.Azure.AutoRest.CSharp version is still 3.0.0-beta.20230328.2 instead of 3.0.0-beta.20230329.1.

    info | Loading local AutoRest extension '@autorest/csharp' (C:/Users/pashao.FAREAST/.nuget/packages/microsoft.azure.autorest.csharp/3.0.0-beta.20230328.2/buildMultiTargeting/../tools/net6.0/any/)

Root cause: You could go to {RopoRoot}\artifacts\obj\Azure.Analytics.Synapse.Monitoring for example, there is a cache file project.nuget.cache. Its content is image

Suggestion: I suggest we add a dotnet restore to every autorest.md, otherwise user might generate incorrect code from out-of-date generator. image

jsquire commented 1 year ago

//cc: @m-nash, @heaths, @pallavit

m-nash commented 1 year ago

I think this is a common thing for many library dependency cache situations. If we wanted to fix this I would lean more towards having the cdoe generation target always run restore for the user so they don't need to run multiple commands.

pallavit commented 1 year ago

Is this issue more of a concern now than before due to all the activity happening in the autorest repo? As Michael said I would assume this is package caching concern which is usually diminished by backward compatibility. So, if you end up using an older package you generate older code but not necessarily incorrect code.

heaths commented 1 year ago

I agree with Michael. Solve this as low down the stack as possible by depending on the Restore target for GenerateCode. You might need to find some way to force it, though. Maybe. Given a <PackageReference> changed that may not be necessary.

If you fix it in some higher-level script, if and when someone calls the GenerateCode target themselves or another script is written for some other purpose, the problem will be apparent again and may be hard to diagnose for people who aren't as familiar with the system end-to-end.

pshao25 commented 1 year ago

Is this issue more of a concern now than before due to all the activity happening in the autorest repo? As Michael said I would assume this is package caching concern which is usually diminished by backward compatibility. So, if you end up using an older package you generate older code but not necessarily incorrect code.

I would rephrase as "user might generate unexpected code from out-of-date generator."