Ho fatto una breve ricerca in merito al mio precedente post ed ho trovato che già qualcuno aveva segnalato il comportamento anomalo. Il team Microsoft segnala che le versione di VS.NET successive alla BETA 1 non hanno più questo problema. Sarà meglio che mi decida a scaricare la CTP di Febbraio.

http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=a9dd17ac-10fb-4828-847a-104dcdb31872

Meno male!

powered by IMHO

 


Non so quanti abbiano la mia stessa abitudine, tant'è che io, da quando uso VS.NET 2002/2003, ho adottato un modo di strutturare le mie "solutions" ormai abbastanza sperimentato e consolidato. Usando Visual Studio 2005, ho notato che l'IDE, nella Beta 1 CTP di Dicembre, usa fare delle assunzioni che mi rendono la vita abbastanza difficile se continuo a mantenere invariata la struttura.

Personalmente sono uso a denominare il progetto con lo stesso nome del namespace di base cui esso fa riferimento. Perciò, dovendo creare un assembly relativo al namespace "Elite.DotTraq.Configuration", non faccio altro che chiamare il progetto proprio così, ottenendo il beneficio che le varie cartelle di una solution sono ben ordinate e mi riconducono facilmente ai file che contengono, e che VS.NET automaticamente mi imposta il namespace di default del progetto a quello adottato come nome.

In VisualStudio 2005 le cose cambiano "sottilmente". Se si prova a chiamare un progetto "Elite.DotTraq.Configuration", la cartella ed il progetto assumeranno correttamente questo nome, mentre il namespace di base inopinatamente diverrà Elite_DotTraq_Configuration, sostituendo quindi i punti con degli underscore che creano non pochi problemi.

La cosa si risolve richiamando le proprietà del progetto e rimettendo i punti al loro posto, ma questo implica di dover cancellare la classe che viene creata di default, o tuttalpiù di correggerne il namespace.

Mi sfugge il motivo per cui il team di VS.NET abbia deciso di apportare questa modifica, devo solo rilevare che mi sembra un peggioramento. Almeno per la mia mania di ordine...forse per le persone più "normali" sarà una cosa buona.

powered by IMHO


Nel post qui quotato, il team di Visual Studio 2005 chiede aiutoper stabilire quale sia il miglior design per i tab della nuoca IDE. Mi immagino i litigi durante le riunioni che alla fine sono sfociati nella decisione di rimettersi ad un response "popolare"...

Hi everyone – The Visual Studio Design team is currently going back and forth over a few different designs for the tool window tabs in Visual Studio 2005, and we wanted to elicit feedback from the community on what all of you prefer. With the tabs in Visual Studio 2005 Beta 1 it can be difficult to determine at a glance which ones are active and which are inactive, which is how we ended up with the designs that we’re prototyping.

Fonte: Feedback Requested: Visual Studio 2005 Tab Design

powered by IMHO


La Oracle ha deciso di supportare al più presto il Framework .NET con dei tools per gli sviluppatori che si dovrebbero integrare in Visual Studio al pari del Server Explorer attuale. Il passo più curioso dell'articolo recita:

It allows a developer to view the schema quickly, as well as add or edit Oracle database objects such as databases, tables, views, stored procedures, functions, packages, synonyms, sequences, XML databases, and Java classes.

La cosa di gran lunga più interessante è invece la promessa integrazione del runtime di .NET all'interno del database per offrire la possibilità di scrivere stored procedures con i linguaggi di .NET come già avviene per Java.

Mendelsohn also hinted at another product named Oracle Database Extensions for .NET, due to ship with Oracle 10g Release 2 in mid 2005. The product will enable developers to write .NET stored procedures for Oracle on Windows; feature a server-side data provider; and support C#, Visual Basic .NET, and Managed C++. On a related note, 10g Release 2 also will support runtime load balancing.

Fonte: Dev Tools for VS.NET from Oracle

powered by IMHO