2011-11-14 3 views
3

Je construis une bibliothèque proxy/stub à partir d'un fichier IDL, et pour une raison quelconque, le pilote de construction pense que la bibliothèque d'importation générée pendant le lien est un fichier d'entrée sur le lien, reliant le projet à chaque fois noms raccourcies pour une meilleure lisibilité):Dépendance de DLL pour posséder la bibliothèque d'importation, comment éviter?

10:05:33.764 1> 
Target "Link: (TargetId:66)" in file "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Microsoft.Cpp.Win32.Targets" from project "[...]\VersionControl.vcxproj" (target "_Link" depends on it): 
Using "Link" task from assembly "Microsoft.Build.CppTasks.Win32, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a". 
Task "Link" (TaskId:26) 
    Write Tracking Logs: (TaskId:26) 
[...] 
    Outputs for [...]\DEBUG\DLLDATA.OBJ|[...]\DEBUG\VERSIONCONTROL.DLL.EMBED.MANIFEST.RES|[...]\DEBUG\VERSIONCONTROL_I.OBJ|[...]\DEBUG\VERSIONCONTROL_P.OBJ: (TaskId:26) 
    [...]\DEBUG\VERSIONCONTROL.ILK (TaskId:26) 
    [...]\DEBUG\VERSIONCONTROL.DLL (TaskId:26) 
    [...]\DEBUG\VERSIONCONTROL.DLL.INTERMEDIATE.MANIFEST (TaskId:26) 
    [...]\DEBUG\VERSIONCONTROL.PDB (TaskId:26) 
    Inputs for [...]\DEBUG\DLLDATA.OBJ|[...]\DEBUG\VERSIONCONTROL.DLL.EMBED.MANIFEST.RES|[...]\DEBUG\VERSIONCONTROL_I.OBJ|[...]\DEBUG\VERSIONCONTROL_P.OBJ: (TaskId:26) 
    [...]\LIB\RPCRT4.LIB (TaskId:26) 
    [...]\LIB\KERNEL32.LIB (TaskId:26) 
    [...]\LIB\USER32.LIB (TaskId:26) 
    [...]\LIB\GDI32.LIB (TaskId:26) 
    [...]\LIB\WINSPOOL.LIB (TaskId:26) 
    [...]\LIB\COMDLG32.LIB (TaskId:26) 
    [...]\LIB\ADVAPI32.LIB (TaskId:26) 
    [...]\LIB\SHELL32.LIB (TaskId:26) 
    [...]\LIB\OLE32.LIB (TaskId:26) 
    [...]\LIB\OLEAUT32.LIB (TaskId:26) 
    [...]\LIB\UUID.LIB (TaskId:26) 
    [...]\LIB\ODBC32.LIB (TaskId:26) 
    [...]\LIB\ODBCCP32.LIB (TaskId:26) 
    [...]\DEBUG\VERSIONCONTROL.DLL.EMBED.MANIFEST.RES (TaskId:26) 
    [...]\DEBUG\DLLDATA.OBJ (TaskId:26) 
    [...]\DEBUG\VERSIONCONTROL_I.OBJ (TaskId:26) 
    [...]\DEBUG\VERSIONCONTROL_P.OBJ (TaskId:26) 
    [...]\SYSTEM32\TZRES.DLL (TaskId:26) 
    [...]\SORTING\SORTDEFAULT.NLS (TaskId:26) 
    [...]\DEBUG\VERSIONCONTROL.EXP (TaskId:26) 
    [...]\DEBUG\VERSIONCONTROL.LIB (TaskId:26) 
    [...]\VERSIONCONTROL.DEF (TaskId:26) 
    [...]\LIB\MSVCRTD.LIB (TaskId:26) 
    [...]\LIB\OLDNAMES.LIB (TaskId:26) 
    Source compilation required: input [...]\DEBUG\VERSIONCONTROL.LIB is newer than output [...]\DEBUG\VERSIONCONTROL.DLL. (TaskId:26) 

Le projet est mis en place en tant que projet DLL normale, avec les paramètres par défaut. gauche comme Une idée de pourquoi MSBuild décide que ces fichiers générés devraient être traités comme des entrées, et comment je pourrais résoudre ce problème?

+0

« versioncontrol » est un nom inhabituel pour une DLL proxy/stub. Mes boules de cristal indiquent que votre projet principal de serveur COM s'appelle également "VersionControl". –

+0

Non, c'est juste le nom de l'interface. Actuellement, la seule implémentation réside dans l'application principale et COM n'est utilisé que pour déplacer des opérations longues dans un thread séparé. À un moment donné, je prévois de séparer le code en une DLL distincte, qui portera le nom du système VC auquel elle est liée et enregistrée dans une catégorie. –

+0

Je construis généralement un projet contenant l'IDL pour les interfaces, qui construit la bibliothèque P/S, et chaque implémentation importe l'IDL à partir de là et définit 'coclass'es. –

Répondre

0

C'est un coup de feu dans l'obscurité, mais vaut un coup d'œil ...

Ouvrez votre fichier vcxproj et recherchez le @ (Midl) point. Modifier en essayant un de ces trois éléments de métadonnées de l'article et voir comment le comportement change, il peut vous mettre sur la bonne voie:

<Midl Include="My.idl"> 
    <LinkCompiled>false</LinkCompiled> 
    <LibCompiled>false</LibCompiled> 
    <ImpLibCompiled>false</ImpLibCompiled> 
    </Midl> 
Questions connexes