In ASP.NET web forms, can any arbitrary object be stored directly in ViewState, or are there specific requirements on the type of objects that can be placed there?

Introduction / Context:
ViewState is a mechanism in ASP.NET web forms that preserves the state of controls between postbacks by encoding data into a hidden field sent to the client and back. Developers often want to store custom values in ViewState to remember user selections or small pieces of state. However, not every kind of object is suitable for storage in ViewState, because its contents must be serialized to a string representation and transmitted in the page.

Given Data / Assumptions:

• We are working with ASP.NET web forms, where ViewState is enabled by default for many controls.
• ViewState data is serialized and embedded in the page as a hidden field.
• The question concerns what kinds of objects can be stored without causing runtime errors.
• We assume typical configuration without custom serialization providers.

Concept / Approach:
Because ViewState is serialized to and from a string representation, any object stored in it must be serializable. In practice, this means that custom classes should be marked with the appropriate attributes or implement interfaces that support serialization. Non serializable objects, such as open database connections or unmanaged resources, cannot be reliably represented in ViewState and will either cause errors or break the page. The best practice is to store small, serializable pieces of data, not heavy objects or resources that depend on server side state.

Step-by-Step Solution:
Step 1: Recall that ViewState is encoded and decoded across the network, so its content must be converted into a form suitable for transport. Step 2: Understand that serialization is the mechanism used to convert objects into such a form. Step 3: Recognize that only objects that support serialization, including basic value types and properly marked custom types, can be safely stored in ViewState. Step 4: Examine the answer choices. Option a explicitly states that only serializable objects can be stored in ViewState, which matches the requirement. Step 5: Reject answers that claim any object can be stored without restriction or that restrict ViewState to strings or specific resource types.

Verification / Alternative check:
If you attempt to store a non serializable object in ViewState in a real ASP.NET application, you will typically see runtime exceptions complaining about serialization. In contrast, storing integers, strings, and simple serializable classes works as expected. Microsoft documentation also warns developers to keep ViewState small and to store only serializable data that can be safely transmitted to and from the client.

Why Other Options Are Wrong:
Option b is wrong because it ignores the serialization requirement and would lead to runtime failures. Option c is too restrictive, because ViewState can hold many serializable types beyond strings. Option d incorrectly claims that ViewState cannot store data, which contradicts its core purpose. Option e focuses on database connections, which are not suitable for ViewState and should be managed on the server side without being serialized to the client.

Common Pitfalls:
A common pitfall is to store large or sensitive objects in ViewState, leading to bloated page sizes and potential security concerns. Another mistake is to assume that complex objects will just work, without checking whether their fields are all serializable. Keeping ViewState limited to small, serializable values improves performance and reliability.

Final Answer:
In ASP.NET web forms, only serializable objects should be stored in ViewState, as stated in option a.