C'è una semplice ragione per cui a MS questo modello non piace - se qualche programma contiene la sua versione delle DLL di .NET framework, Windows Update non sarebbe in grado di fornire aggiornamenti di sicurezza / correzioni di bug per il. DLL framework NET. E questo non è un problema ipotetico: ogni pochi mesi, una nuova patch o un aggiornamento di sicurezza per le DLL framework è stato distribuito dalla MS in passato.
La situazione in cui MS ha fornito specifiche DLL di run time ai fornitori di applicazioni e che i produttori sono responsabili della distribuzione e dell'aggiornamento delle DLL stesse non è nuova. Ad esempio, le DLL MFC, le DLL GDI + e alcune altre librerie sono state spesso distribuite in questo modo. Ma questo porta quasi sempre a una situazione in cui gli utenti hanno avuto problemi nell'ottenere aggiornamenti importanti per queste DLL. Vedi, ad esempio, qui , per il caso dal 2004 in cui gdiplus.dll doveva essere aggiornato - e che guai significano per gli utenti, rispetto ad un aggiornamento relativamente impeccabile usando i meccanismi di "Windows Update". Da quell'esperienza credo che MS sia giunta alla conclusione di non dare la responsabilità degli aggiornamenti dalle loro mani.
Ai tuoi argomenti:
1) We often don't use all the dlls but we force customers to install the entire .NET framework. It would be great to just deploy the dlls we need.
La versione Windows più recente contiene già .NET FW 3.5 o 4.0 E in caso contrario, il framework deve essere installato una volta per macchina (ok, 3.5 una volta e 4.0 una volta), non più e più volte per ogni applicazione che ne ha bisogno
2) We often want to update our application and the framework but that sometimes requires a machine reboot because other applications are using it.
Di solito non vuoi aggiornare il framework da solo, Windows Update lo fa per te. E se hai intenzione di utilizzare una nuova versione di framework che finora non è installata sulla macchina, ovviamente non può esserci un'altra applicazione che utilizza il framework più recente finora.
3) A full .NET installation usually takes quite a bit of time. An xcopy type private deployment could be much faster.
Sì, ma solo una volta per macchina, non una sola volta per applicazione.
@ La risposta di BryantB è anche vera. Soprattutto perché il modello di esecuzione degli assembly .NET non controlla se tutti gli assembly necessari sono installati prima che JITer compili una chiamata di funzione a uno di quegli assembly. Ciò significa che se si dimentica di distribuire una DLL framework, il programma potrebbe avviarsi in modo impeccabile, ma si bloccherà più tardi quando verrà utilizzata la prima funzione che richiede la DLL dimenticata. Questo comportamento è molto diverso dalle DLL native (ovviamente non quelle con il caricamento ritardato) e sarebbe un pericoloso errore trap.