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/
