2017-07-24 8 views
1

Comme j'avais besoin de ses fonctionnalités, j'ai forké un paquet NuGet qui était supposé pouvoir me permettre de traiter des expressions régulières dans ma construction, dont le but était: est de transformer le numéro de version .NET Framework en une variable d'environnement, de sorte que, par exemple, 4.7 devienne NET47. Je suis plus que suffisamment familier avec les expressions régulières pour que cela se produise, et la tâche fonctionne parfaitement lorsque j'appelle l'assembly à partir d'un programme de console. Il trouve et charge l'assembly, exécute sa méthode Execute et définit les valeurs de propriété attendues. Toutefois, lorsque j'essaie d'exécuter la tâche dans une construction, MSBuild rapporte comme suit.La tâche "RegularExpressionMatching" n'a pas pu être chargée à partir de l'assembly RegexMatch.MSBuildTask

Le "RegularExpressionMatching" tâche ne pourrait être chargé de l'ensemble R egexMatch.MSBuildTask, Version = 1.0.0.7, Culture = neutral, PublicKeyToken = 659f28f508fc4cd9, processorArchitecture = MSIL. Confirmez que la déclaration est correcte, que l'assembly et toutes ses dépendances sont disponibles et que la tâche contient une classe publique qui implémente Microsoft.Build.Framework.ITask. C: \ Users \ DAVE \ Documents \ Visual Studio 2013 \ Projects \ WizardWrx_Libs \ DLLServices2 \ ConsoleStreamsLab \ ConsoleStreamsLab_4.7 \ ConsoleStreamsLab_4.7.csproj 81 5 ConsoleStreamsLab_4.7

élément Mon UsingTask se présente comme suit.

<UsingTask TaskName="RegularExpressionMatching" 
      AssemblyName="RegexMatch.MSBuildTask, Version=1.0.0.7, Culture=neutral, PublicKeyToken=659f28f508fc4cd9, processorArchitecture=MSIL" /> 

Mon bloc cible suit.

<Target Name="SecondMatch" AfterTargets="BeforeBuild"> 
    <Message Text="TargetFrameworkVersion = $(TargetFrameworkVersion)" Importance="high" /> 
    <Message Text="DefineConstants  = $(DefineConstants)" Importance="high" /> 
    <RegularExpressionMatching Input="$(DefineConstants)" Pattern="^(.*)(*;NET\d{1,2})(;*.*)*$" > 
     <Output TaskParameter="IsMatch" 
       PropertyName="IsMatchJiro" /> 
     <Output TaskParameter="Match" 
       PropertyName="MatchJiro" /> 
     <Output TaskParameter="Replacement" 
       PropertyName="ReplacementJiro" /> 
    </RegularExpressionMatching> 

Les deux premiers messages apparaissent dans le journal de construction, exactement comme prévu, puis affichés.

------ Build started: Project: ConsoleStreamsLab_4.7, Configuration: Debug Any CPU ------ 
Build started 2017/07/24 15:14:29. 
SecondMatch: 
    TargetFrameworkVersion = v4.7 
    DefineConstants  = DEBUG;TRACE 
C:\Users\DAVE\Documents\Visual Studio 2013\Projects\WizardWrx_Libs\DLLServices2\ConsoleStreamsLab\ConsoleStreamsLab_4.7\ConsoleStreamsLab_4.7.csproj(81,5): error MSB4062: The "RegularExpressionMatching" task could not be loaded from the assembly RegexMatch.MSBuildTask, Version=1.0.0.7, Culture=neutral, PublicKeyToken=659f28f508fc4cd9, processorArchitecture=MSIL. Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask. 

Build FAILED. 

Time Elapsed 00:00:00.00 
========== Build: 0 succeeded, 1 failed, 1 up-to-date, 0 skipped ========== 

Diagnostic Level Build Log est une tentative précédente, courir avec le niveau de journalisation mis au diagnostic. Bien que cela donne beaucoup plus d'informations, rien de tout cela n'éclaire la lumière, autant que je sache.

L'ensemble en question a un nom fort , est installé dans le GAC sur la machine sur laquelle la construction a couru et n'a pas de dépendances inhabituelles, autres que les trois assemblées MSBuild.

Je soupçonne que la solution pourrait être dans les références de montage figurant dans le RegExMatch Solution, en particulier Microsoft.Build.Utilities.v4.0, puisque je ne suis pas sûr comment cela est en corrélation avec le moteur de construction qui fonctionne dans Visual Studio 2013, qui se présente comme la version 12 (bien que cela puisse se référer uniquement à la version de Visual Studio avec laquelle il est livré).

Je voudrais vraiment que cela fonctionne, afin que je puisse faire cette tâche de la manière guidée par les données, et éliminer les paramètres codés en dur. Une fois que j'ai une preuve de concept, je serai ravi de soumettre une demande de tirage à l'auteur original.

Je vais avoir les yeux ouverts pour de bonnes suggestions.

Répondre

0

Avez-vous importé le projet des extensions? Je ne l'ai pas utilisé les extensions spécifiques que vous avez utilisé, mais quand je les MSBuildExtensions je devais ajouter un ensemble de lignes à l'effet de:

<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" /> 

seulement après cette ligne était présent je pu acess les objectifs et utilisez les extensions.

+0

Cette modification n'a eu aucun effet sur le résultat. En examinant le contenu du fichier, je ne peux pas voir comment cela aurait changé quoi que ce soit. Néanmoins, après l'avoir fait avant, je suis allé de l'avant, et le résultat était exactement le même qu'avant. –

+0

Donc juste pour vérifier vous avez référé le chemin d'importation à votre paquet de nuget reconstruit? Comme dans ne pas copier ma ligne verbatim, mais importer le projet contenant votre extension que vous souhaitez utiliser? – Spence

+0

QUOI? Ajouter le projet VS? C'est stupide! Comme les autres utilisateurs n'auront pas accès à mon code source, cette suggestion n'est pas portable. Ai-je mal compris votre intention? Bien sûr, je n'ai pas copié votre ligne verbatim; Je l'ai ajusté pour se conformer à mon installation Visual Studio! –