Questo sito utilizza i cookies, anche di terze parti. Per continuare a navigare sul sito è necessario accettare l'utilizzo dei cookies.
Ti invitiamo a leggere la Cookies Policy.

In order to improve user's experience this site uses cookies. To keep on browsing the site you must accept cookies
by pressing "Accetto" button here on the right. More info on Cookies Policy page (italian).
 
Bitstream I.T. solutions
Corso del Popolo 133
30172 Mestre (VE)
Email: info@bitstream.it
Tel.: +39.333.6416400
©2017 - P.Iva 03509290270

Cookie policy

Dev Life: IIS Express supporta anche Classic ASP

Pubblicato il 12/04/2016

A volte capita anche ai Dev.
 
Stiamo migrando una vecchia applicazione realizzata con tecnologia Microsoft Classic ASP e DB Access in una nuova che utilizza MVC + Entity Framework e abbiamo pensato di poter fare la cosa in modo graduale. Abbiamo quindi creato un nuovo progetto in Visual Studio 2015 copiandovi tutti i file dell’applicazione originale, convinti che, per testarla, avremmo dovuto installare la versione completa di IIS e invece… Bam! La versione IIS Express, installata di serie con Visual Studio, supporta nativamente Classic ASP. Tutto ha funzionato al primo colpo, il linguaggio VBScript viene interpretato correttamente e persino i componenti ActiveX vengono istanziati senza particolari problemi.
 
Di seguito riporto alcuni link utili per conoscere le caratteristiche di IIS Express:
E IIS Express supporta anche PHP!
 
Non solo, con qualche workaround è anche possibile attivare il debug, come indicato in questo post.
 
Non l’avrei mai detto…Anche ai Dev capitano delle piacevoli soprese…
 
Altra cosa interessante, abbiamo anche scoperto che ADO DB (la tecnologia di accesso ai dati utilizzata da Classic ASP) è compatibile con il provider OLE DB di SQL Server Native Client. Esso consente un collegamento veramente veloce ai dati di SQL Server e soprattutto consente di utilizzare MARS (Multiple Active Result Set) e i nuovi tipi di dato introdotti da SQL 2005 in poi.
 
E’ sufficiente preparare una stringa di connessione simile a questa:
 
ConnectionString =  "Provider=SQLNCLI11;" _
& "Server=(local);" _
& "Database=NomeDB;" _
& "Integrated Security=SSPI;" _
& "DataTypeCompatibility=80;" _
& "MARS Connection=True;"
 
Nella quale è importante la presenza della proprietà “DataTypeCompatibility=80”.
 
Recita infatti MSDN:
Le applicazioni ADO esistenti possono accedere a valori XML, UDT, nonché di campi binari e di testo di grandi dimensioni ed eseguirne l'aggiornamento utilizzando il provider SQLOLEDB.I nuovi tipi di dati varchar (max)nvarchar (max) e varbinary (max) di grandi dimensioni vengono restituiti rispettivamente come i tipi ADO adLongVarCharadLongVarWChar e adLongVarBinary.Le colonne XML vengono restituite come adLongVarChar, mentre le colonne con tipo definito dall'utente vengono restituite come adVarBinary.Se tuttavia, si utilizza il provider OLE DB di SQL Server Native Client (SQLNCLI11) anziché SQLOLEDB, è necessario assicurarsi di impostare la parola chiave DataTypeCompatibility su "80" in modo da consentire la corretta esecuzione del mapping dei nuovi tipi di dati ai tipi di dati ADO.
 
Non c’è che dire, questa retro-compatibilità del provider mi è piaciuta molto e ci ha consentito di iniziare una migrazione a step intermedi della vecchia applicazione, facendo convivere temporaneamente Classic ASP ed MVC, ADO DB ed Entity Framework.
 
Davvero una piacevole sorpresa!
 


AUTORE DEL POST

Andrea Gorin

Andrea Gorin

Web tech specialist, Analyst, .NET Senior Developer, SQL Server specialist, Microsoft Certified Professional Small Business Solutions