Skip to content

The type or namespace name 'ByteArray' could not be found #1278

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
patrick-insightly opened this issue Sep 22, 2015 · 10 comments
Closed

The type or namespace name 'ByteArray' could not be found #1278

patrick-insightly opened this issue Sep 22, 2015 · 10 comments

Comments

@patrick-insightly
Copy link

When trying to generate binary file upload code in C# based on swagger spec the file parameter type is set to ByteArray instead of byte[]. This breaks compilation.

@wing328
Copy link
Contributor

wing328 commented Sep 23, 2015

@patrickjrs For C#, file is mapped to "Stream": https://github.com/swagger-api/swagger-codegen/blob/master/modules/swagger-codegen/src/main/java/io/swagger/codegen/languages/CSharpClientCodegen.java#L75

Ae you using the latest version (master)?

Can you also share the spec with us?

@patrick-insightly
Copy link
Author

@wing328 Thanks for getting back to me. I grabbed the latest master version today. Our api is currently behind a VPN so cannot share it yet. For multipart/form-data requests the file parameter seems to be mapped to Stream. We also have straight binary uploads of files when no metadata is needed in the request, in this case we would write the file bytes to the body of the request. According to this PR it should work but maybe it's outdated already: swagger-api/swagger-core#1335
The parameter definition in the spec looks something like:
Parameter definition:
{
"name": "BinaryData",
"in": "body",
"required": true,
"schema": {
"type": "string",
"format": "binary"
}
}

@wing328
Copy link
Contributor

wing328 commented Sep 23, 2015

@patrickjrs format binary is introduced recently and it's not supported in C# codegen at the moment (from what I recall, it's only supported in Java API client).

To workaround the issue for the time being, what about using type file instead ?

@patrick-insightly
Copy link
Author

@wing328 If you plan to support it on C# client at some point I'd rather wait for that than change the current contract of our api, or could we use "file" without it generating a multipart/form-data request?

@wing328
Copy link
Contributor

wing328 commented Sep 25, 2015

@patrickjrs if file is the only argument in the body (no other form parameters), then the content-type should not be multipart/form-data.

@wing328
Copy link
Contributor

wing328 commented Sep 25, 2015

@patrickjrs sorry I was wrong. The API client would still use multipart/form-data even though only file is provided. e.g.

Content-Type: multipart/form-data; boundary=Boundary+6E729600B52DA40B

In your case, is it correct to say the server is expecting application/octct-stream?

@patrick-insightly
Copy link
Author

@wing328 Yes, that's correct, for this particular action the server expects application/octet-stream

@wing328
Copy link
Contributor

wing328 commented Sep 30, 2015

@patrickjrs I would like to get this support in the C# client but may not have time recently.

If you've some cycle to submit a PR to add the support of byte array in C# API client, I can work with you and give you some directions to begin with.

@wing328 wing328 modified the milestones: v2.1.5, v2.1.4 Oct 20, 2015
@fehguy fehguy modified the milestones: v2.1.5, v2.1.6 Jan 6, 2016
@wing328
Copy link
Contributor

wing328 commented Jan 11, 2016

@patrickjrs I've submitted #1864 to add "binary" support for C# client. I wonder if you can perform a test when you've time.

@wing328
Copy link
Contributor

wing328 commented Jan 12, 2016

PR merged into master. Closing this issue for the time being.

@wing328 wing328 closed this as completed Jan 12, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants