2010-11-12 15 views
7

Siamo passati da VS2008 a VS2010 per lo sviluppo. Ma il requisito per l'installazione dell'app è ancora Framework 3.5. Pertanto indirizziamo la build a questo framework. Tutto funziona bene tranne un comportamento strano Vorrei verificare che non sia un problema:VS2010 modifica i riferimenti del file di risorse alla versione 4.0 nonostante il targeting 3.5 Framework

Se qualcuno modifica le risorse voci esistenti in resources.resx e resources.designer.cs modifica la voce system.windows.forms da 2.0 Da .0.0 a 4.0.0.0. Esempio:

Prima modifica:

<assembly alias="System.windows.forms" 
      name="system.windows.forms, Version=2.0.0.0, ...[signature] /> 

Dopo:

<assembly alias="System.windows.forms" 
      name="system.windows.forms, Version=4.0.0.0, ...[signature] /> 

Questo sembra essere un punto di riferimento per i tipi ResXFileRef per le immagini. Una linea poi si dice:

<data name="mypic" type="System.Resources.ResXFileRef, System.Windows.Forms"> 
    <value>[pictureinfomation - referencing System.Drawing version 2.0]</value> 
</data> 

esecuzione l'applicazione non sembra cercare la versione 4. ma vorrei sapere con certezza, che questo non è un problema.

Qualcuno ha qualche idea? Ho cercato un bel po 'di tempo per una risposta e non ho capito bene che il ResXFileRef è usato nel meccanismo delle risorse.

Grazie per eventuali suggerimenti se la mia app utilizza ancora 3.5 versioni.

saluti

+0

Ho notato qualcosa di simile; vale a dire, la conversione di una soluzione da VS2008 a VS2010 può cambiare automaticamente le versioni di destinazione di .NET Framework dei progetti. – stakx

+0

C'è sicuramente una mappatura trasparente in corso. Vedere questo thread per riferimento: http://stackoverflow.com/questions/4065577/are-dependencies-promoted-in-net-assembly-manifests/4065799#4065799 –

+0

Dove nei file di risorse si vede ? Cercando di ricreare questo, e non riesco a trovare quel tag da nessuna parte nel progetto ... –

risposta

0

non ha alcun impatto sulla vostra applicazione, come i binari compilati sono ancora contro .NET 3.5.

Se questo è un bug, non dovresti essere il primo a notarlo.

1

Non penso che questo sia un bug.

Provare a compilare l'applicazione e distribuirla e testare.

Anche ottenere le proprietà di dll utilizzando 'ildasm'and controllo

+0

L'ho fatto. Ma temevo che potesse essere un riferimento caricato in runtime e quindi rappresentare un rischio di runtime. Quindi ho pensato a qualcuno di nuovo sicuro di ciò per cui questa voce è stata usata e se/quando è stata caricata (forse solo per progettisti VS?). – Uwe

+0

Non penso che accadrà. Puoi dare un test e controllarlo –

Problemi correlati