Attach to Process

DotNet

Iris Classon wrote a good lengthy post about the history of .NET web development and how it all lead to the development of the .NET Core that we have today. As someone who doesn't get to work as much on the web dev side of things, this was a very informative read for me. I think it is a good read for any .NET developer, so check out her post by following the link below.

ASP.NET Core and .NET Core and the Web Development Stack Timeline

Tags: #Bookmarks #AspDotNet #DotNet #DotNetCore

This is a problem I've seen in the past and just recently actually, where exceptions are made harder to troubleshoot, because of the way objects are instantiated. Allow me to explain.

class Program
{
    static void Main(string[] args)
    {
        try
        {
            UserDto dto = new UserDto()
            {
                UserName = "Apatosaurus",
                LastLoginDate = null
            };

            User user = new User()
            {
                UserName = dto.UserName,
                LastLoginDate = dto.LastLoginDate.Value.ToString("MM-dd-yyyy")
            };

            Console.WriteLine("User Info:");
            Console.WriteLine("Username: " + user.UserName);
            Console.WriteLine("LastLoginDate: " + user.LastLoginDate);
        }
        catch (Exception ex)
        {
            Console.WriteLine(ex.Message);
            Console.WriteLine(ex.StackTrace);
        }
    }
}

class User
{
    public string UserName { get; set; }
    public string LastLoginDate { get; set; }
}

class UserDto
{
    public string UserName { get; set; }
    public DateTime? LastLoginDate { get; set; }
}

Take for example the code above. What happens if the dto.LastLoginDate property is actually null when instantiating a User object?

at System.ThrowHelper.ThrowInvalidOperationException(ExceptionResource resource)
at System.Nullable`1.get_Value()
at NullRefErrorExample.Program.Main(String[] args) in C:\Users\dbansigan\source\repos\NullRefErrorExample\NullRefErrorExample\Program.cs:line 21

The error message above is what was displayed in the console app I was running. Line 21 points to User user = new User(), which is the line of code that was instantiating an object, but not the line of code that caused the exception. It should have pointed to Line 24 instead, LastLoginDate = dto.LastLoginDate.Value.ToString("MM-dd-yyyy"). However, since I followed Visual Studio's suggestion (IDE0017 Object initialization can be simplified), to simplify object initialization, this is what happened. So now you can see how it can make troubleshooting a more time-consuming task.

Note that this is a very simple example. Imagine if you had big class that had like 20 properties and multiple lines of initialization code that could cause an exception? It would be pretty hard to figure out which line of code caused the exception without having to debug the application.

So how do we fix it? Should we even still try to simplify object initialization?

Yes, we can still simplify object initializations, however we just have to be wary of using code that can cause exceptions when assigning property values. So the rule that I follow is that any line of code that could throw a null reference exception, or any exception for that matter, is taken out of the code that simplifies object initialization; they are instead moved to their own line.

So, taking the example from above, this is how I would initialize the object with the rule in mind. I basically just take out the code that assigns the value to the user.LastLoginDate property and move it outside the brackets containing the simplified initialization code.

User user = new User()
{
    UserName = dto.UserName
};
user.LastLoginDate = dto.LastLoginDate.Value.ToString("MM-dd-yyyy");

I run the app once again and this is what the stack trace tells me.

at System.ThrowHelper.ThrowInvalidOperationException(ExceptionResource resource)
at System.Nullable`1.get_Value()
at NullRefErrorExample.Program.Main(String[] args) in C:\Users\dbansigan\source\repos\NullRefErrorExample\NullRefErrorExample\Program.cs:line 25

Notice how the stack trace now points to Line 25 user.LastLoginDate = dto.LastLoginDate.Value.ToString("MM-dd-yyyy");, which is exactly the line of code that caused the exception. So now I get a head start on troubleshooting the exception. Also, any experienced developer will be able to tell almost immediately what caused the exception, if all they had to do was look at 1 line of code.

Are there alternative solutions to this?

An alternative is to check for null before even considering instantiating an object, like in the code below. I think this is a valid solution and it allows you to throw an exception with a detailed/specific message, or throw a custom exception. That said, if you are throwing an exception only because you cannot instantiate an object, then I don't see how it is significantly better than just letting it error out on the line of code assigning the property value. Your application is not going anywhere anyway, since you still cannot instantiate the object you need for your application to move forward.

if (!dto.LastLoginDate.HasValue)
{
    throw new NullReferenceException("dto.LastLoginDate cannot be null");
}

Another possible alternate solution could come from the use of nullable reference types in C# 8. However, this is something I have not been able to play with yet, so I cannot comment on the use of it.

I've seen this problem occur on other types of code as well, like for instance code where method chaining happens. If there is an exception, the end result is the same; you can hardly tell which method parameter, or which method call, or which specific part of the code caused the exception, because they are all essentially just one line of code. In situations like this, it is often advisable to break up the chain of method calls, unless you are absolutely sure that it can never cause an exception.

I'm curious to think if other developers also instantiate objects in this manner to avoid exceptions when creating objects. If you do, or you don't, I'm curious to hear your reasons for doing so. Please do send me a message so we can discuss.

Tags: #CSharp #DotNet

Have you ever had to do testing wherein you had to move your system date/time forward or back? If so, you will probably agree that one of the annoying things is remembering to reset the system date/time back to the current date/time. Most people will manually do this, which can be tiring when done multiple times during the day. If you are working in an office environment, then your workstation's system date/time can most likely be synced to a domain controller. Here is how you can easily do that using the command prompt in Windows.

Open up the command prompt and type in the command listed below:

net time /domain /set /y

You might have to open the command prompt in Administrator mode to get it to work.

Taking this a step further, what if you can automatically reset the system date/time on your workstation after a test finishes? I've had to do something similar since I've had to maintain some Coded UI tests, that can change the system date/time as part of their testing. So I wrote a utility method in C# that will reset the system date/time after a Coded UI test ends. This is called via the TestCleanup method that will run after a test ends.

[TestCleanup]
public void CleanUp()
{
    ResetLocalSystemTime();
}

private void ResetLocalSystemTime()
{
    using (Process netTime = new Process())
    {
        netTime.StartInfo.FileName = "NET.exe";
        netTime.StartInfo.Arguments = @"TIME /DOMAIN /SET /Y";
        netTime.StartInfo.UseShellExecute = false;
        netTime.StartInfo.CreateNoWindow = false;
        netTime.Start();

        Task.Delay(1000);
    }
}

Hope this helps some of the devs out there doing some testing. If you have a different way of doing this, do share them in the comments below or share them in a message.

Tags: #CSharp #DotNet #Tests

If you've ever needed to get a list of the base classes/types for an object in C#, this is one way of doing it. In my case, I had an object which was of the base class/type, but it was really a derived type.

Example: I had an object of type Animal, but it was really an instance of the Dog class, which is derived from the Animal base class.

The beauty of inheritance in object oriented programming is that the current instance of the object, can be an instance of the derived type, or the base type; it doesn't matter. As long as the code expects you to provide it an object of the base type, you can provide an instance of either one.

I needed to record the type hierarchy for that object when saving it to the database. So this utility method is what I came up with in short order. I am returning a list of strings in my example below, but there is nothing stopping you from returning an array of Types or whatever else you may need based on your scenario.

private List<string> GetTypeHierarchy()
{
    List<string> typeHierarchy = new List<string>();

    Type currentType = this.GetType();
    typeHierarchy.Add(currentType.Name);

    Type baseType = currentType.BaseType;
    while (baseType != null)
    {
        typeHierarchy.Add(baseType.Name);
        baseType = baseType.BaseType;
    }

    typeHierarchy.Reverse();
    return typeHierarchy;
}

I intentionally wrote this without recursion, because recursion hurts my head haha. There might be a better/cleaner way of doing this, if so, do share your solution with me.

#CSharp #DotNet

Recently I ran into an issue where I needed to exclude a property from getting serialized using Json.NET. The easy answer is to add a [JsonIgnore] attribute to the property. The problem with doing that is it will also ignore the same property during deserialization. So I needed a solution that allows me to ignore a property using serialization, but still set that property's value during deserialization. Thankfully I found a blog post from 2013 that explains exactly how to do that. I would have wasted more hours searching for an answer had I not found this solution right away.

There's a little known feature of Json.NET that lets you determine at runtime whether or not to serialize a particular object member: On the object you're serializing, you have to define a public method named ShouldSerialize{MemberName} returning a boolean value. – Marius Schulz

Visit Original Post: Conditionally Serializing Fields and Properties with Json.NET

It was only after I found Marius' blog post that I then found the documentation talking about conditional property serialization on the Newtonsoft website.

This is one of the rare instances where I didn't find the answer in StackOverflow. It makes me grateful for the developers who are still cranking out blog posts and sharing solutions to problems on their personal blogs/websites.

#Bookmarks #JsonDotNet #DotNet #Serialization