A question about classes / enumerated types/ best practice etc..

[AtW]

But if you strong name single DLL that you release as a patch - would that take care of the issue or not?

[ASB]

But if you strong name single DLL that you release as a patch - would that take care of the issue or not?

Don't know. I wasn't trying to start a quiz

The situation is really simple. Compiling assembly B embeds the compile time values of public constants of assembly A into B. Deploy a new version of Assembly A (which is a valid thing to do). Oops, assembly A does not use the new "constant" values.

Now, if the assembly is strong named then one of two thing would happen (given I don't use strong naming this is of course just my expectation):-

1) The application fails to load because the version number has changed. This would presumably manifest itself as a type load exception.
2) The application loads the old version of the assembly (i.e. not the new one) if it can be located through assembly probing.

This seems to be a remarkably long winded way of trying to get you to concede my original point. "Public constants can cause trouble"

[AtW]

Yes, it seems to me that's compiler issue really - a constant does not mean it will never change, it just means it won't change during run-time of THAT DLL, seems like risky optimisation in compiler: they should have been performing this optimisation once DLL is loaded and current value of constant is obtained.

I was not argueing just was trying to understand

[DimPrawn]

Constants should be constants, like days of the week, PI, etc so it shouldn't cause a problem, BUT people declare constants for things like tax rates, telephone numbers and tulip like this they deserved to get burned.

Configuration settings are not constants. Constants are things that are constant, FOREVER.

[ASB]

Constants should be constants, like days of the week, PI, etc so it shouldn't cause a problem, BUT people declare constants for things like tax rates, telephone numbers and tulip like this they deserved to get burned.

Configuration settings are not constants. Constants are things that are constant, FOREVER.

I would largely agree. But days of the week is maybe a bad example. Ordinally you're fine but the actual name of the day is dependant upon environment and is therefore a configuration setting (by your reasonable definition).

It does seem a bit of a flaw though. Given the way it works I *think* that it would be better if it was not possible to make constants public or that they behaved as read only properties.

Previously they were defined in a compile time resource - some sort oh header file. If they are defined in some sort of run time resource the it is reasonable to expect them to change if the resource that defines them changes.

[Of course there would be a minor performance hit if they were treated as read only properties]

[AtW]

Constants in computer field is more like read only values - we call them constants to help avoid errorneous assignment and allow compiler to optimise things better, however it does not mean they won't or should not change at all.

[DimPrawn]

so what in C#

public readonly int X;

then if constants are like readonly variables?

[AtW]

This is effectively what is really meant by "consts", its not physics you know.