Getting "ref" keyword required in Double.TryParse

Question

I have a library with the following code:

double result = -1;

if (!string.IsNullOrEmpty(fieldName))
{
    string value = HttpContext.Current.Request.QueryString[fieldName];
    if (string.IsNullOrEmpty(value))
    {
        value = HttpContext.Current.Request.Form[fieldName];
    }

    if (string.IsNullOrWhiteSpace(value) || !double.TryParse(value.Trim(), out result))
    {
        result = -1;
    }
}

return result;

In my local copy of Visual Studio 2015 this compiles fine. Last week the build server would let this compile without a problem as well. Suddenly, on Monday the build server started having the error:

QueryParser.cs(449,53): error CS1620: Argument 2 must be passed with the 'ref' keyword [$projectPath\Core40.csproj]

When I make that switch (using ref instead of out), the build server is able to complete the build without errors, but Visual Studio will no longer compile.

From my reading of the relevant documentation, double.TryParse has always taken the out keyword, so there must be something off about the build server's libraries, but I'm not sure what or how to go about diagnosing it.

---

After some of the questions below, I went back to the class and confirmed that there are multiple instances of decimal.TryParse(value, out result), int.TryParse(value, out result), float.TryParse(value, out result), long.TryParse(value, out result), and Guid.TryParse(value, out result). I also was able to replace "double" with "float", and it worked just fine. This is something specific to double.

---

Apparently, the build command is:

msbuild  /m /p:Configuration=Release /p:Platform="Any CPU" $path\$solution.sln

---

Also, I can replace the TryParse with a try { return double.Parse(value); } catch (Exception) { return DEFAUlT; } block (my temporary way forward), but that doesn't actually solve the problem.

Hamstring

What compiler is your build server using? Is it also running on windows? – Chenab

@Chenab I'll need to find out. Unfortunately, the build server isn't something I have control over – Hamstring

I cant help but suspect that you are misreading/misinterpreting the exception- though your test (changing it to ref) seems to indicate you are not. Is this the exact code? Are you sure that someone didn't sneak in a using statement or something equally asinine to make double mean something other than System.Double? If you are working with source control, do a pull/refresh/whatever to make sure your local working copy is the very latest that's in the repository. – Patio

@ChrisShain double is a C# type, I'm sure you cannot define a custom type with the same name. – Inger

@ChrisShain I'm 100% sure that Git reports no changes to that library for two weeks (a week before the compiler problem), and no changes to that file for at least 3 months. Instinct would be that somehow someone put a corrupted external lib on the build server, but the fact that it affects double, of all things, makes this Twilight Zone material. – Hamstring

Have you tried defining and invoking your own custom method with an out parameter and checking to see if the build server also misbehaves in that case? In other words, is the out parameter issue specific to double.TryParse, or is it more generalized? – Muscatel

Not sure what the cause is, but I'd try the following to attempt to debug it: Remove the broken line. Try double.TryParse in a separate library in your solution. Does it still work? Try in a brand new fresh solution with no dependencies. What about int.TryParse? Does it work with your own out parameter methods? – Chenab

@Chenab Switching the broken line to a try...catch block works, as does swapping the class in question to float. – Hamstring

Maybe some build cache got corrupted - or overwritten by something unrelated. Try removing any existing object files. – Juxtaposition

I was thinking the same thing as @ivan_pozdeev. You may try adding /t:Clean,Build for it to force a full rebuild. Does QueryParser.cs(449,53) point to that TryParse call? Are both installed .net framework versions the same? Check if there are new windows updates for the framework that may have screwed things up. – Salespeople

Answer 1

Turns out that this was some type of bad cache issue. Eventually, DevOps rebooted the build machine and the problem went away. I'd love to have an actual root cause, but the resolution was still "turning off and turning it on again."

Hamstring