Renommer .NET 2.0 Exécutable

Est-ce que quelqu'un connaît des pièges lors de la modification d'un nom de fichier exécutable C# .NET 2.0 lors d'un événement post-construction, étant donné que l'exécutable est fort et a un manifeste incorporé? De plus, l'exécutable sera signé par un tiers avant d'être empaqueté dans un programme d'installation.Renommer .NET 2.0 Exécutable

Je sais que tous les fichiers .config associés doivent également être renommés pour refléter le nouveau nom de l'exécutable.

Ai-je raison de deviner que la meilleure solution est de changer le nom de l'assembly dans les propriétés du projet plutôt que de renommer le nom du fichier exécutable? Le problème est que Visual Studio ne fonctionne pas bien avec les noms d'assembly conditionnels. (c'est-à-dire en ajoutant un attribut de condition à l'étiquette dans le fichier .csproj)

Source

2011-03-04 Brent Newbury

Vous semblez parler de deux problèmes, mais décrit non plus. Non, renommer un fichier n'est jamais un vrai problème. –

Il n'y a aucun avantage réel à nommer fortement un exe. L'avantage de nommer fortement une DLL est que quelqu'un ne peut pas le remplacer par sa propre version malveillante (et vous pouvez le mettre dans le GAC). Sauf si vous faites référence à votre exe dans un autre projet comme s'il s'agissait d'un DLL (ce qui serait étrange), vous n'avez pas besoin de le nommer fortement. – jonathanpeppers

@ Jonathan.Peppers - cela ressemble plus à une réponse qu'à un commentaire. Si vous le mettez comme une réponse, nous pouvons voter! – RQDQ

VS charge le projet une fois, puis le stocke en mémoire. Si vous voulez construire deux ensembles de VS vous pouvez ajouter cible AfterBuild et appeler MSBuild pour construire votre assemblée à nouveau, mais avec des paramètres différents:

<ProperttyGroup Condition="'$(BuildAgain)'==''"> 
    <!-- Default parameters to VS --> 
    <AssemblyName>Name1,Default</AssemblyName> 
<ProperttyGroup> 

<ProperttyGroup Condition="'$(BuildAgain)'=='true'"> 
    <!-- Overrided parameters --> 
    <AssemblyName>Name2.Custom</AssemblyName> 
<ProperttyGroup> 

<Target Name="AfterBuild" 
     Condition="'$(BuildAgain)'==''"> 
    <MSBuild Projects="$(MSBuildProjectFullPath)" 
       Properties="BuildAgain=true;Configuration=$(Configuration);Platform=$(Platform)" 
       Targets="Rebuild" 
</Target>

Source

2011-03-05 13:52:03

Fonctionne un régal! La seule chose à noter est que la cible AfterBuild devrait avoir 'Condition = '$ (BuildAgain) ==' '' pour arrêter l'erreur' Il y a une dépendance circulaire dans le graphe de dépendance cible impliquant la cible 'Build' ' –

Accepter. J'ai corrigé la réponse. –

Il n'y a pas de réel avantage à nommer fortement un exe. L'avantage de nommer fortement une DLL est que quelqu'un ne peut pas le remplacer par sa propre version malveillante (et vous pouvez le mettre dans le GAC). Sauf si vous faites référence à votre exe dans un autre projet comme s'il s'agissait d'un DLL (ce qui serait étrange), vous n'avez pas besoin de le nommer fortement.

Source

2011-03-04 22:02:04 jonathanpeppers

C'est juste quelque chose que nous avons toujours fait. Merci pour l'information, j'apprécie toujours d'autres connaissances, mais peut-être que cela aurait été mieux comme un commentaire plutôt que comme une réponse? Cela diminue simplement la probabilité que quelqu'un tente de répondre à la question de la liste. Encore une fois, c'est apprécié. –

Renommer .NET 2.0 Exécutable

Répondre

Questions connexes