Переименовать исполняемый файл .NET 2.0

Кто-нибудь знает о каких-либо ошибках при изменении имени исполняемого файла C # .NET 2.0 в событии после сборки, учитывая, что исполняемый файл имеет строгое имя и имеет встроенный манифест? Кроме того, исполняемый файл будет подписан третьей стороной перед его упаковкой в ​​программу установки.

Я знаю, что любые связанные файлы .config также необходимо переименовать, чтобы отразить новое имя исполняемого файла.

Я также прав, предполагая, что лучшим решением будет изменить имя сборки в свойствах проекта, а не переименовывать имя исполняемого файла? Проблема в том, что Visual Studio плохо работает с условными именами сборок. (т.е. добавление атрибута условия к тегу в .csproj)


visual-studio .net c# .net-assembly
person Brent Newbury    schedule 04.03.2011    source источник
comment
Кажется, вы упомянули две проблемы, но не описали ни одну. Нет, переименование файла никогда не является реальной проблемой.   -  person Hans Passant    schedule 04.03.2011
comment
Нет никакой реальной пользы от строгого именования exe. Преимущество строгого именования dll заключается в том, что кто-то не может заменить ее собственной версией вредоносной (и вы можете поместить ее в GAC). Если вы не ссылаетесь на свой exe в другом проекте, как если бы это была dll (что было бы странно), вам не нужно называть его строгим.   -  person jonathanpeppers    schedule 04.03.2011
comment
@Jonathan.Peppers - это больше похоже на ответ, чем на комментарий. Если вы поместите это как ответ, мы можем проголосовать за него!   -  person RQDQ    schedule 04.03.2011
comment
Только что сделал это. Иногда я чувствую серую зону между комментарием и ответом, так как я не был на 100% уверен, что удаление строгого имени решит его проблему, даже если оно, скорее всего, не нужно.   -  person jonathanpeppers    schedule 05.03.2011
comment
@RQDQ - Джонатан не ответил на мой вопрос, поэтому я сказал, что это должен был быть комментарий, а не ответ. Я никогда не спрашивал, является ли проблемой строгое имя исполняемого файла, я спрашивал, является ли проблемой переименование управляемого исполняемого файла (который просто имеет строгое имя и встроенный манифест). Это ценная информация, но она не отвечает на мой вопрос.   -  person Brent Newbury    schedule 08.03.2011
comment
@Hans Passant - я никогда не упоминал о проблемах, я задал простой вопрос (с побочным вопросом для бонусных баллов), на который вы дали простой ответ. Спасибо за ответы на вопросы.   -  person Brent Newbury    schedule 08.03.2011

Ответы (2)


arrow_upward
2
arrow_downward

VS загружает проект один раз, а затем сохраняет его в памяти. Если вы хотите собрать две сборки из VS, вы можете добавить цель AfterBuild и вызвать MSBuild для повторной сборки сборки, но с другими параметрами:

<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>
person Sergio Rykov    schedule 05.03.2011
comment
Работает удовольствие! Единственное, что следует отметить, это то, что цель AfterBuild должна иметь Condition=' $(BuildAgain) =='' , чтобы остановить ошибку «В графе целевых зависимостей есть циклическая зависимость, включающая целевую сборку». - person Brent Newbury; 08.03.2011

arrow_upward
1
arrow_downward

Нет никакой реальной пользы от строгого именования exe. Преимущество строгого именования dll заключается в том, что кто-то не может заменить ее собственной версией вредоносной (и вы можете поместить ее в GAC). Если вы не ссылаетесь на свой exe в другом проекте, как если бы это была dll (что было бы странно), вам не нужно называть его строгим.

person jonathanpeppers    schedule 04.03.2011
comment
Это то, что мы всегда делали. Спасибо за информацию, я всегда ценю любые другие знания, но, может быть, это было бы лучше в качестве комментария, а не ответа? Это просто снижает вероятность того, что кто-то попытается ответить на вопрос из списка. Опять же, это ценится. - person Brent Newbury; 05.03.2011