The Untold Truth: Creating C# Objects Without Calling a Constructor

A deep dive into how C# can instantiate objects without ever running their constructors — and when it actually happens.

🧠

In C#, constructors are supposed to be the first line of defense — the foundation on which every object is born. But what if I told you there's a secret tunnel beneath that gate?

Yes — you can create a C# object without ever calling its constructor.

Whether you're a seasoned developer or a curious learner, this trick will bend your understanding of how C# handles object instantiation.

Let’s go down the rabbit hole. 🕳️🐇

🤔 Why Skip the Constructor?

There are rare (but valid) scenarios where skipping a constructor is useful or even necessary:

• ✅ Deserialization: When reconstructing an object from JSON, XML, or binary formats.

• ✅ Mocking Frameworks: Creating proxy or fake objects in unit tests.

• ✅ Performance Tuning: In extreme edge cases involving object pooling.

• ✅ Low-Level Runtime Work: Serialization libraries, ORMs, and AOP tools.

In these cases, calling the constructor might:

• Trigger unwanted side effects

• Be impossible due to private/protected access

• Invalidate the deserialized state

🔍 The Magic Method: FormatterServices.GetUninitializedObject

C# gives us a backdoor via the System.Runtime.Serialization namespace:

object FormatterServices.GetUninitializedObject(Type type)

This method allocates memory for an object without invoking any constructor — not even the parameterless one.

🚧 Code Example: Constructor Not Called!

using System;
using System.Runtime.Serialization;

class User
{
    public string Name;

    public User()
    {
        Console.WriteLine("Constructor called!");
        Name = "Default User";
    }
}

class Program
{
    static void Main()
    {
        // Normal instantiation
        var user1 = new User();
        Console.WriteLine($"user1.Name: {user1.Name}");

        Console.WriteLine();

        // Dangerous instantiation — constructor is skipped!
        var user2 = (User)FormatterServices.GetUninitializedObject(typeof(User));
        Console.WriteLine($"user2.Name: {user2.Name}");
    }
}

🧾 Output:

Constructor called!
user1.Name: Default User

user2.Name:

As you can see, user2 was created without calling the constructor — and Name is null.

⚠️ Why This Is Dangerous

Here’s the catch: Skipping constructors skips initialization logic.

That means:

• Required fields might remain unassigned

• Invariants may be broken

• Methods might throw NullReferenceException

• Debugging such objects is painful

It’s like creating a car without the ignition system — it exists, but don’t expect it to drive.

✅ When Should You Use This?

Only when you meet all of the following:

• You’re building a serializer, mocking library, or performance-critical framework

• You understand the object's internal structure and state dependencies

• You take responsibility for initializing fields manually after creation

If you're writing standard application code — avoid it. Use regular constructors and let the runtime handle lifecycle.

🧵 TL;DR

• C# has a hidden trick via FormatterServices.GetUninitializedObject

• It creates an object without calling the constructor

• JSON libraries like Newtonsoft.Json use this behind the scenes

• Use it only in advanced scenarios — it's powerful, but risky

📣 Final Thoughts

C# is elegant, but beneath the surface, it’s packed with low-level power.
FormatterServices.GetUninitializedObject is one of those sharp tools — amazing for meta-programming and serialization… but not for everyday development.

Remember: just because you can do something, doesn’t mean you should.

💬 What do you think?
Have you ever used this method in real projects? Share your experience or horror story in the comments!

---