0

I have the following code inside a method:

string username = (string)context["UserName"];

string un = (string)context["UserName"];

The problem is that the first string "username" is not assigned, while the second does.

To make it more strange, when I have stopped the debugging after the first line and copied the line to the Immediate window, dropping the varible type delaration, it was assigned succesfully.

I have made rebuild all and checked project properties which seems to be OK.

The context variable is a System.Configuration.SettingsContext, which is a hash table. To be more specific, I'm implementing a profile provider, the GetPropertyValues method.

I am using VS 2012 and .NET 4.5

EDIT:

I am using code contract in my project, which uses compile time code injection for runtime checking. I disabled it and all is working well. I'll try to remove contracts one by one to find which one is causing the problem.

aikixd
  • 506
  • 5
  • 16
  • 2
    Unlikely to be the variable name. Did you try swapping the order of the assignments? – Douglas Jul 31 '12 at 18:28
  • 1
    Are you sure you don't have another `username` variable defined elsewhere that is in scope? – Oded Jul 31 '12 at 18:29
  • @Douglas Not only that. I have also tried to assign value to an object and to the string after that, but no luck. – aikixd Jul 31 '12 at 18:30
  • Provide the context (class, method, major library). Right now it's not even clear if these are local vars or fields. – H H Jul 31 '12 at 18:31
  • @Oded Intellisence gives nothing – aikixd Jul 31 '12 at 18:31
  • It's not the variable name unless you are shadowing a class level variable and then attempting to read the result of the assignment from another method. Please create a small reproducible code sample, there is no way we can solve this problem for you given what information you have provided. And forget intellisense, you're just adding a layer of confusion into your troubleshooting. – Ed S. Jul 31 '12 at 18:31
  • @aikixd: I meant that the variable name does not make a difference. If you name your first variable "un" and your second variable "username", then I'm confident that "username" would get assigned (assuming your behaviour is consistent and not consequent of a threading issue). – Douglas Jul 31 '12 at 18:32
  • Try to assign to `/* string */ username` – H H Jul 31 '12 at 18:37
  • @Ed-S There are no fields I have defined for that class with this name. The class is a deriviation from .NET, so I don't know whether it is defined there. But I can assign the variable from within the Immediate window and after that the application executes fine. I'll try to reproduce it in test project. – aikixd Jul 31 '12 at 18:40
  • @Henk-Holterman Does not compile. – aikixd Jul 31 '12 at 18:41
  • *"The class is a deriviation from .NET"* - I have no idea what that means. – Ed S. Jul 31 '12 at 18:49
  • @Ed-S I have mispelled. The class is a deriviation from .NET class. I have also looked at the .NET disassembley and found no fields with this name in ancestor classes. – aikixd Jul 31 '12 at 18:56
  • Wait... so you have decompiled a type defined in the library and are using that to create this example? I have no idea how to interpret this problem anymore. – Ed S. Jul 31 '12 at 19:00
  • @Ed-S Ofcource not. I have used the ILSpy to look inside. – aikixd Jul 31 '12 at 19:06
  • The CC angle makes it much more relevant, and more wanting of a small reproducable case. – H H Aug 01 '12 at 19:52
  • 1
    To the people wondering: it is indeed a bug in Code Contracts, and I have reproduced it below. – Daniel A.A. Pelsmaeker Aug 02 '12 at 10:26

2 Answers2

0

After investigating and desabling contracts I found that the problem appears only when runtime contracts checking is enabled and this contract appears:

Contract.Ensures(Contract.Result<System.Configuration.SettingsPropertyValueCollection>() != null);

If I delete this line, the code works, so it looks like code contracts bug, though I couldn't recreate it on a test project.

aikixd
  • 506
  • 5
  • 16
0

What you are seeing is similar to a Code Contracts bug I saw before. I wrote something about it here a few months back. If you have this bug, you probably also have a lambda or LINQ expression in your method that uses username.

For future reference, this is the bug I saw:

I had in the same method a lambda expression capturing a local variable, lets say values, and a Contract.Requires() expression checking something completely unrelated. While debugging that method, the debugger shows in Locals the variable values twice, and reports the value of values always as null even when this is clearly not the case.

To reproduce:

  static void Reproduction(string argument)
  {
      Contract.Requires(argument != null); // <-- (1)

      int[] values = new int[1];
      Debug.Assert(values != null);

      Func<int, bool> d = i => values[i] >= 0; // <-- (2)

      Console.WriteLine(values);
  }

Put a breakpoint somewhere in this method after the assignment to values and ensure that the method gets called. When the debugger hits the breakpoint, look at the Locals list of Visual Studio for the duplicate variable. Hover the mouse over values to find that it gets reported as being null, something which is clearly not the case.

The problem disappears when removing either the contract (1) or the line with the lambda (2).

Community
  • 1
  • 1
Daniel A.A. Pelsmaeker
  • 47,471
  • 20
  • 111
  • 157