0

I have a class with has variables of three types - constant , readonly , reference variable like this 

public class Constants
{
    public const int constA = 10;
    public int readOnlyB = 10;
    public readonly int referenceVarC = 10;
}

There is another project which references these variables from above like this -

class Program
{
    static void Main(string[] args)
    {
        int a = Constants.Constants.constA;
        int b = new Constants.Constants().readOnlyB;
        int c = new Constants.Constants().referenceVarC;
        Console.WriteLine("The value of a is {0}", a);
        Console.WriteLine("The value of b is {0}", b);
        Console.WriteLine("The value of c is {0}", c);
        Console.ReadLine();
    }
}

As per constant type variable nature - when i change the value of Constant and recompile the project but don't recompile the project which is consuming the constants , it refers to the old value of constant variable. Only on recompilation of the consuming project ,the new value of the constant project. This is understandable.

But why this nature is observed for readonly and reference variable also . There value, if changed in their creation project and the project gets compiled , should change in the consuming project , the consuming project being not recompiled, should change but i have observed them to point to old values.

As per me, when the consuming project is ran without recompilation , the referenced assemblies are loaded ( which are recompiled ) and the new values should be loaded.

pnuts
  • 58,317
  • 11
  • 87
  • 139
SunilA
  • 513
  • 8
  • 19
  • http://stackoverflow.com/questions/21022779/how-to-stop-c-sharp-from-replacing-const-variable-with-their-values/21023404#21023404 – Khanh TO Aug 21 '15 at 12:39
  • Different questions, but very similar answer would apply I think. See http://stackoverflow.com/a/29523499/2312877 ... maybe – Kritner Aug 21 '15 at 12:45
  • 2
    While it's clear what you mean, there are some problems in the question: `int` is not a reference type and `readonly` is added to a wrong member. – Sinatr Aug 21 '15 at 12:47
  • 1
    Can't reproduce your behavior. For me, it works as expected. It's more likely that there is a flaw in your test and you are somehow still pointing to your old dll. You may want to describe the exact procedure you followed to perform your test. – sstan Aug 21 '15 at 12:48
  • 1
    Agreed, this works as expected. Compile your solution. Copy the .exe and the .dll into a separate directory. Change the values. Compile again. Copy only the .dll to the separate directory. Run the .exe. See the differences. – Corak Aug 21 '15 at 12:51
  • @sstan: The question isn't about performing a test and it isn't working properly. It works exactly how it should, it's just that the OP has a misunderstanding about how references work, and that is what the question is – musefan Aug 21 '15 at 12:57
  • @Corak - your solution works. What i tried previously was to have the two projects in one solution in visual studio and the consuming project references the project with variables. – SunilA Aug 21 '15 at 13:05
  • @musefan: I see your point. It's just that I think OP's question wasn't: "*What am I doing wrong that is causing this to behave inexplicably?*". Instead, I think his question was: "*Why does .NET have broken behavior?*". So my point was simply that, instead of pointing the finger at .NET, it should be pointed at the way OP used VS to setup his little test scenario. So I think we're both saying the same thing, except you are being very generous in assuming that he understood that he was doing something wrong, and that that was his question all along. – sstan Aug 21 '15 at 13:24
  • @sstan - Yes , i had a wrong understanding. It is corrected now. Thanks :). – SunilA Aug 21 '15 at 13:45

1 Answers1

3

Without checking I would assume that you need to recompile the consuming project because that is the process that copies the referenced DLLs over. In other words, if you don't recompile, you are still using the old DLLs in your output bin folder.

If you were to manually copy the DLLs from your source output "bin", to your consumer output "bin" then you could run the application without recompiling and it would use the new values.

The key point here is that applications don't really know about other applications. So although you reference one project to another in Visual Studio, the actual application doesn't know the other project exists. All it knows is "I need to use these DLL files", and VS takes care of updating the DLL files when you rebuild.

musefan
  • 47,875
  • 21
  • 135
  • 185
  • So why it is said that recompilation is required for static variables and not required for reference variables since they get loaded at run time. – SunilA Aug 21 '15 at 12:53
  • @SunilA: Where does it say that? I think you are likely just misunderstand the meaning of it – musefan Aug 21 '15 at 12:59
  • 1
    @SunilA I think you are getting confused between recompilation of the consuming app and the fact that when you recompile a consuming app in visual studio it updates an dependent DLLs that have changed. As musefan says if you copy the updated DLLs into the bin folder it will use them without requiring recompilation, but this does not happen magically. E.g. if you has deployed the app somewhere you wouldn't expect it to be updated because happened to have recompiled some DLL on some other machine. – Ben Robinson Aug 21 '15 at 13:03
  • 1
    @BenRobinson and musefan - i had this assumption that when a project refers to a dll and that dll is changed from its parent project , the consuming project should point to the new dll. This is wrong. It only refers to the dll available in its bin directory. Only on recompilation of the consuming project , new dlls are loaded. Thanks a lot for clearing this to me. – SunilA Aug 21 '15 at 13:42