Reply to: A question about classes / enumerated types/ best practice etc..

[AtW]

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

[DimPrawn]

so what in C#

public readonly int X;

then if constants are like readonly variables?

[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.

[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]

[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.

[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

[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]

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

[ASB]

Would not strong naming take care of this situation, which is effectively multiple versions of same named DLL?

Yes, but then that stuffs the deployment model of just issuing a patch to the erroneous DLL.

But this started as a note to the OP of a reason why public constants may be a bad idea in some cases - which was the entire point. i.e. Do this and this will happen. It might be unhelpful.

[AtW]

Would not strong naming take care of this situation, which is effectively multiple versions of same named DLL?

[ASB]

Yes but the (dubious) point is that the normal expectation is that a client DLL is dependant upon that dll at run time - not at compile time. It's not an entirely unreasonable assumption that shipping the changed dll should satisfy the clients requirements for it referred methods/properties/constants. It only satisfies the first two. Thus it is an inconsistancy.

[AtW]

But surely deployment of a patch would include deployment of all changed DLLs, which for practical purposes means all of them? I generally avoid referencing DLLs (unless they never change, and by that I mean never) directly, I prefer to create solution with all relevant projects in the same solution, so that build of it would ensure everything is up to date.

[ASB]

I am pretty sure almost all assemblies are copied into apps directory by VS, so if you change some dependency you need to recompile everything that depends on it.

Agreed, but the problem relates more to deployment of a later patch. This exemplefies the issue rather better than I did.

http://haacked.com/archive/2005/01/02/1796.aspx

[AtW]

I am pretty sure almost all assemblies are copied into apps directory by VS, so if you change some dependency you need to recompile everything that depends on it.

[ASB]

This may well not be the case with enums (I doubt it is) but be careful with public constants in other assemblys. They are copied into a referencing assembly at compile time, thus if the constant is changed and the client assembly is not recompiled then you are stuffed. Expose them as properties instead and use that. Of course this behaviour may have changed since I fell over it but I cant be bothered to check.