search

Azure / autorest.csharp

Extension for AutoRest (https://github.com/Azure/autorest) that generates C# code
MIT License
143 stars 165 forks source link

All I want to do is generate a client for ASP.NET MVC (not .NET Core) #1188

Open dsynclabsllc opened 3 years ago

dsynclabsllc commented 3 years ago

This is extremely frustrating. All I want to do is find a way to generate a client that does not require you to import the azure core libraries, which only seem to work for .NET Core. This used to work just fine. I would generate a client that depended upon the microsoft rest client runtime nuget package and all was well. Now after spending several hours on it, trying different combinations of using --legacy, --v2, switching the open API spec version to v2 instead of v3, etc. - nothing will generate a client that is compatible with the .NET Framework 4.8. This should not be that complicated, but yet, here we are.

timotheeguerin commented 3 years ago

CSharp generator got updated to use v3 recently(which uses the Azure.Core libraries as you saw). For the old version you should use autorest readme.md --csharp --v2 what error do you get when using this?

dsynclabsllc commented 3 years ago

Well I tried to use --v2 --legacy. That did generate a client, but it still depended upon the azure libraries. I will try it again.

timotheeguerin commented 3 years ago

Also just asked around and the Azure.Core libraries are suppsoed to work with dotnet and dotnetcore. https://docs.microsoft.com/en-us/dotnet/azure/intro#access-azure-services-from-net-applications If you are having issue with this you should open an issue in their repo https://github.com/Azure/azure-sdk-for-net/blob/Azure.Core_1.13.0/sdk/core/Azure.Core/README.md

dsynclabsllc commented 3 years ago

Well, apparently running --v2 without --legacy made the difference. But running --v2 doesn't let me consume the Open API v3 swagger, so that won't work. I appreciate the help so far.

If I follow the same steps to generate a client in .NET Core 3.0, the shared folder never appears in the Visual Studio and I cannot find the nuget package Microsoft.Azure.AutoRest.CSharp (even if I manually search for it). image

If I try to use a .NET Standard library, targeting 2.0, then I get language incompatibility errors during project build: image

timotheeguerin commented 3 years ago

so the error just seems to be an issue with not using csharp 8 and not with the version of dotnet. Can you change LangVersion to <LangVersion>8.0</LangVersion>?

For the Microsoft.Azure.AutoRest.CSharp package I am not really sure what this package is, what are you expecting from it?

dsynclabsllc commented 3 years ago

Well, putting in the 8.0 into the ASP.NET MVC csproj did make those errors go away. But now I have the same errors I was met with when I first tried generating a client for a .NET Core console app. Please see below. image

To fix this in .NET Core, I had to make a few changes to the csproj file:

Important to note: just simply adding in the two properties above to the csproj file did not let the project compile (I tried to see if that would be sufficient) and the "Shared" folder did not appear in the project. I had to also add in the CSharp package - only then would the Shared folder appear. I also tried to omit those two properties and simply add the CSharp package to the csproj, which also was not sufficient. I had to add the properties, then add the package reference, only then did the Shared folder appear, the CSharp package was able to finally be restored into the project, and finally the .NET Core project would compile with no errors.

For the Non-.NET Core, ASP.NET project (and with the language errors out of the way), I have repeated the same steps mentioned above. But doing all of the steps I mentioned never makes the Shared folder appear, which is probably why I can't install the Microsoft.Azure.AutoRest.CSharp package via nuget package manager (with All listed as the source) or via the package manager console. I get the standard "cannot find this package" error message. Install-Package : Package 'Microsoft.Azure.AutoRest.CSharp 3.0.0-beta.20210311.1' is not found in the following primary source(s): 'https://api.nuget.org/v3/index.json,https://azuredevops.mysite.net/SomeCollection/_packaging/SomeInternalFeed/nuget/v3/index.json,C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\'. Please verify all your online package sources are available (OR) package id, version are specified correctly.

I'm guessing that I am getting this error because the two csproj properties that make the magic happen in .NET core, don't do anything for a non.net core project.

timotheeguerin commented 3 years ago

I am not sure what the issue is here, transferring to the autorest.csharp repo where they might know what is going on and what you are missing.

dsynclabsllc commented 3 years ago

Thanks for all of your help and for transferring to the right area. Hopefully they know what is messed up here. Autorest.CSharp team... waiting for your insight.

chamons commented 3 years ago

We have some documentation here, in particular here which contains instructions on using v3 outside of azure-sdk-for-net.

The protection level issues suggest you need to either use public-clients or need to wrap it in a "convenience layer" similar to this.

chamons commented 3 years ago

If you want more specific help, we'd need an attached project showing configuration and setup information.

ghost commented 3 years ago

Hi, we're sending this friendly reminder because we haven't heard back from you in 7 days. We need more information about this issue to help address it. Please be sure to give us your input. If we don't hear back from you within 14 days of this comment the issue will be automatically closed. Thank you!

MichaCo commented 3 years ago

Having the same problems with the "new" v3 of the csharp generator of autorest.

Tried autorest --use:@autorest/csharp@3.0.0-beta.20210210.4 --input-file:http://localhost:5300/swagger/v1/swagger.json --clear-output-folder:true --output-folder:client

as mentioned in the documentation

and

autorest --input-file:http://localhost:5300/swagger/v1/swagger.json --clear-output-folder:true --output-folder:client --v3 --csharp --add-credentials

Both generates some stuff which then doesn't compile

First of all, its an absolute horrible experience that your csproj file gets rewritten. Have never seen something like that, ever. Then, it references something which cannot be resolved / restored

    <PackageReference Include="Microsoft.Azure.AutoRest.CSharp" Version="3.0.0-beta.20210610.3" PrivateAssets="All" />

So even if I put everything into a new project and let it rewrite the csproj, it doesn't work in the end. Probably this sits on some nuget feed other than nuget.org?

Beta packages, not published - how am I supposed to use this in soon production like projects?? When will this be out of beta?

This is a huge waste of time right now, so, I'm just getting frustrated with this and probably giving up. I cannot use v3 because its just not usable, and v2 doesn't produce code for the OpenApi 3 specs. I guess I have to find another tooling chain and switch 50+ projects to use that ~~

More questions, just to share the fun:

:edit: sorry for the tone, I was a bit frustrated yesterday ;)

dsynclabsllc commented 3 years ago

I also noticed that about the override client name forcing the Rest suffix, which was annoying. Don't tell me how to name my clients. That override option is there for a reason. There really is no reason to attach a project to this. Simply create an ASP.NET 4 MVC application in Visual Studio and try to use the new generators. You will not be able to do it. Adding the restore additional project source and include generator shared code elements to your csproj file will do nothing.

A side note, having to add those elements to your project is ridiculous. Everything should be wrapped up in a public nuget package that I can easily consume via the package manager. Forcing people to modify their csproj file increases complexity when it comes to automation tasks and it is just unnecessary. Also, it doesn't support ASP.NET MVC 4 projects.

Oh and once you do finally figure out the csproj settings required to bring in the dependencies, you STILL cannot simply new up a client instance and use it, because you will find that the constructor complains about not having a diagnostics class, with an options class. You can't create these directly, as they are abstract classes. So you have to create useless child classes that inherit from the diagnostics and options classes, passing those in. All around, using the new generator was just a terrible experience. It has made me avoid using autorest in future endeavors.

I don't understand what is going on with Microsoft these days. They keep making these terrible framework decisions. For fun, look up how to build an azure web extension and then try to build a simple, yet useful web extension (like a hub). You will start to see a trend. Maybe it's like The Big Bang Theory, where Sheldon is just so smart, that no one understands him. I definitely don't understand the thinking behind the new generator implementations.

Ok I am done ranting now. That was a lot to write. There are probably lots of grammatical errors, but I have to move on with my work day.

ericbrumfield commented 2 years ago

I've run into the same issues and am now faced with having to switch out tooling like @micha_conrad. In projects I have to maintain, I use autorest for generating c#/.net core libs and leverage the same openapi v3 files on mobile app sides for typescript client generation using other tooling. I know it's not autorest's problem in parts for the other tooling, but it's a real mess trying to generate these client proxies for v3 off the same openapi file, the tooling pulls people in many different directions.

What used to work pretty easily on the c# side no longer does for autorest and I'm likely going to abandon using it moving forward in the future. This path is currently not working at all