Question 1

C#.NET — Implement a read-only property Length correctly in a class.

Accepted Answer

Introduction / Context: This item tests your ability to recognize a correct read-only property pattern in C#. A read-only property must expose only a get accessor that returns a backing value. Any presence of a set accessor (or infinite self-reference) violates the read-only or correctness requirement. Given Data / Assumptions: The property is named Length. We want a proper implementation that compiles and is read-only. Concept / Approach: A traditional read-only property uses a private backing field and provides only a get block that returns that field. Expression-bodied members are also valid modern syntax, but the question typically expects the classic full-property form. Beware of accidental recursion (return Length;) and invalid keywords such as “Readonly” in accessors (not C# syntax). Step-by-Step Solution: Option A: Uses a private field len and returns it in get. No set present → correct read-only property. Option B: Returns Length from inside Length, causing infinite recursion and stack overflow at runtime; incorrect. Option C: Has a set accessor → not read-only. Option D: “Readonly” is not a valid accessor modifier; does not compile. Option E: Although valid C# (expression-bodied read-only property), many exam banks expect the explicit get syntax; the canonical answer is A. Verification / Alternative check: Compiling Option A succeeds; reading Sample.Length returns the stored value of len. Attempts to assign Sample.Length will fail since no setter exists. Why Other Options Are Wrong: B: Recursive getter; incorrect. C: Not read-only by definition. D: Uses an invalid keyword in accessor position. E: Although valid in modern C#, the key expects the classic pattern; we retain A as the correct response. Common Pitfalls: Returning the property from itself; forgetting that “readonly” is a field modifier, not an accessor keyword. Final Answer: Option A is the correct read-only property implementation.

Question 2

C#.NET properties — Which option correctly implements a write-only property named Length in the Sample class?

Accepted Answer

Introduction / Context: In C#.NET, a property can be read-only, write-only, or read–write depending on whether it exposes a get accessor, a set accessor, or both. This question asks you to identify a valid write-only property implementation for a class named Sample, specifically for an integer property called Length. Given Data / Assumptions: The property must be write-only (no getter). The backing field can be a private int (commonly named len). Code must use correct C# syntax (no VB keywords, no recursion bugs). Concept / Approach: A write-only property in C# is declared by providing only the set accessor and omitting the get accessor. Inside set, the implicit parameter value represents the right-hand side of an assignment. The set body should assign value into a private backing field. Using the property name to assign itself causes infinite recursion and a stack overflow. Non-C# keywords like WriteOnly are invalid. Step-by-Step Solution: Identify a backing field: int len;Declare property with only set: public int Length { set { len = value; } }Ensure no get is present → write-only achieved.Avoid self-assignment (Length = value), which would recursively call the setter. Verification / Alternative check: Try compiling each option. The correct one compiles and allows statements like: var s = new Sample(); s.Length = 10; but forbids reading s.Length. Why Other Options Are Wrong: Option A: Setter assigns property to itself → infinite recursion. Option B: Provides get and set → not write-only. Option C: Uses invalid keyword WriteOnly → not C#. Option E: Not an implementation. Common Pitfalls: Confusing write-only with private set (private set still has a getter). Also, avoid naming clashes or recursive self-assignment in setters. Final Answer: class Sample { int len; public int Length { set { len = value; } } }

Question 3

C#.NET indexers — A Student class exposes an indexed property over an int[5]. Which usages are correct?

Accepted Answer

Introduction / Context: Indexers in C#.NET let an object behave like an array using the syntax obj[index]. They are instance members; C# does not support static indexers. This problem asks which example statements correctly use such an indexed property of a Student class that maps to a 5-element integer array. Given Data / Assumptions: Student defines an instance indexer taking one int parameter. We want valid C# syntax and semantics. Console.WriteLine can read from the indexer if a get accessor exists. Concept / Approach: Valid usage requires a Student instance (constructed with new) and then either assignment via the set accessor or reading via the get accessor. Static-like forms such as Student[3] are invalid. Also, constructs like Student.this are not C# syntax and should be rejected. Step-by-Step Solution: Statement 2: Create s; assign s[3] = 34 → valid (requires set accessor).Statement 3: Create s; read Console.WriteLine(s[3]) → valid if indexer has get.Statement 1: Student[3] = 34 → invalid (no static indexers).Statement 4: Console.WriteLine(Student[3]) → invalid for same reason.Statement 5: Student.this ... → invalid syntax in C#. Verification / Alternative check: Declare public int this[int i] { get; set; } inside Student, then compile and test statements 2 and 3 successfully. Why Other Options Are Wrong: 1 and 4: Attempt static indexer access → illegal in C#. 5: Nonsensical C# syntax. Common Pitfalls: Forgetting that indexers are instance-based; also mixing up property indexers with arrays declared at the type level. Final Answer: 2, 3

Question 4

C#.NET properties — Sample has a Length property with only a set accessor (write-only). Which statements compile and run?

Accepted Answer

Introduction / Context: A write-only property exposes only a set accessor and no get accessor. This question checks whether you can distinguish valid usage of such a property (assignment) from invalid usage (reading the value). Given Data / Assumptions: Sample.Length exists and has only set. No static property named Length is defined on the type. Standard C# property rules apply. Concept / Approach: You can assign to a write-only property on an instance, for example m.Length = 10;. Any attempt to read it (store into a variable, use on the right-hand side, or print it) will not compile because there is no get accessor. Static references like Sample.Length are also invalid unless the property is static (not stated). Step-by-Step Solution: Option E: Uses only the setter on an instance → valid.Option A: Attempts to read m.Length → requires get → invalid.Option B: Reads m.Length for the expression → invalid for lack of get.Option C: Tries to set a static property on the type → not given as static → invalid.Option D: Reads a static property → same issue. Verification / Alternative check: Define public int Length { set { ... } } and compile; only direct assignments are legal. Why Other Options Are Wrong: A/B/D: All require a getter. C/D: Also misuse type-qualified access with an instance property. Common Pitfalls: Confusing a write-only instance property with a static property; or assuming you can read a value after setting it. Final Answer: Sample m = new Sample(); m.Length = 10;

Question 5

C#.NET indexers — Student must support two-dimensional indexing as in:  Student s = new Student(); s[1, 2] = 35;  Which declaration enables this write-only indexer?

Accepted Answer

Introduction / Context: C# indexers can accept multiple parameters, enabling two-dimensional indexing syntax like s[i, j]. To make only assignments possible (write-only), the indexer should expose only a set accessor and omit a get accessor. Given Data / Assumptions: Student uses an internal 2D int array (int[,]) for storage. Goal: support s[1, 2] = 35; (write-only indexer). We use correct C# keywords and syntax. Concept / Approach: A valid two-parameter indexer has the form public int this[int i, int j] { set { a[i, j] = value; } }. The indexer’s declared type (int) is the value being assigned. No get accessor means reads like var x = s[1,2]; are disallowed. Step-by-Step Solution: Choose int[,] backing array for true 2D storage.Declare public int this[int i, int j] with only set.Inside set, assign value into a[i, j].Avoid invalid keywords like property or WriteOnly (VB terms). Verification / Alternative check: Compile the declaration and test with the given assignment; it compiles. Attempting to read s[1,2] will fail, as intended. Why Other Options Are Wrong: A/B: Use VB-style keywords and, in A, the backing array type is wrong (int[] with 2D size). D: Invalid indexer signature; missing parameters in the indexer declaration. Common Pitfalls: Confusing jagged arrays with rectangular arrays and mixing language keywords from VB into C#. Final Answer: class Student { int[,] a = new int[5, 5]; public int this[int i, int j] { set { a[i, j] = value; } } }

Question 6

C#.NET properties — To allow both assigning and printing acc.accountNo, how should Account.accountNo be declared?

Accepted Answer

Introduction / Context: The sample code performs both a write and a read: acc.accountNo = 10; and Console.WriteLine(acc.accountNo);. Therefore, the property must support assignment and retrieval. This is a standard read–write property in C#. Given Data / Assumptions: Account class has a property named accountNo. We want both setting and getting to compile and work. Concept / Approach: A C# property that can be both read and assigned must include a get accessor (to return the value) and a set accessor (to accept a value via the implicit parameter value). Omitting either accessor would disable the corresponding operation. Step-by-Step Solution: Provide a backing field, for example: private int _accountNo;Declare property: public int accountNo { get { return _accountNo; } set { _accountNo = value; } }Use: acc.accountNo = 10; Console.WriteLine(acc.accountNo); Verification / Alternative check: Compile with both accessors present and observe that both statements are valid. Remove get or set and see the relevant statement fail. Why Other Options Are Wrong: B: Read-only; assignment would fail. C: “normal accessors” is not a C# concept; get/set already cover it. D: Write-only; Console.WriteLine(acc.accountNo) would fail. E: There is a correct solution (A). Common Pitfalls: Confusing access modifiers (public/private) with accessors (get/set). You can also fine-tune with private set if external code should not assign. Final Answer: Declare accountNo with both get and set accessors.

Question 7

C#.NET indexers — What kinds of types can declare an indexer and thus be indexed like an array?

Accepted Answer

Introduction / Context: Indexers provide array-like access to instances. They are declared with the this keyword and one or more parameters. This question asks which categories in C# are eligible to define indexers. Given Data / Assumptions: C# supports indexers on classes, structs, and interfaces. Properties and functions themselves are not entities that “hold” indexers; they are members. Concept / Approach: An indexer is a member of a type. The C# language allows an indexer declaration inside a class or a struct, and an indexer signature can also be declared in an interface (with accessors but without bodies). Properties and methods are not containers of indexers; rather, indexers are peers to them. Step-by-Step Solution: Confirm eligibility: class → yes; struct → yes; interface → yes.Eliminate property/function: these are members, not types that declare indexers.Select (1, 3, 5) as the correct grouping. Verification / Alternative check: Write minimal declarations in each construct. For interfaces, use signatures like int this[int i] { get; set; } with no bodies. Why Other Options Are Wrong: B/D: Include “function” or “property,” which cannot contain indexers. C: Omits class even though it is valid. Common Pitfalls: Confusing an indexer with a property that returns an array; the latter is different and does not change indexing rules for the object itself. Final Answer: 1, 3, 5

Question 8

C#.NET properties — We want the statement stu.RollNo = 28 to fail for a Student object. How should the rollNo property be declared?

Accepted Answer

Introduction / Context: To prevent assignment like stu.RollNo = 28; from compiling, the property must be read-only to callers, i.e., it should have a getter but no public setter. This is a common pattern for identifiers. Given Data / Assumptions: Student exposes a property named rollNo. We want external code to read but not write it. Concept / Approach: A read-only property is declared with only a get accessor. Optionally, you could provide a private set if the class itself needs to assign internally while callers cannot. Either way, the public API should not expose a set accessor if the goal is to block assignment by outside code. Step-by-Step Solution: Define backing field: private int _rollNo;Property: public int RollNo { get { return _rollNo; } }(Optional) public int RollNo { get; private set; } to allow internal writes. Verification / Alternative check: Attempt to compile stu.RollNo = 28; → the compiler reports that there is no set accessor. Why Other Options Are Wrong: A/C: Include a set → the assignment would compile. B: Write-only prevents reading and is not the stated goal. E: There is a correct solution (D). Common Pitfalls: Exposing a public setter for identifiers can lead to invalid state; prefer immutability or controlled updates. Final Answer: Declare rollNo with only get accessor.

Question 9

C#.NET indexers — Which statements are correct about indexer definitions and interface indexers?

Accepted Answer

Introduction / Context: Indexers are property-like members that use parameters to provide array-style access to objects. Understanding their signatures and how they are declared on interfaces is essential for robust API design. Given Data / Assumptions: We evaluate five statements about indexers and their accessors. We consider both class/struct indexers and interface indexers. Concept / Approach: Indexer signature is defined by the number and types of parameters (and modifiers like ref/out, when applicable). Indexers resemble properties, but accessors take parameters. Interface members, including indexers, have no bodies, and their accessors cannot use access modifiers; they simply declare get and/or set. Step-by-Step Solution: Statement 1: True — signature is based on parameter list.Statement 2: True — they are property-like but parameterized.Statement 3: False — interface accessors cannot have modifiers on accessors themselves.Statement 4: True — accessibility must be at least as accessible as the indexer.Statement 5: False — interface members have no bodies. Verification / Alternative check: Define an interface with int this[int i] { get; set; }; note there are no bodies and no accessor-level modifiers. Why Other Options Are Wrong: Options C: Both statements selected are false. Option A: Mixes one true with two false statements. Option D: Omits statement 1; incomplete. Common Pitfalls: Trying to add public/private to interface accessors or writing method bodies inside interfaces (not allowed). Final Answer: 1, 2, 4

Question 10

C#.NET properties — Which statement correctly describes properties?

Accepted Answer

Introduction / Context: Properties are a core C# feature that encapsulate access to fields. The presence of get and/or set accessors determines whether a property is readable, writable, or both. This question asks for the correct generic statement about property capabilities. Given Data / Assumptions: We consider standard auto-properties or manually implemented properties. “Read only” means get without set; “write only” means set without get. Concept / Approach: A property can be read-only (get; no set;), write-only (set; no get;), or read–write (both get and set). A write-only property does not return a value; it simply accepts a value in its set accessor via the implicit parameter value. Any statement claiming a property is simultaneously read only and write only is self-contradictory. Step-by-Step Solution: Evaluate option B: Accurately describes that a property can be either read only or write only (or both, though not stated).Option A: Logically impossible to be both read only and write only.Option C: Inverts accessors (write-only would have set, not get).Option D: Says a write-only property “returns a value,” which it does not. Verification / Alternative check: Code examples: public int Id { get; } (read-only), public int Secret { set { ... } } (write-only), public int Count { get; set; } (read–write). Why Other Options Are Wrong: A/C/D contradict accessor semantics. Common Pitfalls: Assuming write-only properties are common; they are rare because callers cannot read back a value. Use scenarios include sensitive data, logging, or command-like APIs. Final Answer: A property can be either read only or write only.

Question 11

C#.NET properties — Sample has a Length property with only a get accessor (read-only). Which statements are valid?

Accepted Answer

Introduction / Context: A read-only property exposes only a getter. This permits reading the value but forbids assignment. Many .NET APIs use read-only properties for computed or immutable values. Given Data / Assumptions: Sample.Length has a get accessor and no set accessor. Length is an instance property unless otherwise specified. Concept / Approach: With only a getter, you can read the property into a local variable or print it using the instance. You cannot assign to it, nor can you use type-qualified syntax like Sample.Length unless the property is static. Therefore, the only correct option is to construct an instance and read the property value. Step-by-Step Solution: Create an instance: var m = new Sample();Read the value: int l = m.Length; → valid with get-only.Attempting assignment m.Length = 10 (A) → invalid (no set).Using m.Length on the right side of an assignment to itself (B) also requires set → invalid.Static access (D, E) would require a static property, which is not stated → invalid. Verification / Alternative check: Define public int Length { get { return _len; } } and compile. A and B produce compile-time errors, while C compiles. Why Other Options Are Wrong: A/B: Attempt to write to a read-only property. D/E: Use type-qualified access without a static property. Common Pitfalls: Confusing static and instance members; always access instance properties through an instance unless explicitly static. Final Answer: Sample m = new Sample(); int l; l = m.Length;

Question 12

C#.NET — Properties and accessibility: make Console.WriteLine(emp.age) fail by design. Scenario: An Employee class exposes a property named age. There is a reference emp to an Employee object. You want the statement below to fail at compile time (i.…

Accepted Answer

Introduction / Context: This question examines how C#.NET properties control read/write accessibility. The goal is to make a read attempt Console.WriteLine(emp.age) fail at compile time, so you must deny the public getter while still possibly allowing writes. Given Data / Assumptions: Class: Employee. Property: age. Access attempt: read via Console.WriteLine(emp.age). We want a compile-time error on reading. Concept / Approach: In C#, a property can expose a get (read) accessor, a set (write) accessor, both, or neither (with restricted access). A write-only property is made by providing only set and omitting get (or making get less accessible). Step-by-Step Solution: To block reads, remove or restrict the get accessor. A write-only property signature looks like: public int age { set { /* validate and assign */ } } Trying to read emp.age causes a compile-time error because get is not defined or not accessible. Verification / Alternative check: Try compiling with only set present: any read usage fails, while writes like emp.age = 30; compile. Why Other Options Are Wrong: A (get only) permits reading, so Console.WriteLine(emp.age) compiles. C exposes both read and write, so reading works (no failure). D “extra accessor” is not a C# concept; only get and set exist. E is wrong because a valid solution exists. Common Pitfalls: Confusing access modifiers on get/set with presence of accessors. Even with access modifiers, any accessible get will allow reading. Final Answer: Declare the age property with only a set accessor (write-only property).

Question 13

C#.NET — Using an instance property with get and set: which statements compile and run? Assume class Sample defines a non-static property Length with both get and set accessors. Which of the following statements are valid?

Accepted Answer

Introduction / Context: The problem tests whether you can distinguish between instance versus static property access and evaluate valid reads/writes when a property has both get and set accessors. Given Data / Assumptions: Length is an instance property of Sample with get and set. Statements: 1) Sample.Length = 20; 2) Sample m = new Sample(); m.Length = 10; 3) Console.WriteLine(Sample.Length); 4) Sample m = new Sample(); int len; len = m.Length; 5) Sample m = new Sample(); m.Length = m.Length + 20; Concept / Approach: Non-static properties must be accessed through an instance. Reads require get; writes require set. Using the type name for a non-static property does not compile. Step-by-Step Solution: 1) Invalid: attempts static access; Length is not static. 2) Valid: instance write via m.Length = 10. 3) Invalid: attempts static read; Length is not static. 4) Valid: instance read into len. 5) Valid: reads then writes on the same instance. Verification / Alternative check: Marking Length as static would change 1 and 3, but the question specifies an instance property, so the provided evaluation stands. Why Other Options Are Wrong: Any option including 1 or 3 is invalid because they rely on static access. Common Pitfalls: Confusing static and instance members; assuming properties behave differently than fields with respect to static access. Final Answer: 2, 4, 5

Question 14

C#.NET — True or False: A property can be declared inside a class, a struct, or an interface.

Accepted Answer

Introduction / Context: This statement checks your knowledge of where properties may be declared in C#. Properties are type members and can appear in several kinds of types. Given Data / Assumptions: We consider declaration sites for properties in C#. Concept / Approach: Properties are members of types, not namespaces or methods. C# allows properties in classes, structs, and interfaces. Interfaces declare property signatures (no bodies); classes/structs provide implementations. Step-by-Step Solution: Class: property with get/set bodies allowed. Struct: property with get/set bodies allowed (with struct rules). Interface: property signatures allowed (no implementation in classic interfaces). Verification / Alternative check: Attempting to declare a property in a namespace or inside a method causes a compile-time error. Why Other Options Are Wrong: They inappropriately restrict where properties can be declared. Common Pitfalls: Confusing interface property signatures (no bodies) with class/struct implementations. Final Answer: True

Question 15

C#.NET — Which statement about properties is correct?

Accepted Answer

Introduction / Context: The question probes what a property truly is under the hood in C#.NET and clarifies common misconceptions about accessors and overloading. Given Data / Assumptions: We compare statements about accessors, overloading, and nature of properties. Concept / Approach: A property compiles to accessor methods (get and/or set). It can be read-only (get only), write-only (set only), or read-write (both). Overloading properties by parameter list is not applicable (that is what indexers are for), and you cannot have two properties with the same name differing only by type. Step-by-Step Solution: A is false: properties can be read-only or write-only. B is generally true (properties are not overloaded like methods), but the most broadly accurate and explanatory statement is C. C is correct: properties are syntactic sugar for accessor methods that expose field-like syntax. D is false: a property can be read-write (both accessors). Verification / Alternative check: Inspect IL: a property named P compiles to methods get_P and/or set_P. Why Other Options Are Wrong: They either overconstrain accessors or mischaracterize property behavior; C states the core truth. Common Pitfalls: Confusing properties with indexers (which do take parameters) or assuming accessor presence is mandatory. Final Answer: Properties of a class are actually methods (get/set) that behave like data members.

Question 16

C#.NET — True or False: A property can be declared inside a namespace or inside a procedure (method).

Accepted Answer

Introduction / Context: This statement checks whether you know the valid declaration places for a property in C#. Given Data / Assumptions: We consider namespace scope and method (procedure) scope. Concept / Approach: Properties are members of types (class, struct, interface). They cannot be declared directly in a namespace, nor inside a method body. Attempting either results in a compile-time error. Step-by-Step Solution: Declare properties within a type definition only. Disallow property declarations at namespace or method scope. Verification / Alternative check: Try to compile a property directly under a namespace; the compiler rejects it. Why Other Options Are Wrong: They suggest illegal declaration contexts. Common Pitfalls: Confusing top-level statements or records with property placement rules. Final Answer: False

Question 17

C#.NET — Implementing a bounds-checked indexed property (indexer) for a 5-element scores array. Goal: The indexer should print "Invalid Index" when the user accesses beyond the last valid index.

Accepted Answer

Introduction / Context: Indexers in C#.NET allow array-like access to class or struct instances. Here, the Student indexer should both read and write scores while warning when the index exceeds the allowed range. Given Data / Assumptions: scores is an int[5]. Valid indices are 0..4. Requirement: print "Invalid Index" when out of bounds. We accept a simple check (index < 5); in production, include index >= 0 as well. Concept / Approach: A well-formed indexer includes both get and set accessors when read-write access is needed. Each accessor should validate the index and either proceed or report an error state. Step-by-Step Solution: Choose an indexer with both get and set accessors. In get: return scores[index] if valid; otherwise print a message and return a safe default (e.g., 0). In set: assign scores[index] if valid; otherwise print a message. Verification / Alternative check: Testing with index = 4 works; index = 5 prints "Invalid Index". Adding index < 0 checks further hardens the code. Why Other Options Are Wrong: A: Write-only; lacks a getter. C: Read-only; lacks a setter. D: Accessor bodies are swapped/incorrect and will not compile. E: Incorrect because a correct implementation exists (option B). Common Pitfalls: Forgetting the lower-bound check or mixing up get/set logic bodies. Final Answer: Option B (read-write indexer with bounds check) is correct.

Properties Questions