Utilizzare DLL precedenti (.NET) nell'app di Windows Store?

Question

Ho iniziato a lavorare sul porting di un'applicazione che ho scritto per la distribuzione nell'App Store di Windows 8.Ciò richiede che l'applicazione sia scritta contro il sottoinsieme del quadro .NET.La mia applicazione segue un'architettura in cui la funzionalità principale è nella propria DLL, e cose come l'accesso del file system vengono eseguite tramite IOC.Fondamentalmente, ciò significa che l'unica dipendenza per il Core DLL è il sistema.A causa di ciò, pensavo che il porting sarebbe un gioco da ragazzi - configurando i miei valori dei miei IOC e collegare una GUI, allora sarò bello andare.Solo, non riesco nemmeno a fare riferimento alla mia DLL Core dall'app Windows Store (A.k.a. Metro App).

Ho perso qualcosa?In realtà devi riscrivere la mia DLL Core solo per l'inclusione nell'App Store di Windows 8?Ci è stato detto che se usi una buona architettura, allora il porting sarà un brezza, ed è quello che ho fatto.È stata semplicemente una grande bugia?

Answer 1

Le app store Windows (precedentemente chiamata APP Metro Style) sono limitate all'utilizzo del profilo core .NET.Ho messo alcuni dettagli sul profilo principale in my Rispondi a questa domanda .Vedere Conversione del codice Framework di .NET esistente In questo articolo maggiori dettagli.Non è la tua architettura, è il sottoinsieme del .NET Framework disponibile per un'app Windows Store.Potrebbe essere necessario integrare alcuni dei tipi che usi in .NET con i tipi di WinRT invece.

Answer 2

Non ho una conoscenza approfondita e cercherò di stipare i fatti mentre li capisco. La metropolitana aggiunge funzionalità e funzionalità limitabili. Esistono restrizioni di sicurezza pesanti e segmenti vasti del Full .NET Framework che non sono disponibili (ad esempio, non è possibile utilizzare System.Data, alcuni dei metodi di sistema.io e dei file di accesso sono drasticamente modificati). Un'app della metropolitana è isolata, non sarai in grado di ricurse tutti i file sul disco rigido come puoi in un'applicazione standard (la mia opinione che è, in cima alla sicurezza da parte di isolamento È un incoraggiamento a spingerti nel Cloud per esigenze di archiviazione).

A meno che le cose non siano cambiate, Pinvoke è limitata a metodi API Win32 "approvati".

Vedere questo link per alcune alternative alle esigenze di API Win32 comuni: http://msdn.microsoft.com/en-us/library/windows/apps/hh464945.aspx

Vedi questo link per API di Win32 / COM approvato: http://msdn.microsoft.com/en-us/library/windows/apps/br205762.aspx

È difficile dire se un'architettura "buona" sarà una brezza da porto senza sapere cosa c'è nel codice in quell'architettura. Nel mio quadro di utilità ho avuto cose che portò molto facilmente (o almeno erano semplici) e le cose che erano un lavaggio completo che richiedeva molta riscrittura (la perdita di System.Data ad esempio è un punto dolente per me). Ci sono cose che possono essere progettate bene, ma quando estrai il codice sottostomo nel quadro o API è stato scritto con esso richiederà la riscrittura.

Answer 3

Ho avuto lo stesso problema: un progetto per l'app della metropolitana non caricare DLL creato con Framework .4.Ho cambiato il quadro da 4 a 3,5 per la DLL e ora il progetto Metro li vede.