cs11dotnet7/docs/errata/common-errors.md

Common Errors and How to Fix Them (3 items)

If you have suggestions for other common errors, then please raise an issue in this repository or email me at markjprice (at) gmail.com.

• Missing types and members in a utility class
  • CS0103 The name 'DoSomething' does not exist in the current context
  • CS0122 'Util.DoSomething()' is inaccessible due to its protection level
• Missing functions in the partial Program class
  • CS0103 The name 'DoSomethingElse' does not exist in the current context
• Microsoft introduces a bug in a later version

Missing types and members in a utility class

CS0103 The name 'DoSomething' does not exist in the current context

You might create a utility class with a method, as shown in the following code:

namespace Common.Errors;

public class Util
{
  static void DoSomething()
  {
    Console.WriteLine("Doing something.");
  }
}

You try to call the method directly (without any class name prefix) in the Program.cs file, as shown in the following code:

using Common.Errors;

DoSomething(); // This causes: CS0103 The name 'DoSomething' does not exist in the current context.

The class is declared inside the Common.Errors namespace and you have imported the Common.Errors namespace in Program.cs so why can't it be found?

First, you need to statically import the class rather than just import it's namespace, as shown in the following code:

using static Common.Errors.Util; // Statically import the class to call its static methods.

CS0122 'Util.DoSomething()' is inaccessible due to its protection level

But now you get a different compiler error, as shown in the following code:

DoSomething(); // This causes: CS0122 'Util.DoSomething()' is inaccessible due to its protection level.

Next, by default members of a class are private so you must explicitly make the method public or internal, as shown in the following code:

namespace Common.Errors;

public class Util
{
  public static void DoSomething()
  {
    Console.WriteLine("Doing something.");
  }
}

Now the method call works.

Missing functions in the partial Program class

CS0103 The name 'DoSomethingElse' does not exist in the current context

In my book, I show how to define functions that can be easily called directly in the Program.cs file because you add them to the partial Program class definition. You can put these functions in a separate file, for example, Program.Helpers.cs, as shown in the following code:

// A file named Program.Helpers.cs.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace Common.Errors
{
  partial class Program
  {
    static void DoSomethingElse()
    {
      Console.WriteLine("Doing something else.");
    }
  }
}

Note: The above file might have been created by the Visual Studio 2022 project item template. It imports five commonly used namespaces and wraps the class in a namespace that is the name of the project.

You try to call the method directly (without any class name prefix) in the Program.cs file, as shown in the following code:

DoSomethingElse(); // This causes: CS0103 The name 'DoSomethingElse' does not exist in the current context.

The class is declared as Program and uses the partial keyword so why doesn't it merge with the auto-generated Program class? Because it is a different namespace and therefore you now have two classes named Program. The fully qualified name of your class is Common.Errors.Program. The fully-qualified name of the auto-generated class is just Program.

To fix the problem, delete the explicit namespace (and you might as well remove the unncessary imported namespaces at the same time), as shown in the following code:

// A file named Program.Helpers.cs.
partial class Program
{
  static void DoSomethingElse()
  {
    Console.WriteLine("Doing something else.");
  }
}

Note: The filename is not important and you can have as many files as you like, for example, Program.Helpers.cs, Program.Functions.cs, Any.Thing.cs, and even Muppets.cs.

Microsoft introduces a bug in a later version

Although rare, it is possible that by using a later version of a NuGet package than the one I used to write the book, you experience different behavior, especially negative behavior if it is due to a bug.

For example, in the Microsoft.Extensions.Configuration.Binder package, version 7.0.3 has a bug that causes an exception to be thrown when it tries to parse a trace level set in an appsettings.json file. Previous versions from 7.0.0 to 7.0.2 did not have this bug.

You can read more this specific example here: https://github.com/markjprice/cs11dotnet7/blob/main/docs/errata/errata.md#page-178---reviewing-project-packages

If you add packages using the Visual Studio 2022 user interface or the dotnet add package command-line tool then it will use the most recent version by default which can cause this issue when Microsoft adds any bugs to any packages in future. If you have problems, try manually reverting to an older version.