NET in Windows 8: AppContract, Marketplace e WPF / C # da un punto di vista dev

Question

Sono abbastanza excitet su tutte le novità in arrivo in Windows 8, ma allo stesso tempo un po 'preoccupato di come e se posso continuare a utilizzare i componenti di codice e personalizzati ho già costruito utilizzando .NET e C # durante il mio tempo come un dev di Windows. Ho alcune domande misti Generali su questo. Spero che non ti dispiaccia io li sto mettendo insieme in un post:

• Will Windows 8 Conservare essere per entrambe le applicazioni Metro-style e regolari applicazioni WPF-del desktop? Compreso spingendo gli aggiornamenti e rendere le applicazioni disponibili per i dipendenti della società?

• Sarà il nuovo App Contratto-thingy anche essere disponibile per WPF-apps? Ed è AppContract sulla base di WCF-servizi con forse UDP-discovery sulla rete? Posso fare i miei contratti tra le proprie applicazioni utilizzando il framework App contratto?

• Non sto particolarmente preoccupato se WPF verrà abbandonato o meno. Posso vivere senza di essa. La cosa che mi preoccupa è se riesco ancora a scrivere la presentazione e il codice business layer in C # e usarlo come backend per le mie applicazioni, non importa quale UI-quadro sarò con, HTML, Silverlight, WPF o quello che hai . Se sono ancora in grado di scrivere la logica in C # e presentarlo con X-UI framework, Sono uno sviluppatore felice. Ho sentito che posso accedere al .NET framework da JavaScript. Ma che dire di assembly personalizzati?

Answer 1

E 'stato annunciato che le applicazioni non-Metro possono apparire nel negozio ma il negozio sarà solo un collegamento al sito della casa editrice -. In realtà non gestire la vendita / installazione / DRM / etc roba

Che cosa è stato annunciato finora è che i contratti sono solo per le app Metro ma sarei scioccato se questo non cambia. Sarebbe folle per Microsoft non per consentire applicazioni desktop, ad esempio, aggiungere i comandi al fascino delle impostazioni, il supporto PlayTo o la stampa attraverso il fascino Devices, o agire come fonti di Azioni. Dovremo aspettare e vedere dove tracciare la linea su ciò che le applicazioni desktop possono / non possono fare.

condivisione di codice tra Metro e non-Metro Apps è sarà molto difficile. Un sacco di concetti fondamentali e le convenzioni sono gli stessi, ma anche di base roba come file di I / O contare su una totalmente nuova API. Non ci sono un sacco di cose interessanti che si possono fare con il codice a che lavoreranno su entrambi i lati della barricata. La cosa migliore sarebbe quella di definire le interfacce per la vostra roba livello di business e quindi utilizzare dependecy iniezione di selezionare dinamicamente vs. tavolo WinRT implementazioni in fase di esecuzione

Answer 2

• Store: non ci sono informazioni finale, ma per quanto ho capito, è per le applicazioni in stile Metro solo

• I contratti app sono una cosa metropolitana. So che un frammento di codice che l'uso di documenti da applicazioni desktop (ad esempio, http://www.heise.de/developer/artikel/WinRT-in-klassischen-NET-Anwendungen-nutzen-1366039.html (mi dispiace, tedesco)), ma non so se avrà il supporto di Microsoft

• WinRT compila le librerie di componenti WinRT. Potreste essere in grado di riutilizzare il codice e compilarli a un componente fino a quando non si sta usando uno spazio dei nomi che non è disponibile per WinRT

Questa domanda è pesante sul indovinando quanto non v'è alcuna versione beta ufficiale disponibile. E anche allora non possiamo essere assolutamente certi ...