reg.exe add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4B2WU" /v OptIn /t REG_DWORD /d 1 /f

L'aggiornamento non verrà scaricato, però, se avete già altre versioni beta del framework 4 installate sulla vostra macchina.

Link: Fonte

I diversi pattern sono raggruppati e presentati al lettore secondo questa tassonomia:

Presentation Logic

• Model-View-Controller (MVC)
• Model-View-Presenter (MVP)
• Use Case Controller

Host or Behavioral

• Command
• Publish-Subscribe / Observer
• Plug-in / Module / Intercepting Filter

Structural

• Service Agent / Proxy / Broker
• Provider / Adapter

Creational

• Factory / Builder / Injection
• Singleton

Persistence

Repository

Sono certo che potrete trovare anche voi queste due pagine interessanti. Buona lettura!

Link: ASP.NET Patterns every developer should know

Durante questa fase la risorsa è realmente esistente all'URL in cui si troverà, ma la sua visualizzazione è limitata al solo staff, per le ragioni che ho spiegato prima. Per evitare che qualche utente malizioso possa andare alla ricerca di queste risorse facciamo in modo che, se il visitatore manca delle necessarie autorizzazioni non visualizzi un generico errore di accesso, ma un bel 404.

Fortunatamente non c'è alcun bisogno di andare a smanettare con la sezione customErrors del web.config, è sufficiente generare una HttpException:

Il runtime di ASP.NET rileverà l'eccezione e si occuperà del redirect alla opportuna pagina per l'errore 404.

Io mi sono fatto l'idea che c# è un linguaggio per lavorare, mentre ruby è ancora un qualcosa da smanettoni... Qui la fonte ed altre interessanti opinioni.

Di seguito un rapido esempio di utilizzo:

<debuggerBrowsable(DebuggerBrowsableState.Never)> _
Public Shared Function getGroup(ByVal idGroup As String) As SlotGroup

Per i dettagli date uno sguardo su MSDN

L'idea migliore, più precisa ed efficiente, è quella di affidarsi a System.Diagnostics.Stopwatch: se lo avete già realizzato, usando però il "classico" DateTime e qualche sottrazione per ottenere un TimeSpan, sarebbe il caso che provvediate a rimpiazzare tutto il vostro accrocchio.

Stopwatch infatti è realizzata usando chiamate ad API di basso livello, con un overhead decisamente minore rispetto a qualsiasi metodo di .NET. Inoltre se la vostra configurazione hardware e software lo permette, potrete usufruire di un contatore ad alta precisione.

dim watch as new System.Diagnostics.Stopwatch()

watch.Start()

 

[...]

 

watch.Stop()

literal.Text = "Pagina generata in " + watch.Elapsed.ToString() + " secondi"

Beh, fatemi sapere quanti millisecondi avete recuperato!

La libreria contiene 117 classi, ed è frutto del lavoro di James Newtonking, che ha deciso di rilasciarla con tanto di codice sorgente.
Io l'ho scaricata e messa sul desktop, appena posso giuro che gli do un'occhiata

I problemi principali della migrazione potranno essere dati da AWStats e dagli URL della vecchia versione, che rimangono ancora validi ed indicizzati in tutti i motori di ricerca: in particolare quest'ultima problematica è quella che potrebbe causare più ripercussioni... errori in questo senso potrebbero mandare a monte anni di indicizzazione dei motori (al solo pensiero mi vengono i brividi )

Ecco come credo di aver risolto il problema:

Visto che T&C è praticamente costituito per il 95% da contenuti dinamici, ho dovuto prevedere dei redirect "dinamici", che reindirizzassero alle nuove pagine conservando anche i parametri inviati attraverso l'url.

Ho creato un modellino generale di questi redirect, realizzati in ASP Classic, che è fatto così come segue:

<%
REDIR_PATH = "nuovapagina.aspx"

if len(request.querystring) > 0 then
response.redirect(REDIR_PATH & "?" & request.querystring)
else
response.redirect(REDIR_PATH)
end if
%>

Se si ha la cura di conservare nelle nuove pagine gli stessi parametri delle vecchie, è sufficiente cambiare la variabile alla prima riga della pagina; i pochi parametri di cui ho cambiato il nome "funzionano" nella nuova versione sia con il vecchio che con il nuovo metodo (ovviamente fintanto che non verranno indicizzate le nuove versioni delle pagine)

Per l'upgrade definitivo oramai è solamente questione di ore, un paio di giorni al massimo... Iniziate ad incrociare le dita per me

Vista la facilità di portare codice dal VbScript di ASP in VB.NET ho scelto questo linguaggio, nonostante il C# sia evidentemente più elegante e meno prolisso nei costrutti.

C'è poi da dire che il Framework.Net permette la commistione di linguaggi (sebbene sia necessario separare i diversi "dialetti" in assembly diversi), quindi in futuro potrei realizzare migrazioni parziali e/o pezzi di sito o librerie interne senza difficoltà in C# con poco lavoro aggiuntivo.

Però ora devo ammettere che le idee non sono più così nitide e definite...

Durante questi mesi ho dovuto però ammettere che VB.NET ha due punti notevoli a suo favore sul C#:

• Visual Basic.Net non è case-sensitive: l'interazione uomo-macchina ci insegna che un dialogo tra una macchina e l'utente deve essere tollerante verso l'errore, la mia opinione è che nonostante i programmatori siano notoriamente più intimi con le macchine dell'utente medio, sia comunque la macchina che si debba adattare al programmatore.
  E' frustrante e fa perdere un sacco di tempo correggere maiuscole in minuscole o viceversa: a lungo andare ci si può anche fare l'abitudine (ne ho usati tanti anch'io di linguaggi case sensitive) ma eliminare la problematica riduce senza dubbio il carico cognitivo del programmatore, che può quindi concentrarsi maggiormente sul codice che sta scrivendo
• I programmi in C# devono essere compilati per controllare se compilano, quelli in VB.NET no: quando mi son trovato a scrivere in C# la prima cosa che ho notato è che l'ambiente di sviluppo non ti segnala il problema se prima non compili il progetto. La prima cosa che si impara e la scorciatoia per compilare, e poi via: un pò di codice e CTRL+SHIFT+B, e via così fino a consumare questi tre tasti sulla tastiera...
  VB.NET è in grado invece di dirti in anticipo se qualcosa non va, effettuando una precompilazione in background mentre si scrive il codice.

E' la seconda peculiarità che mi fa apprezzare davvero tanto il VB, tanto da farmi pensare di spostarlo sopra al C# in cima alla lista dei miei linguaggi preferiti in .NET.

Quelle adorabili righe ondulate azzurre o verdi che ti segnalano quando stai sbagliando qualcosa, stai chiamando un metodo che non esiste, eccetera eccetera... quanto tempo mi han fatto risparmiare!

PS: Resharper risolve questo secondo problema per C#, alla modica cifra di 349USD

Per utilizzare queste collection templatizzate è necessiario importare il namespace System.Collections.Generic, che può essere importato automaticamente scrivendo quando segue nel web.config

<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">

  <system.web>

    <pages>

      <namespaces>

        <add namespace="System.Collections.Generic" />

      </namespaces>

    </pages>

  </system.web>

</configuration>

L'impaginazione non è delle migliori, causa questo sistema di publishing che devo ancora comprendere a pieno... il concetto però credo sia chiaro, no?