Saturday 21 May 2016

Guid parsing - strange casing behavior

System.Guid is used quite often by .NET developers. For most of the scenarios that you encounter it works quite well. However consider the following code block:

string guidstr1 = "122F5113-FF7E-455D-8FF0-D79A2B830375";
string guidstr2 = "076e6c09-57b1-48da-836f-57d3646d8cb0";
Guid guid = Guid.NewGuid();
Console.WriteLine(guid);
guid = new Guid(guidstr1);
Console.WriteLine(guid);
guid = new Guid(guidstr2);
Console.WriteLine(guid);
Console.ReadLine();


Output:
edca0d0e-e62f-4c03-b41a-16cc9176df71
122f5113-ff7e-455d-8ff0-d79a2b830375

076e6c09-57b1-48da-836f-57d3646d8cb0

Did you expect the highlighted output? Parsed GUID has changed the casing of alphabets.

If you crack open ILSpy and checkout the implementation of Guid constructor, you can locate the line that tries to parse the Guid using a style option "any".

public Guid(string g)
{
    
if (g == null)
    {
        
throw new ArgumentNullException("g");
    }
    
this = Guid.Empty;
    Guid.GuidResult guidResult =
default(Guid.GuidResult);
    guidResult.
Init(Guid.GuidParseThrowStyle.All);
    
if (Guid.TryParseGuid(g, Guid.GuidStyles.Any, ref guidResult))
    {
        
this = guidResult.parsedGuid;
        
return;
    }
    
throw guidResult.GetGuidParseException();
}

There are many styles supported for GUID but there is no option that can preserve casing of the value.

private enum GuidStyles
{
    None =
0,
    AllowParenthesis =
1,
    AllowBraces =
2,
    AllowDashes =
4,
    AllowHexPrefix =
8,
    RequireParenthesis =
16,
    RequireBraces =
32,
    RequireDashes =
64,
    RequireHexPrefix =
128,
    HexFormat =
160,
    NumberFormat =
0,
    DigitFormat =
64,
    BraceFormat =
96,
    ParenthesisFormat =
80,
    Any =
15
}

Interesting to know!!

Sunday 15 May 2016

Visual Studio 2015 crash : case # 1

Recently I ran into an interesting problem. One of my colleague was facing an issue with his Visual Studio 2015 crashes. As soon as he would launch VS on his machine, the VS application screen would freeze for some time and then the process would terminate automatically. So, we started looking around for clues in the EventLog. We noticed the following log reported when the VS crashed on the machine.

Application: devenv.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.TypeLoadException
   at Microsoft.VisualStudio.Shell.Connected.ConnectedUser.BaseUserContext+d__56.MoveNext()
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].Start[[Microsoft.VisualStudio.Shell.Connected.ConnectedUser.BaseUserContext+d__56, Microsoft.VisualStudio.Shell.Connected, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a]](d__56 ByRef)
  at Microsoft.VisualStudio.Shell.Connected.ConnectedUser.BaseUserContext.GetProfileSessionTokenCredentialsAsync(Boolean, System.Threading.CancellationToken)
   at Microsoft.VisualStudio.Shell.Connected.ConnectedUser.BaseUserContext+d__54.MoveNext()
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(System.Threading.Tasks.Task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(System.Threading.Tasks.Task)
   at Microsoft.VisualStudio.Shell.Connected.ConnectedUser.BaseUserSession+d__48.MoveNext()
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(System.Threading.Tasks.Task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(System.Threading.Tasks.Task)
   at Microsoft.VisualStudio.Shell.Connected.ConnectedUser.BaseUserSession+d__37.MoveNext()
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(System.Threading.Tasks.Task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(System.Threading.Tasks.Task)
   at Microsoft.VisualStudio.Shell.Connected.ConnectedUser.IdeUserSession+d__54.MoveNext()
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(System.Threading.Tasks.Task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(System.Threading.Tasks.Task)
   at Microsoft.VisualStudio.Shell.Connected.ConnectedUser.VsOnlineSettings+d__29.MoveNext()
  at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(System.Threading.Tasks.Task)
  at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(System.Threading.Tasks.Task)
   at Microsoft.VisualStudio.Shell.Connected.ConnectedUser.VsOnlineSettings+d__28.MoveNext()
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(System.Threading.Tasks.Task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(System.Threading.Tasks.Task)
   at Microsoft.VisualStudio.Shell.Connected.ConnectedUser.VsOnlineSettings+d__25.MoveNext()
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(System.Threading.Tasks.Task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(System.Threading.Tasks.Task)
   at Microsoft.VisualStudio.Services.Roaming.TfsServer+d__15.MoveNext()
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(System.Threading.Tasks.Task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(System.Threading.Tasks.Task)
 at Microsoft.VisualStudio.Services.Roaming.RoamingProfileManager+d__12.MoveNext()


While most of the error stack meant nothing much, couple of things stood out (highlighted above). It seemed that the team explorer component of Visual Studio was causing the crash when trying to connect to a VSTS as soon as VS was launched.

So how do we prove that it is the Team Explorer component that is causing the crash? Simple. Disconnect the machine from Network i.e. turn off Wi-Fi and remove LAN cable. Now when we launched the VS, it did not crash. Moreover, we had a repro step now. Turn on the Wi-Fi and launch VS and it would crash. Turn off the Wi-Fi and launch VS and it would work fine. In fact, we could turn on the Wi-Fi once VS is launched successfully and things wouldn't crash.

Is there anything else we could do to fix this permanently? We removed the VS profiles from visual studio i.e. turn off Wi-Fi, launch VS, go to account setting, remove the accounts.




After that we could have the VS back to normal behavior and encountered no more crashes. Just some workarounds you have to try out to keep your productivity up :).