Come molti di voi già sanno ieri è uscito Visual Studio 2010 RC1 per gli abbonati msdn. Potete trovare un articolo esauriente sul blog di ScottGu. Questa release, più che nuove feature, dovrebbe apportare notevoli migliorie sul lato performace.
In effetti, dai primi test effettuati, l’apertura e l’utilizzo di una soluzion di circa 80 progetti risulta essere molto più veloce della beta2. La nuova interfaccia WPF ora sembra rispondere meglio ai comandi e anche lavorando con due monitor le finestre e i menù si attivano molto più velocemente di prima. O almeno questa è la mia sensazione dopo un pomeriggio di prove. :-D
E ora la nota dolente. Purtroppo anche la RC1 (come la Beta2) soffre di un fastidiosissimo bug che non permette di compilare correttamente un progetto WinForm. L’errore che mostra è:
The specified task executable "ResGen.exe" could not be run. The filename or extension is too long
Warning:
The command-line for the "ResGen" task is too long. Command-lines longer than 32000 characters are likely to fail. Try reducing the length of the command-line by breaking down the call to "ResGen" into multiple calls with fewer parameters per call.
I have been able to build other projects without any problems. I cannot yet reproduce the issue on any other projects.
Se anche a voi capita un problema simile gli sviluppatori Microsoft suggeriscono un paio di workaround che sono:
- switch to target 4.0. Obviously that isn't a workaround for a serious project, but it fixes it for experimentation.
- I didn't try this. Go into <fxdir>\microsoft.common.targets and find the GenerateResource task. Make a backup of the file first. Change the Condition attribute to
Condition="'%(EmbeddedResource.Type)' == 'Resx' and '%(EmbeddedResource.GenerateResource)' != 'false' and '%(EmbeddedResource.Identity)' != ''"
Per niente convincenti. Vabbè dopotutto è un RC1 no?
Dopo un lungo periodo di silenzio ritorno a scrivere sul blog di ugi un post dedicato ad una mia recente esperienza. Ovvero il passaggio da CruiseControl.Net a TeamCity. Devo dire che il passaggio è stato rapido e indolore. TeamCity 4.5 si installa velocemente e senza troppo problemi. Dopo un breve sguardo alla documentazione ho migrato il database dal formato nativo a SQL Server senza intoppi. La configurazione di nuovi progetti è veramente semplice e il supporto nativo alle solution VS2005 e VS2008 ne semplifica enormemente la configurazione.
In generale TeamCity è risultato decisamente superiore rispetto a CruiseControl.net, sia in termini di funzionalità che di usabilità. Grazie all’architettura ad Agent è possibile distribuire il carico di lavoro su n server. Il tutto per rendere più efficiente e veloce il processo di build. Un enorme punto a favore di TeamCity è l’interfaccia web che ti permette di configurare ogni aspetto, anche quello più complesso, in modo semplice e immediato. L’interfaccia web utilizza AJAX in modo massivo e questo rende tutto molto più fluido e funzionale. Insomma no more XML!
In fine la licenza. TeamCity è un prodotto proprietario della JetBrains (la stessa di ReSharper). Nonostante questo TeamCity Professional è scaricabile gratuitamente e supporta fino a 20 utenti con 20 build configuration e al massimo 3 agent registrati. Per un team di medie dimensioni come il mio è più che sufficiente.
Da qualche giorno sto lavorando all’integrazione tra il nostro prodotto in .net e un documentale scritto in Visual Basic 6. L’integrazione si posa fondamentalmente su una libreria COM che mi permette di accedere alle funzionalità base dell’applicativo. A parte le solite magagne e gli sbattimenti dell’interop, da qualche giorno Visual Studio mi avverte che:
Warning 1 Type library importer has encountered an interface not derived from IUnknown: '_HiddenInterface'.
A quanto pare gli oggetti COM o una delle sue interfacce non implementano correttamente l’interfaccia IUnknown, generando di conseguenza il warning in .net. Il problema è che non ho a disposizione i sorgenti della libreria, e una richiesta di modifica direttamente al produttore è impensabile. Mi domando se esistono soluzioni alternative a questo problema.
Oggi mi è capitata una cosa nuova. Ho creato in sql server una table-valued function con un parametro di tipo datetime. Nel parametro ho impostato il default a GETDATE in modo che se un client chiama la funzione con il default viene impostato la data corrente.
La function è fatta grosso modo così:
CREATE FUNCTION MyFunction
(
@DataValidita AS DATETIME = GETDATE
)
RETURNS TABLE
AS
RETURN
(
SELECT
T.Colonna
FROM
dbo.Tabella T
WHERE
T.DataValidita = @DataValidita
)
Mentre la chiamata cosà:
SELECT * FROM dbo.MyFunction(default);
Ma mentre nel primo caso, cioè nella creazione della function, sql server non mi ritorna errori, nel secondo caso, cioè nella chiamata, mi comunica in modo categorico che:
Msg 241, Level 16, State 1, Line 1
Conversion failed when converting datetime from character string.
Questo è dovuto al fatto che il parametro @DataValidita assume un valore particolare che non mi è chiaro. Se però eseguo la chiamata con un valore, allora tutto va a buon fine. Dopo qualche ricerca ho capito che nelle function non è possibile utilizzare funzioni non deterministiche come appunto risulta essere GETDATE per i valori di default di un parametro. Dato che la valorizzazione alla data corrente per il parametro @DataValidita è un requisito nel caso in cui la funzione sia chiamata con il default mi sono inventato una soluzione alternativa, in questo modo:
CREATE FUNCTION MyFunction
(
@DataValidita AS DATETIME = NULL
)
RETURNS TABLE
AS
RETURN
(
SELECT
T.Colonna
FROM
dbo.Tabella T
WHERE
T.DataValidita = CASE
WHEN (@DataValidita IS NULL) THEN GETDATE()
ELSE @DataValidita
END
)
Probabilmente non è la soluzione più elegante, ma questo piccolo trucchetto mi ha risolto il problema. Domanda, esistono soluzioni alternative e magari più eleganti?
Technorati Tags:
SQL Server
Quando penso a Visual Studio penso subito a Resharper. Considero quest’ultimo ormai come parte integrate dell’ide di sviluppo. Un add-on direi più che essenziale nella produttività quotidiana. Ebbene, con il recente rilascio della beta 1 di Visual Studio 2010 potremmo, tra pochi giorni, provare la beta del nuovo Resharper 5.0. Sul blog del team di sviluppo, infatti, possiamo ammirare i primi screenshot dell’ultima versione già integrata in VS2010 in attesa di una preview prevista per giugno.
Un saluto a tutta la grande community UgiDotNet che seguo con interesse da tanto tempo. Nella migliore tradizione questo è il primo di, spero, una lunga serie di post tematici. Spero di poter contribuire in modo decisivo alla crescita dell’user group italiano partecipando anche agli eventi annuali. Come molti di voi sono anche io un programmatore appassionato del mondo .NET e di tutto quello che ci gira attorno. Per il momento è tutto.
Dunque, al via questa nuova avventura ;-)