Posso modificare un campo di sola lettura privato in C # utilizzando la reflection?

Mi chiedo, dal momento che molte cose possono essere fatte usando la riflessione, posso cambiare un campo di sola lettura privato dopo che il costruttore ha completato la sua esecuzione?
(nota: solo curiosità)

public class Foo
{
 private readonly int bar;

 public Foo(int num)
 {
  bar = num;
 }

 public int GetBar()
 {
  return bar;
 }
}

Foo foo = new Foo(123);
Console.WriteLine(foo.GetBar()); // display 123
// reflection code here...
Console.WriteLine(foo.GetBar()); // display 456

Puoi:

typeof(Foo)
   .GetField("bar",BindingFlags.Instance|BindingFlags.NonPublic)
   .SetValue(foo,567);

La cosa ovvia è provarlo:

using System;
using System.Reflection;

public class Test
{
    private readonly string foo = "Foo";

    public static void Main()
    {
        Test test = new Test();
        FieldInfo field = typeof(Test).GetField
            ("foo", BindingFlags.Instance | BindingFlags.NonPublic);
        field.SetValue(test, "Hello");
        Console.WriteLine(test.foo);
    }        
}

Funziona bene. (Java ha regole diverse, interessante: devi impostare esplicitamente Fieldche sia accessibile e funzionerà comunque solo per i campi di istanza.)

Sono d'accordo con le altre risposte in quanto funziona in generale e soprattutto con il commento di E. Lippert che questo non è un comportamento documentato e quindi non un codice a prova di futuro.

Tuttavia, abbiamo notato anche un altro problema. Se stai eseguendo il codice in un ambiente con autorizzazioni limitate, potresti ottenere un'eccezione.

Abbiamo appena avuto un caso in cui il nostro codice funzionava bene sulle nostre macchine, ma abbiamo ricevuto un messaggio VerificationExceptionquando il codice è stato eseguito in un ambiente limitato. Il colpevole era una chiamata di riflessione al setter di un campo di sola lettura. Ha funzionato quando abbiamo rimosso la restrizione di sola lettura di quel campo.

Hai chiesto perché vorresti rompere l'incapsulamento in quel modo.

Uso una classe helper di entità per idratare le entità. Questo utilizza la riflessione per ottenere tutte le proprietà di una nuova entità vuota e abbina il nome della proprietà / campo alla colonna nel gruppo di risultati e lo imposta usando propertyinfo.setvalue ().

Non voglio che nessun altro sia in grado di modificare il valore, ma non voglio nemmeno dedicare tutto lo sforzo ai metodi di idratazione del codice personalizzati per ogni entità.

Molti dei miei processi memorizzati restituiscono set di risultati che non corrispondono direttamente a tabelle o viste, quindi gli ORM di generazione del codice non fanno nulla per me.

Un altro modo semplice per farlo utilizzando unsafe (oppure potresti passare il campo a un metodo C tramite DLLImport e impostarlo lì).

using System;

namespace TestReadOnly
{
    class Program
    {
        private readonly int i;

        public Program()
        {
            i = 66;
        }

        private unsafe void ForceSet()
        {
            fixed (int* ptr = &i) *ptr = 123;
        }

        static void Main(string[] args)
        {
            var program = new Program();
            Console.WriteLine("Contructed Value: " + program.i);
            program.ForceSet();
            Console.WriteLine("Forced Value: " + program.i);
        }
    }
}

La risposta è sì, ma ancora più importante:

Perché dovresti volerlo? Rompere intenzionalmente l'incapsulamento mi sembra un'idea orribilmente cattiva.

Usare la riflessione per modificare un campo di sola lettura o costante è come combinare la Legge delle conseguenze indesiderate con la Legge di Murphy .

Non farlo.

Ho appena passato una giornata a correggere un bug surreale in cui gli oggetti potrebbero non essere del loro tipo dichiarato.

La modifica del campo di sola lettura ha funzionato una volta. Ma se provassi a modificarlo di nuovo, otterrai situazioni come questa:

SoundDef mySound = Reflection_Modified_Readonly_SoundDef_Field;
if( !(mySound is SoundDef) )
    Log("Welcome to impossible-land!"); //This would run

Quindi non farlo.

Questo era nel runtime Mono (motore di gioco Unity).

Voglio solo aggiungere che se hai bisogno di fare queste cose per i test unitari, puoi usare:

A) La classe PrivateObject

B) Avrai ancora bisogno di un'istanza PrivateObject, ma puoi generare oggetti "Accessor" con Visual Studio. Procedura: rigenerare funzioni di accesso private

Se imposti campi privati ​​di un oggetto nel tuo codice al di fuori del test unitario, sarebbe un'istanza di "odore di codice" Penso che forse l'unico altro motivo per cui vorresti farlo è se hai a che fare con una terza parte libreria e non puoi modificare il codice della classe di destinazione. Anche in questo caso, probabilmente vorrai contattare la terza parte, spiegare la tua situazione e vedere se non andranno avanti e cambieranno il loro codice per soddisfare le tue necessità.