sabato 30 dicembre 2006
Questo dovrebbe essere l'ultimo mio post per l'anno 2006. E' stato un anno significativo, in cui sono successe tante cose, ma credo che la più importante sia stata la fine della mia istruzione, con la Laurea Specialistica in Tecnologie Informatiche presa 2 settimane fa...
Nel mese di Giugno di quest'anno ho anche deciso di aprire un blog su UgiDotNet.org, con lo scopo di condividere con tutti voi la mia passione per l'informatica e in particolare per la programmazione. E se i contributi che ho fornito sono stati utili anche solo ad una persona, posso dire di aver raggiunto l'obiettivo che mi ero prefissato... Nei mesi a venire cercherò di continuare questa attività, perché mi sono reso conto che il blog Around and Abount .NET World è servito tanto anche a me, poiché mi ha fornito uno stimolo in più ad essere sempre aggiornato, a cercare di capire il perché delle cose in un mondo, quello dell'informatica, in cui non ci si può permettere di rimanere indietro neanche di qualche metro...
Che dire ancora... Naturalmente AUGURI DI BUON ANNO A TUTTI!
La classe SoundPlayer, utilizzata per riprodurre file WAV, non è inclusa nel .NET Compact Framework 2.0. Di conseguenza, per ottenere questa funzionalità nelle applicazioni per dispositivi palmari, è necessario ricorrere alle API:
using System;
using System.IO;
using System.Runtime.InteropServices;
namespace System.Media
{
public class SoundPlayer
{
private byte[] m_soundBytes;
private string m_fileName;
private enum Flags
{
SND_SYNC = 0x0000,
SND_ASYNC = 0x0001,
SND_NODEFAULT = 0x0002,
SND_MEMORY = 0x0004,
SND_LOOP = 0x0008,
SND_NOSTOP = 0x0010,
SND_NOWAIT = 0x00002000,
SND_ALIAS = 0x00010000,
SND_ALIAS_ID = 0x00110000,
SND_FILENAME = 0x00020000,
SND_RESOURCE = 0x00040004
}
[DllImport("CoreDll.DLL", EntryPoint = "PlaySound", SetLastError = true)]
private extern static int WCE_PlaySound(string szSound, IntPtr hMod,
int flags);
[DllImport("CoreDll.DLL", EntryPoint = "PlaySound", SetLastError = true)]
private extern static int WCE_PlaySoundBytes(byte[] szSound, IntPtr hMod,
int flags);
public SoundPlayer(string fileName)
{
m_fileName = fileName;
}
public SoundPlayer(Stream stream)
{
m_soundBytes = new byte[stream.Length];
stream.Read(m_soundBytes, 0, (int)stream.Length);
}
public SoundPlayer(byte[] soundBytes)
{
m_soundBytes = soundBytes;
}
public void Play()
{
if (m_fileName != null)
WCE_PlaySound(m_fileName, IntPtr.Zero, (int)(Flags.SND_ASYNC |
Flags.SND_FILENAME));
else
WCE_PlaySoundBytes(m_soundBytes, IntPtr.Zero,
(int)(Flags.SND_ASYNC | Flags.SND_MEMORY));
}
}
}
Chi ha provato ad utilizzare gli oggetti OpenFileDialog e SaveFileDialog di .NET 2.0 con Windows Vista si sarà sicuramente accorto che le finestre così visualizzate non utilizzano il nuovo stile, ma appaiono così come erano in Windows XP.
Cercando maggiori informazioni in rete, ho scoperto perché. Le nuove API introdotte con Windows Vista non supportano l'hook delle finestre di dialogo: poiché gli oggetti OpenFileDialog e SaveFileDialog effettuano proprio l'hooking delle finestre, i controlli corrispondenti vengono visualizzati con il vecchio stile.
Per fortuna qualcuno ha già pensato alla soluzione: sul sito Channel9 è disponibile un controllo, completo di codice sorgente in C#, che consente di visualizzare le finestre Apri e Salva con nome utilizzando lo stile di Windows Vista. Se siete interessati, lo potete trovare qui.
UPDATE (31 Dicembre, ore 13.44). Se l'avessi fatto apposta non ci sarei riuscito: io e il mitico Corrado Cavalli abbiamo scritto un post sullo stesso argomento a distanza di un quarto d'ora!!!
Su questo argomento ci sono pareri discordanti, ma io sono dell'opinione che anche Windows Vista con la UAC abbia comunque bisogno di un antivirus. Ho provato quindi ad installare AVG Free 7.5, che sul sito del produttore è dichiarato compatibile con la nuova versione del sistema operativo.
In realtà, la compatibilità è ben lungi dall'essere ottimale. Innanzi tutto, quando in fase di accesso al sistema l'antivirus viene caricato in background, appare un messaggio che dice Could not initialize AVG anti-virus kernel interface. Application cannot run. A questo punto bisogna aspettare una trentina di secondi ed avviare manualmente l'anti-virus per vederlo effettivamente comparire nella barra delle applicazioni. Anche così facendo, tuttavia, alcuni moduli, tra cui quello che gestisce l'integrazione con Explorer e quello per la scansione della posta in entrata, non funzionano correttamente. Solo eseguendo il programma come amministratore si ripristinano tutte le caratteristiche dell'antivirus.
La soluzione al problema, per fortuna, è abbastanza semplice. Bisogna disabilitare l'esecuzione automatica di AVG Free, quindi creare un'attività pianificata utilizzando lo strumento Utilità di pianificazione di Windows, impostando per AVG Free 7.5 l'esecuzione dopo 30 secondi dall'avvio del sistema da un account che ha i privilegi di amministratore (nella prima schermata di definizione dell'attività bisogna spuntare la casella Esegui con i più alti privilegi possibili).
Certo, più che una soluzione questo è un workaround, ma per il momento risolve il problema... Con la speranza che le prossime versioni dell'anti-virus migliorino la compatibilità con Vista.
Secondo le linee guida della UAC, se in un programma un pulsante determina l'esecuzione di attivà che richiedono i privilegi di amministratore, esso deve contenere l'icona di uno scudo:
.gif)
Per inserire quest'icona nei pulsanti di un programma .NET ci sono due possibilità: utilizzare un'immagine bitmap dello scudo oppure, più elegantemente, creare un controllo che estende la classe Button e utilizza l'API di Windows Vista per mostrare l'icona in questione:
using System;
using System.Runtime.InteropServices;
using System.Windows.Forms;
namespace System.Windows.Forms
{
public class ShieldButton : Button
{
private const uint BCM_SETSHIELD = 0x0000160C;
[DllImport("user32.dll", CharSet = CharSet.Unicode)]
private static extern IntPtr SendMessage(HandleRef hWnd, UInt32 Msg,
IntPtr wParam, IntPtr lParam);
public ShieldButton()
: base()
{
this.FlatStyle = FlatStyle.System;
this.ShowShield = true;
}
private bool _showShield;
public bool ShowShield
{
get { return _showShield; }
set
{
_showShield = value;
SendMessage(new HandleRef(this, this.Handle), BCM_SETSHIELD,
IntPtr.Zero, new IntPtr(_showShield ? 1 : 0));
}
}
}
}
Il passo successivo è fare in modo che, alla pressione del pulsante, appaia la schermata della UAC che chiede conferma prima di proseguire con l'operazione... Ma di questo mi occuperò in un altro post...
In questa pagina è possibile trovare la road map prevista da Microsoft per il rilascio degli aggiornamenti dei sistemi operativi Windows. Qui si legge, tra le altre cose, che il Service Pack 3 per Windows XP è previsto per la prima metà del 2008, mentre il Service Pack 2 per Windows Server 2003 dovrebbe essere rilasciato entro il mese di aprile 2007.
This article discusses:
- Common authentication techniques for ASP.NET applications
- The Membership API and provider model in ASP.NET 2.0
- Role-based security and authorization
|
Clicca qui per leggere.
Questo articolo fornisce un'introduzione a NGen e spiega come utilizzarlo per migliorare le performance di un'applicazione .NET.
Uno degli errori più comuni nello sviluppo di software per Windows è quello di memorizzare file a run-time (ad esempio le opzioni selezionate dall'utente) nella cartella di installazione del programma, ovvero C:\Programmi (o C:\Program Files). Finché si è amministratori della macchina non ci sono problemi, ma se il software viene eseguito da un utente che ha privilegi limitati, la scrittura di file nella cartella dei programmi non è consentita, quindi l'applicazione non funziona correttamente.
Tra le tante soluzioni di Windows Vista per la sicurezza (alcune sono riassunte in questo articolo), ce n'è una chiamata File Virtualization, che ha proprio lo scopo di eliminare il problema appena citato:
File virtualization addresses the situation where an application relies on the ability to store a file (like a configuration file) in a system-wide location. This works well when the user is a member of the administrators group, but fails when the same program is launched from a limited user account (or an account protected by UAC). When the application writes to a system location (like \Program Files\...), Windows redirects it to a user-specific path under the \Virtual Store\... directory. Later, when the application reads back this file, the system will provide the one in the Virtual Store. As far as the application is concerned, it was able to successfully read and write directly to Program Files.
Example:
Suppose User A is running under a limited user account and uses Notepad to save a text file to \Program Files\foo.txt. Virtualization would allow this file to be saved successfully. What occurs is the write is redirected to \Virtual Store\(The User's account security identifier (-SID)\Program Files\foo.txt. Looking in the \Program Files\ directory with Windows Explorer, User A will see the file foo.txt, since Windows Explorer properly shows the user's virtualized files. However, after logging in, User B will NOT see the file foo.txt in the \Program Files\ directory. If User B then writes the \Program files\foo.txt file, that write will also virtualize to User B's virtual store. The files User A writes remain independent of the file User B writes.
Una tecnia analoga esiste anche per la virtualizzazione delle chiavi del Registro di configurazione (Registry Virtualization).
Questa soluzione dovrebbe risolvere i problemi di compatibilità di molte applicazioni con la UAC, tuttavia è bene ricordare che Microsoft rimuoverà la virtualizzazione dalle prossime versioni di Windows: in questo modo, vuole spingere gli sviluppatori a realizzare al più presto applicazioni UAC-Compliant.