Interessante opportunità di lavoro su Milano:
importante azienda cerca programmatore/programmatrice senior C# con buona conoscenza .NET Framework, ASP .NET e Oracle.
Offresi contratto di assunzione e/o di consulenza.
Titolo preferenziale: conoscenza del .Framework 3.5 e di C# 3.0.
Le persone eventualmente interessate possono contattarmi attraverso la form contact di questo blog.
Il controllo TextBox di una web application dispone della proprietà ReadOnly che, ovviamente, impedisce l’interazione dell’utente con il controllo quando è impostata a True.
Ma c’è un particolare importantissimo da considerare: a partire dalla versione 2.0 del .NET Framework il contenuto di un textbox in modalità “ReadOnly” è inviato al server durante un postback della pagina, ma il server ignora questo valore; in altre parole il contenuto del textbox viene perso durante un postback. Questo comportamento mira ad impedire attacchi alla sicurezza, che potrebbero modificare un valore che dovrebbe essere mantenuto inalterato.
La perdita del valore del textbox può essere inaccettabile in certi contesti applicativi e potrebbe essere necessario applicare il comportamento in essere prima del Framework 2.0. Per far ciò è necessario impostare la proprietà ReadOnly come attributo del controllo, in questo modo:
TextBox1.Attributes.Add("readonly","readonly")
e non impostando a True la relativa proprietà.
Così facendo il valore del textbox (ovvero la sua proprietà Text) viene inviato al server durante il postback ed è altresì disponibile per l’elaborazione.
UPDATE: questo aggiornamento è, diciamo così, dovuto: il “copyright” di questa scoperta che ha portato via parecchio tempo prima di venirne a capo non è mio ma della mia collega di lavoro Ines. Io ho solo raccolto il troubleshooting per aiutare altri programmatori come un tempo altri programmatori hanno aiutato me
Questa informazione me la annoto perchè sicuramente utile. Avevo già parlato precedentemente delle sottili e a volte subdole differenze esistenti tra il linguaggio VB .NET e C#, differenze che possono anche riguardare il comportamento di Visual Studio, quindi non strettamente legate a costrutti di programmazione o alla semplice sintassi.
Questa differenza però mi sorprende parecchio e non riesco a comprenderne a fondo il motivo. Presto detto: se si utilizza l’incremento automatico nel numero di versione in un assembly (per intenderci quando impostiamo questa riga
[assembly: AssemblyVersion("1.0.*")]
nel file AssemblyInfo, otteniamo un risultato differente a seconda se l’assembly è scritto in VB .NET o in C#. Se è scritto in VB .NET l’incremento automatico è operato solo alla prima build, mentre alle successive build sulla stessa istanza di Visual Studio il numero di versione resta invariato (se l’assembly viene ricompilato in una differente istanza di Visual Studio il numero di versione è incrementato).
Se, viceversa, l’assembly è scritto in C#, ogni build produce un incremento automatico del numero di versione. Appena mi è possibile proverò questa funzionalità, anche se la documentazione MSDN è abbastanza chiara.
Questo comportamento differente in funzione del linguaggio avrà anche una sua logica, ma non è sicuramente immediatamente chiara.
Inoltre, non condivido la motivazione che la documentazione MSDN produce per spiegare il tutto: poichè il numero di versione è inserito solo a titolo informativo in un assembly non firmato con uno strong name, il problema non si pone. Viceversa, se l’assembly deve essere dotato di strong name, viene sconsigliato l’uso dell’incremento automatico, in VB .NET chiaramente, perchè in C# non c’è alcuna controindicazione.
Come già comunicato qui ho deciso di spostare il feed del mio blog su FeedBurner, un ottimo servizio esterno che consente tra l’altro di ottenere gratuitamente servizi aggiuntivi, e soprattutto di svincolare il proprio blog dal proprio feed rss “interno”, permettendo quindi di centralizzarlo con indubbi benefici, es. la possibilità di pubblicare i propri contenuti anche su altri blogs.
Chi volesse sottoscrivere il mio blog dovrà dunque utilizzare il nuovo feed disponibile all’url: http://feeds.feedburner.com/mauriziotammacco
Non sono un sistemista, nè lo saro mai, ma anche occupandosi solo di sviluppo è utile avere sottomano tools e/o tips prettamente sistemistici che possono essere sicuramente utili.
Eccone uno:
1) netsh interface ip set address “Connessione alla rete locale (LAN)” static 10.xxx.xxx.xxx 255.255.255.0 10.xxx.xxx.xxx 0
2) netsh interface ip set dns “Connessione alla rete locale (LAN) ” static 10.xxx.xxx.xxx primary
3) netsh interface ip add dns “Connessione alla rete locale (LAN)” 10.xxx.xxx.xxx
4) netsh interface ip show config “Connessione alla rete locale (LAN) “
I comandi sopraelencati, messi opportunamente in un file .bat, permettono di settare al volo la configurazione di una scheda di rete ben precisa, ovvero quella la cui descrizione è “Connessione alla rete locale (LAN)”, nell’esempio.
Ovviamente basta cambiare la descrizione della scheda per puntarne un’altra.
La prima riga del batch setta rispettivamente l’indirizzo ip, la subnetmask ed il default gateway. La seconda riga imposta l’indirizzo ip del server dns primario, mentre la terza quello del dns secondario. La quarta riga visualizza a console le impostazioni della scheda appena settate.
Questo vale quando vogliamo settare indirizzi ip ben specifici. E se invece vogliamo che la scheda sia impostata con indirizzi ip ottenuti da un server DHCP ?
Ecco i comandi:
1) netsh interface ip set address “Connessione alla rete locale (LAN)” dhcp
2) netsh interface ip set dns name=”Connessione alla rete locale (LAN)” source=dhcp
3) netsh interface ip show config “Connessione alla rete locale (LAN)”
Per la descrizione della scheda vale quanto già detto. La prima riga imposta la modalità DHCP. La seconda imposta la modalità DHCP per i server DNS, mentre la terza mostra a console la nuova configurazione.
Finalmente ho trovato il tempo per aggiornare la versione di Community Server con cui gira questo blog; ho infatti effettuato un aggiornamento “doppio” passando dalla versione 1.1 alla versione 2007.1. L’aggiornamento era d’obbligo per via delle nuove feature della versione 2007. Ma non è stato semplice, anche per via della connessione Internet a mia disposizione (una lentissima UMTS).
A proposito, questo è l’ultimo post scaricabile attraverso il consueto rss feed; ho deciso infatti di usufruire del servizio messo a disposizione da FeedBurner, un servizio esterno che eroga feed rss, fornendo nel contempo altri utili servizi. Nel prossimo post comunicherò il nuov url da cui è possibile sottoscrivere questo blog.