Handling Multiple Collections in C#

One thing I would like to point out is that all your Add methods are not necessary. If you expose the List<T> like you do, you can use them for adding. And you can use the collection initializer syntax for that:

var institutions = new List<Institution>
{
    new Institution("My college")
    {
        Terms =
        {
            new Term("2016", "Spring")
            {
                Courses =
                {
                    new Course("Math 210")
                    {
                        Assignments =
                        {
                            new Assignment("Chapter 1")
                        }
                    }
                }
            }
        }
    }
};

On first sight, this does not look any better than your original, but I believe it reflects the intention of the code better. (And it probably won't look as bad in more realistic code.)

I do have some further insight that I can provide. First, about your classes, since the name of an institution should probably remian the same and not change, upon instantiation is the only time that you should allow external implementation to modify that string for the Name -- make it immutable from the class perspective. This would be proper encapsulation; a getter which is publicly accessible and any setter functionality as private. Same principle applies to other fields within other classes. Additionally, overriding the ToString() method for user-defined objects is usually always fairly useful in cases where the object has a string representation.

Keep in mind, you can also create your own collection types by implementing a class that implements IList or ICollection for instance, among other interfaces. If you want your object to be enumerable via a foreach loop then consider IEnumerable as well. Unless you have specific guidelines as to how your class should be used, the idea is generally to keep the implementation as general as possible for scalability reasons.

As for the naming conventions, there are .NET naming conventions that you might want to follow and make part of your habit from MSDN (https://msdn.microsoft.com/en-us/library/ms229002(v=vs.110).aspx). Typically locals use camelCase rather than PascalCase.

If your intention is to gear the implementation towards strings, then indexed properties as mentioned before may be the best case for this. As most examples show, the paradigm looks a lot similar to any of the .NET provided TryParse() methods to avoid an exception from being thrown but allow indication of whether the action succeeded or not too.

I don't see a reason for Aggregation here because the heirchy to me looks like it should be as follows: Institution -> Semester -> Terms -> Courses -> Assignments. None of the lower level objects should exist without a parent in my opinion. A semester from my past experience was the equivalent of 2 terms. What you probably want in this case in terms of object relationship is Composition.

You're right not to use inheritance, and in fact I think your design is fine. Let's take a look at one of your uses of your code.

MessageBox.Show(Institutions[0].Terms[0].Courses[0].Assignments[0].Name);

While the [0] uses here are standard for testing, in most uses of a class-based design, you would not be accessing the lists directly by some index, eg writing the number 0 into your code. Instead, you would have lots of "for-each" loops that are performing some important function on all Terms, and then all Courses in that term. Those operations will also look cleaner when the looping is separated into multiple tabbed {} blocks, rather than all in one line.

One-to-Many object mapping is a very important and common concept in programming in general. Your operating system has many Users (usually just one). Each User can run many Programs simultaneously. Those Programs can run multiple Threads...etc

You won't ever get away from the need to use collections, although programming has evolved to make them easier to use. C# in particular has a mechanism called "LINQ" that lets you quickly create "pretend-collections" that represent all parts of another collection, but changed in some way. That's worth reading up on its own, though.

Response to comment...

That's already how all objects (in C# anyway) work; only by references. Let's look at this example.

Course course101 = Institutions[0].Terms[0].Courses[5];
Console.Writeline(Institutions[0].Terms[0].Courses[5].Name); // "C# 101"
course101.Name = "Boring Class";
Console.Writeline(Institutions[0].Terms[0].Courses[5].Name); // "Boring Class"

The only time you actually have a new, separate object is when you call new Course(). Otherwise, the only things you are passing around as variables are references. So in case you were worried you'd need to pass around "institutionIndex, termIndex, courseIndex" for each function, definitely don't worry about that.