raml-dotnet-tools icon indicating copy to clipboard operation
raml-dotnet-tools copied to clipboard

Problems with updated plugin

Open comaunite opened this issue 5 years ago • 5 comments
trafficstars

Hi,

Our team started experiencing issues with the RAML Tools for .NET VisualStudio plugin as of lately. We've upgraded to Visual Studio 2019 and hence, got the updated version of the plugin installed.

Our problem is that the plugin became very unusable. I'm spending so much time trying to fix the constant issues with the new version, and so far to no luck. It's now generating so much usless files and that makes it work super slow. Instead of neat 121 files I used to have for my contracts, I now have over 600 with all sorts of broken names.

To be more specific:

  • Every resource can return a slew of defined HTTP error code responses that are defined in common traits in RAML (400, 401, 500 for instance). So now plugin seems to generate a response object for each of those for every resource. Usually it's also encompassed into a Multiple* wrapper class. There seems to be no option to disable this.
  • Response class and filenames appear broken, generating such classes as Response1, Response2, etc. Those used to be generated based on their resource and RAML object name. There also seems to be no way to fix these object names, that I can find from studying the plugin source and template.

My team and I have now resolved to manually updating the .NET code based on the changes done in RAML, which can be very tedious. If the situation doesn't get better, we would likely have to move to some different solution than RAML, which is sad, because I really liked the convenience of it.

Could it somehow be improved? Could you somehow assist in solving these issues?

The MuleSoft design center platform doesn't detect the specs to be malformed in some way, in case there were some changes to RAML syntax, and it used to work with previous plugin versions (atleast versions of 2.1.*).

The support redirected me to post here. I can attach my RAML contract if needed.

comaunite avatar Apr 14 '20 10:04 comaunite

I also have lots of problems with the new version:

  • Like comaunite said, with the new version, now when you have an invalid RAML, the tool will not prompt the error messages and instead just keep silent. This is very inconvenient as we don't know how to troubleshoot the issues if we don't know what they are.
  • If we have the "uses" statement, e.g.: uses: Response: types/response-types.raml Request: types/request-types.raml The old version will add a prefix "Request" or "Response" into the name of the generated model class. The new version no longer does so.
  • The naming of user defined type seems to be... random, e.g.:

RespType1: properties: Field1: string Field2: string RespType2: properties: NewField: ResponseType1

I would expect a new model called ResponseType1.cs is generated. But it's not always the case. Depending on the order the tool processes the types, if the tool decides to process RespType2 first then the model file being generated will be NewField.cs instead, which does not make sense at all

All above issues are quite significant and thus make the tool unusable for us too. We are thinking of sticking with the old version (2.1.2) but it does not work with VS2019. Does anyone know where we can get the source code of the old version so that we can upgrade it to work with VS2019? The current GitHub repo seems to be for new one only

huubang avatar May 18 '20 06:05 huubang

I would very much love being able to install the 2.1.2 version in VS2019 and run that. It would just solve all my problems, I can easily work around its limitations. Currently we just had to disable the plugin and we're fixing the 2 contracts (one in documentation, and one that is the "imported" version that is inside the .NET project) manually, and the contract code manually. Something that often causes some errors and consumes a lot of time in case a big chunk needs to be added to the contract.

comaunite avatar May 18 '20 06:05 comaunite

We can easily make the old version work if we still have the source code. Unfortunately 2.1.2 was around year 2016 and I could not find the repository any more. Any idea where we can still grab the old one?

huubang avatar May 18 '20 06:05 huubang

Any update on this? We've just started down a mulesoft implementation and it appears, using visual studio 2019, the generated code doesn't seem to match the RAML spec

NelsonLamprecht avatar Sep 14 '20 22:09 NelsonLamprecht

Was anyone able to fix this?

comaunite avatar Jan 18 '21 04:01 comaunite