-----------------------------------------------------------
New Message on BDOTNET
-----------------------------------------------------------
From: SitaramanM
Message 4 in Discussion
Hi Saravana Tht was a good link. In fact a similar problem exists in Constants also
and i have been thinking of posting that info for quite some time now. here you go
Whenever you use constants, excercise caution so that you use constants defined
within your assembly only(not practical always though). If you are using constants
which are present in a different assembly, that could be a potential recipe for
disaster. The reason is that, whenever a constant is used in a client application,
the compiler will put the literal value that the constant holds, while compiling the
code to IL. So if a change is made in the constant in a called application where the
constant is declared and only that called application is compiled, then the changes
are NOT reflected in the calling aplication. Ill give a small example Calling
Application(Client) : Dummy_ConstantsNotRecompiledProblemClassClient Type : Console
application Module Name: Module 1 Version : 1.0 Code : Module Module1 Sub Main()
Dim i As Integer
Dim o As New Dummy_ConstantsNotRecompiledProblemClassLib.Class1
i = o.iVal ' Referring to the constant here
Console.WriteLine("Value of Constant : " & i)
Console.ReadLine()
End Sub End Module Called Application(where the constant is defined) :
Dummy_ConstantsNotRecompiledProblemClassLib Type : Class library Class Name : Class1
Version : 1.0 Code : Public Class Class1
Public Const iVal As Integer = 10
End Class Here when the code is compiled, the IL generated for the Client
application(Dummy_ConstantsNotRecompiledProblemClassClient) is as follows .method
public static void Main() cil managed
{
.entrypoint
.custom instance void [mscorlib]System.STAThreadAttribute::.ctor() = ( 01 00 00 00 )
// Code size 25 (0x19)
.maxstack 1
.locals init ([0] int32 i,
[1] class
[Dummy_ConstantsNotRecompiledProblemClassLib]Dummy_ConstantsNotRecompiledProblemClassLib.Class1
o)
IL_0000: nop
IL_0001: newobj instance void
[Dummy_ConstantsNotRecompiledProblemClassLib]Dummy_ConstantsNotRecompiledProblemClassLib.Class1::.ctor()
IL_0006: stloc.1
IL_0007: ldc.i4.s 10 ' compiler has stripped off the constant reference and
replaced it with a literal value
IL_0009: stloc.0
IL_000a: ldloc.0
IL_000b: call void [mscorlib]System.Console::WriteLine(int32)
IL_0010: nop
IL_0011: call string [mscorlib]System.Console::ReadLine()
IL_0016: pop
IL_0017: nop
IL_0018: ret
} // end of method Module1::Main
Note here that during IL generation, the compiler replaced the reference to the
Constant iVal with the actual value at the time of compilation. Now The output as
expected would be "Value of Constant : 10". Which is fine Now let use asume that
the constant's value changes. So i modify the Called
Application(Dummy_ConstantsNotRecompiledProblemClassLib) as follows Called
Application(where the constant is defined) :
Dummy_ConstantsNotRecompiledProblemClassLib Type : Class library Class Name : Class1
Version : 2.0 Code : Public Class Class1
Public Const iVal As Integer = 20
End Class And i recompile ONLY this Called
Application(Dummy_ConstantsNotRecompiledProblemClassLib). Now if i run my client
again(note that we have not recompiled the client). So though the expected output
should now be 20, it will still be 10 only. This is coz, at the time of the client
compilation to IL itself, the compiler stripped off the constant and replaced it with
the value. So now though the constant value has changed, it is never known to the
client app. So you will again get the output "Value of Constant : 10". which is
wrong. That said, what are the risk mitigation factors, as i could percieve Client
application side : a) Do not use cross-assembly/cross-module constants : Not a viable
option though, as we need to sue these in day-to-day development. Classic example is
the frequest usage of constants in ADO.Net assembly b) Recompile your client app
whenever you recieve a new version of a referenced assembly : Again not a practical
option for large-scale projects. In . However one good thing is that, once a client
app is built against an assembly, it will always use that version only, even though a
new version might be present on the system. This default behaviour can be overridden
by mechanisms like bindingredirect etc. So point to note is that, whenever you are
using such mechanisms like binding redirects, calling application should always be
recompiled against that version(which iteslf might defeat the very purpose of binding
redirec ease-of-use). So as i see it, there is nothing much to control from the
clientapp side :( Server application side : a) If you are developing a class
library for intended use by consumer classes, treat constants as immutable. do not
ever change the value of your defined constants across versions any more inputs from
the group welcome hth regards, sr
-----------------------------------------------------------
To stop getting this e-mail, or change how often it arrives, go to your E-mail
Settings.
http://groups.msn.com/BDotNet/_emailsettings.msnw
Need help? If you've forgotten your password, please go to Passport Member Services.
http://groups.msn.com/_passportredir.msnw?ppmprop=help
For other questions or feedback, go to our Contact Us page.
http://groups.msn.com/contact
If you do not want to receive future e-mail from this MSN group, or if you received
this message by mistake, please click the "Remove" link below. On the pre-addressed
e-mail message that opens, simply click "Send". Your e-mail address will be deleted
from this group's mailing list.
mailto:[EMAIL PROTECTED]
