Our application is currently set to CLSCompliant(true), which causes hundreds of warnings due to StrataFrame. Is there a compelling reason why StrataFrame is not CLS compliant? It would seem as a framework vendor, this would be desirable.



Thanks,

Derek

Derek, this is a very difficult and ambiguous statement to answer.  CLSCompliant means that you are most likely creating a COM class that can be used to  support disparate systems.  We do this ourselves and have even added some CLSCompliant overloads in the framework where this is necessary.  BUt let's look at it like this, if evey method and overload in the system was CLSCompliant, then we may as well not be programming in .NET.  Let me elaborate.  Let's assume that we create the following method:

This method has no hope of ever being CLS Compliant as no other disparate interface is going to know how to treat the BusinessLayer reference here.  The closest that you could hope for would be to type this as an Object...thus 100% elimiating strong-typing and introducing a whole different set of issues.

We never claimed nor will ever claim to be 100% CLS Compliant because that would vastly limit and hobble the future of the framework.

Now, we create COM classes all of the time that are called from disparate systems.  But when we do this, we create a single entry point and make THAT assembly CLS compliant for the methods that are going to be exposed.  This is YOUR responsibility (or mine when I am writing application code) to make my application CLS compliant.  So would create a class that interfaces with the disparate class like this:

This method is CLS compliant and will aide you in your external applications accessing this method with no CLSCompliant violations.  If you want to create a CLS Compliant interface, this is going to have to be the responsiblity of the developer, not the framework.  If we made SF 100% CLS Compliant, then it would be virtually useless as all strong-typing, generics, etc. would not be able to be exposed in a public (or inherited Proteceted) sense.  It is designed in this capacity as it should be.

Hope this explanation helps.

Hi Trent,



Thanks for the update. I don't believe that CLS Compliance is strictly COM-related only. I've read articles on this by people far smarter than me and they do mention the COM-related issues, but seem to stress just general compatibility with other languages.



Interestingly enough, one of our developers re-compiled the StrataFrame source code with CLS Compliant set to true and there were no builds errors, although there were a few extra warnings. I guess we were expecting build errors related to this based on your explanation above. So just out of curiosity, if we can compile your source code with no errors, why wouldn't you just enable this in yours?



Thanks,

Derek

It's not, it forces compatability to generic or primitive types to provide low level compatability with disparate systems.  COM is the most common reason that you would need to do this.  If you are trying to implement CLS compliance for .NET to .NET interfaces, then there is absolutely no need for CLS compliance in this regard as you can add .NET references and would have strong-typed access to the classes and implementations as a whole.

This might make some of the errors go away but there is no guarantee that you have resolved all of the issues.  To make the framework fully CLS compliant, which as I have already told you in my previous post would ultimately require that we "weaken" the flexibility of the framework, then it would require a number of downstream changes.  Though your errors have gone away, you could experience some downstream effects.  If you truly are interested in making a CLS compliant interface, then the absolute last thing that you should do is change the SF source code.  This will put you out on an island and you will begin to drift away from the heart of the framework and the changes that get released.

I you want to create a CLS compliant interface, then you need to create wrappers, just as I mentioned before.  Slapping a CLSCompliant attribute on some things will not fix all of your problems (even though it may compile).  You should take a more pur CLS approach and create the wrapper that interfaces with the framework properly.

We will not be changing the framework in this regard.   As I have already mentioned, it will ultimately "weaken" the flexibility of the framework and how it interfaces with .NET, as it was intended.  Creating CLS compliance generally indicates that you are trying to use .NET code outside of .NET.  Well, StrataFrame is a .NET framework and that it what it is intended to be used with.  I hope this helps you understand our perspective and how CLS compliance works in regards to making changes to our framework.