Seems a bit of a shame to me that they didn't include unsigned types in the CLS. Could be just pass unsinged bytes as shorts and so on, like we will have to do in the Java code? Not a very elegant solution, I know.
On 2/27/07, Tomas Restrepo <[EMAIL PROTECTED]> wrote:
Hi Rupert, > > Tomas, when I built this using the build-dotnet11 script it complained > > (with an error not just a warning), that exposing an unsigned byte in > > a public API would make the library non-CLS compliant. So I commented > > out the Get/SetSByte method declarations in IHeaders for the moment. > > Do you think that we should be trying to keep CLS compliance? > > That's a good question. I think it's important, but we don't necessarily > need to force it. We should be able to explicitly mark any problem members > with a [CLSCompliant(false)] attribute so they don't cause trouble. I'll > see > about it and update the patch accordingly (and probably run it through > FxCop > and see what comes up). Tool a new look at this and indeed this is going to be a bit of a problem. The issue here is that IHeaders is an interface, so you can't selectively mark members as "Non CLS Compliant", like you can with a class. The reason for this is that the compiler assumes you might want to implement said interface in a language only supporting the CLS. This is obviously not our case, but marking the entire interface Non-CLS compliant might have other consequences for users of the interface (i.e. client applications that reference the message headers), so I'm not too keen on that. There might be a way to get around it, I think, by breaking up the interface in two (one base CLS compliant, like we have now, and another one that inherits it with all the Non-CLS compliant members, like GetSByte() and the like). I'll check it out tonight. I'll also fix a few FxCop warnings (can't get rid of all unfortunately) in Qpid.Buffers. Tomas Restrepo [EMAIL PROTECTED] http://www.winterdom.com/weblog/
