Se posso passare alla modalità Static Library
Questo non è l'errore tipico che si ottiene quando si tenta di costruire una libreria statica con/CLR a tutti gli effetti. Dovrei supporre che tu abbia armeggiato con le impostazioni del progetto per sbarazzarti degli errori di linker imperscrutabili che ottieni quando provi a farlo.
Il problema principale è che il sistema di compilazione C++/CLI non supporta le librerie statiche che contengono MSIL. Il codice gestito non utilizza un linker, l'associazione avviene in fase di esecuzione. Il che fa sparire la differenza essenziale tra le librerie statiche e le DLL. Quindi Microsoft decise di non supportarlo perché non aveva molto senso implementarlo. Sfortunatamente non urlano abbastanza forte quando provi a farlo lo stesso, gli errori del linker che ricevi non ti danno abbastanza indizio su cosa hai fatto di sbagliato. I workaround, come l'unione con ILMerge, non funzionano neanche, non possono gestire assiemi in modalità mista. L'unione delle sezioni di codice native e le relative voci della tabella di rilocazione associate è molto spartano.
Ricordare che è possibile collegare librerie statiche native. Un tipico progetto C++/CLI ha solo i wrapper di classe ref che devono essere creati con/clr in effetti. Puoi incollare qualsiasi quantità di codice nativo dalle librerie all'assemblaggio finale.
sono costretto a teorizzare l'errore di compilazione vera e propria, anche molti programmatori ottengono questo errore per un'altra motivo che non ha nulla a che fare con la costruzione di librerie statiche e mi stanno tormentando nei commenti .
Fare attenzione al fatto che il targeting di una versione diversa di .NET rispetto a quella installata sul proprio computer sia un problema piuttosto pericoloso, in particolare se si desidera eseguire il target 4.0 e avere 4.5.x installato. L'elemento chiave nel file .vcxproj è <TargetFrameworkVersion>. Questo mancherebbe se avessi avviato il progetto con una vecchia versione .NET, devi inserirla tu stesso. L'IDE inoltre non supporta la modifica se è è presente, ancora una volta modifica a mano.
Quale è sufficiente per convincere MSBuild a generare il comando di compilazione corretto. È possibile verificare se tale operazione è stata eseguita correttamente, cercare nella sottodirectory * .tlog della directory di compilazione di Debug per il proprio progetto. Il file cl.command.1.tlog mostra le opzioni che sono state passate al compilatore.Dovrebbe contenere:
/AI "C: \ Program Files (x86) \ Riferimento Assemblies \ Microsoft \ Framework.NETFramework \ v4.0"
/FU "C: \ Program Files (x86) \ Riferimento Assemblies \ Microsoft \ Framework.NETFramework \ v4.0 \ mscorlib.dll "
Nota la sottodirectory, molto importante che corrisponda al target .NET previsto. v4.0 in questo esempio. E molto, molto importante che lo sia non in c: \ windows \ microsoft.net, la posizione legacy per gli assembly di riferimento.
che non potrebbe essere più lontano dalla realtà. In realtà è molto FACILE fondere gli assembly con il codice nativo (anche se non proprio consigliato) - l'ho fatto diverse volte, infatti parte del mio WORK include il codice nativo negli assembly CLR - ma unirmi mi ha lasciato aggiungendo un altro step di costruzione che volevo evitare ... quindi ho scelto il modo tradizionale di fare riferimento a ciascun assembly separatamente. – specializt
... e la parte relativa a C++/CLI essendo un "linguaggio di interoperabilità" non ha alcun senso. Mi sembra necessario fare un po 'di ricerca sugli argomenti scelti. (Microsoft) Interop non ha NIENTE a che fare con le specificità della lingua, non ci può essere alcun "linguaggio di interoperabilità" - l'interoperabilità è in qualche modo un PONTE TRA LINGUE. Per favore non dichiarare le tue supposizioni e le tue fantasie come se fossero fatti difficili ... – specializt
Stai facendo baldoria. Pubblica invece una risposta. –