Ambiguous reference error in OpenApi-generated c# code - c#

I'm using OpenAPI Generator to generate client libraries for my c# API. I am having issues generating a c# client, because one of my models is called Environment. The generated service code to manipulate this model causes the build of the project to fail because it is an ambiguous reference between it's own model and .Net's System.Environment.
The exact error I'm seeing is
Api/EnvironmentApi.cs(87,42): error CS0104: 'Environment' is an ambiguous reference between 'MyProject.Model.Environment' and 'System.Environment'
Is there some way to tell openapi-generator to fully-qualify the class names in the generated code so that it won't clash? i.e. so it generates something like
DoSomething<MyProject.Model.Environment>(...) instead of DoSomething<Environment>(...)

It's been a while since the request was opened for swagger: https://github.com/swagger-api/swagger-codegen/issues/2630
Bear in mind that I'm referring swagger as it is the project that was forked to make openapi generator.
https://github.com/OpenAPITools/openapi-generator/blob/master/docs/migration-from-swagger-codegen.md#new-fully-qualified-name-for-the-classes
OpenAPI Generator is a fork of swagger-codegen between version 2.3.1 and 2.4.0
So the answer is most probably no.

Related

Nullable reference types in swashbuckle cli and nswag in .net

I'm using dotnet swagger cli to make a swagger definition file for an ASP.NET 5.0 web api, and using nswag to generate C# client classes, but I've run into a snag. I want all my reference types to be nullable, unless they're marked with Required. For my primitive fields it just follows C# convetions whether it's nullable or not, but my references don't get marked with nullable:true in the swagger definition.
I've tried serializing as V2 instead, but then it just makes everything nullable, which I also don't want.
I'm using the following CLI command right now:
dotnet swagger tofile --serializeasv2 --output $(MSBuildProjectDirectory)\nswag\swagger.json project.dll v1" ConsoleToMSBuild="true" WorkingDirectory="$(OutputPath)"
Well, I don't know how to implement exactly the behavior you've mentioned.
Would it suffice to have nullable properties in API project staying the same(nullable) in generated code?
To do so, you can add this into you API project
services.AddSwaggerGen(c =>
{
c.UseAllOfToExtendReferenceSchemas();
and then enable the following option in NSwag generator: generateNullableReferenceTypes=true.
This option looks like "Generate Nullable Reference Type..." in "DTO Classes" section in NswagStudio UI.
I think this approach should also work with swagger cli

ILMerge into nuget package causing issue with Parameter Type Mismatch with consuming project

I have a service dll, which has a reference to System.Web.OData (from Microsoft.AspNet.OData.5.9.0)
The service dll has an exposed method which takes in an OData.Delta<>
This service dll when compiled is ilmerged, so it has this "version" of Data embedded.
Now the consuming application, also has a reference to the same OData, however, it comes from a corext, globalized cache.
However, when the consuming application, attempts to call the method that has an OData.Delta<> parameter, it complains that it cannot convert from ConsumingApp.OData.Delta to ServiceDll.OData.Delta.
How would I go about making sure that the parameter uses the actual proper "version" of OData.Delta so that they do not conflict?
I can't seem to find like.. a NameSpace.For.ServiceDll that would enable me to specifically target the OData.Delta that is embedded in the ilmerge
you have to install ms odata client for visual studio create a new odata client class, an add in http uri metadata de correct http. After that click on the file and run custom tool option download de latest metadata
Sorry I understood that had problems with odata schema. The error you expose, if I understood well you are using ilmerge for combine various project and reference again the library combined. I think:
you can add the namespace with a surname, for example:
import reference1 = microsoft.data;
import reference2 = ilmerge...;
so you can use them in code like reference1.class1 and reference2.class1
Hope this help you

wcf service reference code generation

i have few project that use the same wcf service, my asp.net and test project are working fine
with the wcf service i add.
my new project in mvc asp.net also added the wcf reference , all of those project reuse
the assemblies.
when there was compiler error with the types i saw difference in the reference.cs file and
the order that visual studio generate the code wasn't the same.
// CODEGEN: Parameter 'GetLookupTablesResult' requires additional schema information that cannot be captured using the parameter mode. The specific attribute is 'System.Xml.Serialization.XmlElementAttribute'.
this is the working one:
Runtime Version:4.0.30319.18063
this one not generate :
Runtime Version:4.0.30319.18444
why there is difference ? is it something in the solution settings?

"Missing compiler required member" error being thrown multiple times with almost no changes to code

Today after deploying some changes to a C# MVC site that I run, I went back to make some more modifications and came across this error:
Missing compiler required member System.Runtime.CompilerServices.ExtensionAttribute..ctor
The error is a bit vague (other than it's description, obviously) as it doesn't give me a file, line, or column to reference, only the project. Also, it throws the error a total of 20 times. I only made three changes to the code between the time I deployed (it was completely functional at that time) and now. I reverted my changes and it is still throwing the same error which makes no sense to me.
I haven't found a lot of information on this error on SO or Google, other than this guys solution and a couple references to some Mono project errors (I'm not using Mono). The solution the guy above gives requires adding a class definition that will allow the compiler to resolve the reference. I don't particularly want to do this because I haven't needed to do it up until this point and it will just muddy my code.
Just curious if anyone has run across this before.
In my case it was because the project was not referencing Microsoft.CSharp. Once I added a reference to that assembly, it compiled just fine.
I don't know if anyone else has experienced this, but I suddenly ran into this error after adding some code utilizing dynamic types and incorporating WebAPI into a project that originated as a TypeScript application in VS2013. Simply adding a reference to Microsoft.CSharp resolved my issue.
Hope this helps someone else.
This error usually means either your project is compiling against .NET 2.0 or you aren't referencing the correct version of System.Core.dll
For a near duplicate question, see Error when using extension methods in C#
I ran into this situation as well today. In my case I was referencing the Newton.Json.Net dll v3.5 in my .NET 4.0 application. I realized that I wasnt even using this library, thus once I removed it from my references, it no longer gave me the compiler error.
Problem solved!!!
The actual error comes from the fact that your 2.0 assembly that causes the error contains this code:
namespace System.Runtime.CompilerServices
{
public class ExtensionAttribute : Attribute { }
}
The Code Above allows the .NET 2.0 Assembly to use extension methods (see Using extension methods in .NET 2.0?). While it confuses the compiler if you target .NET 4.0 and reference a 2.0 Assembly (containing above code) as the mscorlib.dll(4.0) contains the same class in the same namespace.
I fixed this
by compiling the original 2.0 assembly again without the attribute targeting 4.0
by removing the assembly (obviously)
by adding a third Extension Attribute in the target you compile (it seems to overrule the referenced definitions)
Writing this code somewhere in your project may solve your problem. It works for me
namespace System.Runtime.CompilerServices
{
public class ExtensionAttribute : Attribute { }
}
Probably you use dynamic keyword In .NetStandard Class library project. If so, you need to add a reference to Microsoft.CSharp library in the project. Hope it will resolve your problem.
NLog.dll 2.0 referenced from a .NET 4.0 project can cause this too.
I don't have a correct solution, but I'll add my data point:
In my case the error is caused by referencing GoogleSearchAPINet20
Here is what happens:
I close the solution that builds
I open the solution again. It still builds
As soon as I make any change and try to build, I get 19 "Missing compiler required member ..." errors
I remove the reference to GoogleSearchAPINet20
I add back the reference to GoogleSearchAPINet20
I build the solution. It builds without errors
I can now make code changes, build or perform any other actions with solution correctly as long as my Visual Studio is open
I close Visual Studio
Repeat from step one
I'm not referencing System.Core.dll in my solution at all and my target framework is .NET 4.
I'm a bit annoyed at this point ...
Got this error when trying to use async Tasks against .NET 4.0. Updating Target Framework to 4.5.2 fixed the problem.
I hit the same set of exceptions after I added some async methods to a winforms project. I needed to bump my .NET version from 4 to 4.5
For me, the problem occure when I add asynchronous method with async Task await in my .net4.0 project !
With previous versions of the .NET-Framework 4.5, you must install this package:
Install-package Microsoft.Bcl.Async –pre
or
Install-Package Microsoft.CompilerServices.AsyncTargetingPack
more info on Nuget or Nuget

Service Reference Error: Failed to generate code for the service reference

I have a Windows Service Solution and am trying to add a service reference to a Hermes(Opensource ebms message server) Web Service in VS2010.
I can find the Web Service using it's URL, but when I try and populate the Service reference I get the following errors in Visual Studio:
Error 8 Custom tool error: Failed to generate code for the service reference 'testService'. Please check other error and warning messages for details. C:\Users\Admin\documents\visual studio 2010\Projects\MyProject\MyProject.MessageHandler\Service References\testService\Reference.svcmap 1 1 MyProject.MessageHandler
Warning 6 Custom tool warning: Cannot import wsdl:binding
Detail: There was an error importing a wsdl:portType that the wsdl:binding is dependent on.
XPath to wsdl:portType: //wsdl:definitions[#targetNamespace='http://service.ebms.edi.cecid.hku.hk/']/wsdl:portType[#name='EbmsStatusQuery']
XPath to Error Source: //wsdl:definitions[#targetNamespace='http://service.ebms.edi.cecid.hku.hk/']/wsdl:binding[#name='EbmsSoapHttpStatusQuery'] C:\Users\Admin\documents\visual studio 2010\Projects\MyProject\MyProject.MessageHandler\Service References\testService\Reference.svcmap 1 1 MyProject.MessageHandler
Warning 7 Custom tool warning: Cannot import wsdl:port
Detail: There was an error importing a wsdl:binding that the wsdl:port is dependent on.
XPath to wsdl:binding: //wsdl:definitions[#targetNamespace='http://service.ebms.edi.cecid.hku.hk/']/wsdl:binding[#name='EbmsSoapHttpStatusQuery']
XPath to Error Source: //wsdl:definitions[#targetNamespace='http://service.ebms.edi.cecid.hku.hk/']/wsdl:service[#name='EbmsMessageStatusQuery']/wsdl:port[#name='EbmsStatusQuery'] C:\Users\Admin\documents\visual studio 2010\Projects\MyProject\MyProject.MessageHandler\Service References\testService\Reference.svcmap 1 1 MyProject.MessageHandler
Warning 5 Custom tool warning: Cannot import wsdl:portType
Detail: An exception was thrown while running a WSDL import extension: System.ServiceModel.Description.XmlSerializerMessageContractImporter
Error: Schema with target namespace 'http://service.ebms.edi.cecid.hku.hk/' could not be found.
XPath to Error Source: //wsdl:definitions[#targetNamespace='http://service.ebms.edi.cecid.hku.hk/']/wsdl:portType[#name='EbmsStatusQuery'] C:\Users\Admin\documents\visual studio 2010\Projects\MyProject\MyProject.MessageHandler\Service References\testService\Reference.svcmap 1 1 MyProject.MessageHandler
Some investigation seemed to suggest it is due to svcutil.exe not been able to build the proxys due to not having permissions to a directory (possibly c:\windows\temp). I have tried assigning various access permissions, but I am not really sure which user needs the permission, or if it is just a red herring.
Any ideas would be greatly appreciated.
Thanks
Have to uncheck the Reuse types in all referenced assemblies from Configure service reference option
Check this for details
Right click on your service reference and choose Configure Service Reference...
Then uncheck Reuse types in referenced assemblies
Click OK, clean and rebuild your solution.
I also encountered a similar error when trying to generate the client for a web service from an ASP .Net MVC 4.0 project using Visual Studio 2012.
The root of the problem seems to be that fact that the project from where I was trying to generate the client was referencing an assembly which in turn was dependent on another assembly that was not being referenced as well.
When "Reuse types in referenced assemblies" is enabled in the service configuration, the service generator is probably inspecting all the referenced assemblies to get a list of types that can be reused. The fact that one of the referenced assemblies is referencing another assembly which is not available is probably causing the generator to fail.
Unchecking "Reuse types in referenced assemblies" from the service configurations will solve the above problem, but there is a side effect to it. The reuse types option is there for a reason and in some cases it avoids unnecessary casting in the code consuming the service.
For example, if the service itself is built using WCF and some methods parameters inside it are of type System.Guid, they will be translated to strings in the generated client if the reuse types option is disabled.
An alternative that I prefer to disabling reusing types is to add the service reference from Class Library project specifically created for that purpose. The one thing to keep in mind is to copy all the service related configurations from the class library's app.config to the configuration file of the startup project.
If there are types defined in local assemblies that need to be reused in the service client, those assemblies simply need to be referenced from the above mentioned class library project, along with all their dependencies.
http://uliasz.com/2011/06/wcf-custom-tool-error-failed-to-generate-code-for-the-service-reference/#comment-1647
Thanks to the article above.
In my case, i have this issue with my WPF project in VS.Net 2008. After going through this article, i was realizing that the assembly used in the web service is different version of assembly used on client.
It works just fine after updating the assembly on the client.
It would be extremely difficult to guess the problem since it is due to a an error in the WSDL and without examining the WSDL, I cannot comment much more. So if you can share your WSDL, please do so.
All I can say is that there seems to be a missing schema in the WSDL (with the target namespace 'http://service.ebms.edi.cecid.hku.hk/'). I know about issues and different handling of the schema when include instructions are ignored.
Generally I have found Microsoft's implementation of web services pretty good so I think the web service is sending back dodgy WSDL.
Restarting Visual Studio did the trick for me. I am using VS 2015.
I get the same error in Silverlight 5 (VS2012)
You can also remove the references to:
System.ServiceModel.DomainServices.Client
System.ServiceModel.DomainServices.Client.Web
After you've updated the service references, be sure to add them back in.
As stated above, there are a couple of different problems possible. What we found is that the .DLL for the WCF library had been added as a reference to the client project. This, in turn, created problems with resolving the objects and thus caused the files to be "emptied" by code generation steps. While unchecking the use "Reuse Types..." can seem like an answer, it creates extra definitions of object types, which are proxies to the real types, in a new name space, which then causes all kinds of "compatibility" issues with the use of those types. Only if you really want to "hide" a type should you check this option.
Hiding the type would be appropriate when you don't want a "DLL" type dependency to "leak" into a project that you are trying to keep segregated from another. If the DLL for the WCF library project creeps into the client project references, then you will have this problem with all kinds of strange side effects since the type definitions are also in the DLL.
face same issue, resolved by running Visual Studio in Admin mode
I have encountered this problem when upgrading a VS2010 WCF+Silverlight solution in VS2015 Professional. Besides automatically upgrading from Silverlight 4 to Silverlight 5, the service reference reuse checkbox value was changed and generation failed.
"Reuse types" is not always the problem when this error occurs.
When adding a reference to an older service, click 'advanced' and there 'Add Web Reference'. Now link to your wsdl and everything should be working.
If you want to correct this without uncheking the assembly reuse checkbox this is what worked for me:
Remove referenced assembly that you want to re-use
Delete all the bin folder of the project
Update service reference
Keep "Reuse types in specified referenced assemblies"
Add reference to assembly again to fix the errors
Update service reference again
I had this problem when trying to update my service reference (The error only shows up when adding a service reference though) but didn't want to remove the assembly reuse checkbox.
What worked for me was the following:
Remove referenced assembly that I wanted to re-use
Update service reference
Keep "Reuse types in specified referenced assemblies"
Ignore the errors, it's because the reference is missing!
Add reference to assembly again to fix the errors
Update service reference again
Voila, now it actually updates and doesn't try to remove all of my generated code anymore.
I was almost ready to give up on the re-use types feature...
EDIT: Also make sure that the build config is AnyCPU or x86, since svcutil is buggy with x64.
To the downvoter: Sorry if it didn't work for you, I don't even know why it worked for me, but it did. I may have done something else that time that fixed the problem, but no way to know now.

Categories

Resources