.NET 1.1 SP1 C# Compiler Changes = Breaking Changes?

In SP1, it seems the C# compiler reports the use of unassigned variables in situations that it did not before. 

We have an application that compiles assemblies at install time (and others dynamically).  The SP1 compiler throws errors now where the previous version did not.

We'll fix that, but my question is whether strengthening compiler rules in a service pack ought to be considered a breaking change? 

I know the rationale was that compiler changes won't break already compiled code.

However, our customers now need a patch from us because SP1 is --in many cases -- being automatically installed as a critical patch via Windows Update.  I don't see the compiler change as all that critical. Thoughts?

- EJ

Interesting, but surally the reporting of an unassigne variable only yeilds a warning not an error? I this is the case the service pack won't break an existing build, just report more warning that it used to. I think that this is an acceptable change to be introduced via a service pack.

Of course it might break you're build if you're using the treat warnings as error switch, but you can always turn that off. (Or just fix your code).

I agree that new warnings are probably not going to break code generators and we can of course fix the code we generate.

But in this case, the compiler throws an error -- not a warning. 

Also, since this change is delivered by a "critical Windows update", the customer is likely to suffer the break before we get them the fix.

Thanks for the reply.

- EJ

erik wrote:

I agree that new warnings are probably not going to break code generators and we can of course fix the code we generate.

But in this case, the compiler throws an error -- not a warning. 

Also, since this change is delivered by a "critical Windows update", the customer is likely to suffer the break before we get them the fix.

Thanks for the reply.

- EJ