* [csharp] this.Configuration in api template
Unprefixed Configuration property access leads to ambiguous references
when spec defines a Configuration model.
* [csharp] Regenerate samples
* [csharp] Convert "false" properties to booleans
It appears as though "false" strings in additionalProperties are no
longer treated as false booleans. This may be an issue elsewhere, but a
simple fix is to always explicitly set the boolean value in a generator
class back to the additionalProperties map to convert boolean Strings to
boolean Objects.
* [nancyfx] Clean up async default option handling
* [nancyfx] Include asyncServer=false in sample script
* [csharp] Regenerate samples
* [csharp] Resolve .net 4 generation issues
Some functionality is missing from .NET 4.0, such as IReadonlyDictionary
and Type.GetTypeInfo().
This commit resolves compilation of generated .NET 4.0 code, requiring
no conditional versioning of Newtonsoft.Json.
* [csharp] Regenerate .net 4.0 sample
* [csharp] Resolve .NET 4.0 sample compile
Sample build.sh wasn't accounting for targeting different FCL correctly.
That is, when passing "net40" to the -sdk option, it would use the
default -sdk:4 and -langversion:6. These don't necessarily match with
what is installed on a machine with only .NET 4.0 (which is our targeted
use case here).
To resolve, we need to define another version-specific value for passing
to the mcs -sdk option (see man mcs for details).
This option currently isn't overridable in the client codegen class.
Also, langversion is set specifically to the version of C# available to
the targeted SDK version. If there is need, we may extend this to
something like:
langversion=${MCS_LANG_VERSION:-6}
To allow users to run as:
env MCS_LANG_VERSION=5 sh build.sh
I haven't done this because I doubt there's much of a use case via this
script. I'm assuming most consumers will build via IDE or MSBuild.
* [csharp] Revert bin/csharp-petstore.sh to 3.5
* [csharp] Regenerate .NET 3.5 sample
* [csharp] Resolve nuget issue with existing files
* [csharp] Update -all.sh, regenerate samples
When a spec defines a Model at the top level that is a non-aggretate type (such
as string, number or boolean), it essentially represents an alias for the simple
type. For example, the following spec snippet creates an alias of the boolean
type that for all intents and purposes acts just like a regular boolean.
definitions:
JustABoolean:
type: boolean
This can be modeled in some languages through built-in mechanisms, such as
typedefs in C++. Java, however, just not have a clean way of representing this.
This change introduces an internal mechanism for representing aliases. It
maintains a map in DefaultCodegen that tracks these types of definitions, and
wherever it sees the "JustABoolean" type in the spec, it generates code that
uses the built-in "Boolean" instead.
This functionality currenlty only applies to Java, but could be extended to
other languages later.
The change adds a few examples of this to the fake endpoint spec for testing,
which means all of the samples change as well.
* Updating samples after #5232.
* Fix tests after #5232.
* Fix Javascript client tests.
* JaxRS server: set serverPort only when not given from outside.
* Update JaxRS sample creator scripts to fix serverPort.
* Preliminary test fix for JaxRS server generators.
* Updating samples for JaxRS with Jersey1/2.
* Updating JaxRS samples again.
* [csharp] Fix apiPackage,modelPackage,excludeTests
The apiPackage, modelPackage, and excludeTests values were not being
populated correctly from external configs (passing -c filename to
generator).
This commit allows those properties to work correctly with the Csharp
client generator. Previously the Api and Model namespaces were hard
coded after additionalProperties for these were evaluated.
The files which generate test files for models and api classes
didn't honor the excludeTests option.
* [csharp] Regenerate sample
* [csharp] Fix modelPackage in README template
Aligns C# project outputs more with community accepted standards and
leverges Nuget for package management.
This also moves the generated C# sample code out of the test project's
Lib folder. The output structure here was causing some issues with
maintainability (e.g. had to update test project with generated code).
(see: https://gist.github.com/davidfowl/ed7564297c61fe9ab814)
Output for a project, IO.Swagger will now look like:
.
├── IO.Swagger.sln
├── README.md
├── bin
├── build.bat
├── build.sh
├── docs
├── packages
└── src
├── IO.Swagger
│ └── packages.config
└── IO.Swagger.Test
└── packages.config
This is a change from the Java-like src/main/csharp/IO/Swagger/etc
structure and will be a breaking change for some.
