2010-11-01 29 views
5

Je me rends compte qu'il a été demandé et répondu que Visual Studio ne prend pas en charge les projets CIL/MSIL. Le projet MSBuildContrib comporte une tâche ILASM qui vous permet de compiler des fichiers IL au moment de la construction.Existe-t-il des exemples de compilation de code CIL à partir d'un projet Visual Studio?

Googled est venu vide sur des exemples pour l'utilisation de cette tâche.

Existe-t-il des exemples d'utilisation d'ILASM dans le cadre d'une solution Visual Studio? Je réalise que #develope et ILIDE supportent CIL ... l'objectif ici est de compiler quelques fichiers CIL dans le cadre d'une solution Visual Studio.

+0

Puis-je demander pourquoi vous avez vraiment besoin de compiler avec IL? Qu'est-ce que C#/VB.NET/F # ne peut pas faire? – leppie

+2

@Leppie - C'est un sujet digne d'un long débat, il suffit de dire qu'il y a (admirablement peu) des choses beaucoup plus faciles à réaliser avec IL qu'avec C# ou VB - en particulier lors de la création de génériques. IL, naughtily, vous permet de pcik dynamiquement et choisissez les arguments à pousser à la pile avant d'invoquer une méthode. C# et VB ne le font pas.Normalement, c'est une bonne chose, mais parfois en pliant les règles ouvre de nouvelles portes. Les délégués dynamiques en sont un exemple. – Mark

+0

@Mark, pouvez-vous dire brièvement (ou fournir un lien vers) que pouvez-vous améliorer pour les délégués utilisant MSIL? Cela peut-il vous aider à écrire des méthodes qui fonctionnent pour tous les types de délégués? –

Répondre

1

Vous pouvez ajouter un "projet makefile". Le modèle est sous Visual C++, General. Ce type de projet vous permet de spécifier des commandes de construction personnalisées pour les actions Build, Clean et Reconstruire. L'environnement sera configuré automatiquement afin que vous n'ayez pas à vous préoccuper des chemins. L'EDI C++ prend également en charge la création d'une règle de génération personnalisée afin que vous puissiez automatiquement déclencher le bon outil (ilasm.exe) à partir de l'extension de nom de fichier (.il).

C'est pourtant à peu près aussi bon que possible. Il n'y a pas de mappage automatique de plusieurs fichiers .il dans le projet vers une seule commande de génération. Écrire un makefile nmake.exe est nécessaire pour obtenir cela. Et méfiez-vous que le support des règles de build personnalisées soit cassé dans vs2010.

+0

Merci Hans! C'est plus ou moins ce dont j'ai besoin. BTW - aucune idée pourquoi les modèles MSBUILD sur Codeplex ont été abandonnées? Je les ai essayés dans VS2010 et n'ai pas eu de joie ... semblait être une contribution utile. – Mark

+0

Y a-t-il un danger à canibaliser un csproj, en supprimant les "csharp.targets" et en ajoutant des tâches de construction personnalisées pour assembler l'IL? Cela fonctionnerait-il mieux ou pire en termes de contrôle de la source? – Mark

+0

Rien de ce que j'ai posté dans cette réponse n'est en quelque sorte lié à MSBuild. Vous donnez les commandes de construction exactement comme vous les spécifieriez dans un événement de construction pré/post. –

12

je lui ai donné crédit Hans pour répondre à cette question, mais après quelques essais, j'ai une solution qui est un peu plus près de chez:

COMMENT COMPILER CIL/MSIL INTÉRIEUR VISUAL STUDIO

Le hack suivant obtient un projet qui:

  • Respecte la configuration de génération Debug vs. Release dans Visual Studio.
  • Signe éventuellement l'assemblage CIL résultant avec le fichier de clé défini dans les préférences du projet.
  • Peut être ajouté au contrôle de code source.

Suivez ces étapes:

  1. Créer une bibliothèque vide C# Classs
  2. Dans le dossier de la solution, cliquez droit sur le projet et choisissez "projet unload"
  3. clic droit sur le projet à vide et choisissez "edit project"
  4. Dans le fichier csprof, faites défiler vers le bas, et trouvez la ligne qui dit "Import ... Project =" $ (MSBuildBinPath) \ Microsoft.CSharp.targets ", et remplacez-le par le code au http://pastebin.com/KEJtyQLu (reproduites ci-dessous)

Voici le XML:

<Import Project="$(MSBuildToolsPath)\Microsoft.Common.targets" /> 

    <Target Name="CreateManifestResourceNames" /> 

    <Target Name="CoreCompile" Inputs="$(MSBuildAllProjects);@(Compile);" Outputs="@(IntermediateAssembly);$(NonExistentFile);"> 
    <GetFrameworkPath> 
     <Output TaskParameter="Path" PropertyName="FrameworkPath" /> 
    </GetFrameworkPath> 

    <PropertyGroup> 
     <IlAsmCommand>&quot;$(FrameworkPath)\Ilasm.exe&quot; /NOLOGO /DLL /OUTPUT:&quot;@(IntermediateAssembly)&quot; </IlAsmCommand> 
    </PropertyGroup> 

    <PropertyGroup Condition=" '$(Configuration)' == 'Debug' " > 
     <IlAsmCommand>$(IlAsmCommand) /DEBUG </IlAsmCommand> 
    </PropertyGroup> 

    <PropertyGroup Condition=" '$(Configuration)' == 'Release' " ><IlAsmCommand>$(IlAsmCommand) /OPTIMIZE </IlAsmCommand></PropertyGroup> 

    <PropertyGroup Condition=" '$(AssemblyOriginatorKeyFile)' != '' " > 
     <IlAsmCommand>$(IlAsmCommand) /KEY:&quot;$(AssemblyOriginatorKeyFile)&quot; </IlAsmCommand> 
    </PropertyGroup> 

    <Exec Command="$(IlAsmCommand) @(Compile->'&quot;%(FullPath)&quot;', ' ')" 
      Outputs="@(IntermediateAssembly)" /> 

    <CallTarget Targets="$(TargetsTriggeredByCompilation)" Condition="'$(TargetsTriggeredByCompilation)' != ''" /> 

    </Target> 
+0

Merci, cela m'a donné un bon point de départ. J'utilisais MonoDevelop qui peut normalement compiler des projets CIL correctement, mais que la faille soit avec ou avec moi, je ne pouvais pas faire fonctionner la signature correctement, et baser les changements sur le fichier ilproj sur ce qui précède le triait. Pour une version mono, remplacez '" $ (FrameworkPath) \ Ilasm.exe "' avec 'ildasm' (sensible à la casse) et supprimez les ajouts de débogage et de publication (qui atteignent tous les deux des fonctionnalités que mon ildasm ne prend pas encore en charge. MS, il peut aussi être bon d'ajouter '/ RESOURCE: someResourceFile.res' (j'ai juste codé en dur dans le premier' IlAsmCommand') –