Jak używać innej nazwy zespołu dla różnych konfiguracji?

Question

W Visual Studio 2008 (i innych) podczas tworzenia aplikacji .NET lub silverlight, jeśli spojrzysz na właściwości projektu, wydaje się, że możesz mieć tylko jedną nazwę zespołu - we wszystkich konfiguracjach. Chciałbym skompilować mojej aplikacji jako:

MyAppDebug - w trybie debugowania i tylko MojaApl - w trybie zwolnienia

Czy ktoś wie, czy jest to możliwe?

Edit:

Wydaje niektórzy ludzie kwestionują zasadność pytania, więc wytłumaczę trochę dalej:

pracuję w aplikacji Silverlight, która zostanie automatycznie przesłany do nasza strona testowa, kiedy mam "rozwiązanie konstrukcyjne". Kłopot polega na tym, że zespół testowy testuje teraz wersję online, podczas gdy ja pracuję nad nową. Tak więc chcę mieć adres URL. \ MyApp.html dla standardowej wersji, którą zespół QA przetestuje, a następnie. \ MyApp.html? Version = debugowanie dla bieżącej wersji, nad którą pracuję.

Answer 1

udało mi się osiągnąć to, co byłem po za pomocą skryptu post-build:

if "$(ConfigurationName)"=="Debug" goto debug 
"$(SolutionDir)ftp.bat" "$(TargetDir)$(TargetName).xap" 
:debug 
"$(SolutionDir)ftp.bat" "$(TargetDir)$(TargetName).xap" "$(TargetDir)$(TargetName)Debug.xap" 

Mój skrypt ftp zasadzie akceptuje opcjonalny parametr na końcu, który jest co wgrać plik jako. Tak więc na moim lokalnym komputerze nazwy plików są zawsze takie same, ale w trybie debugowania przesyłamy je z "Debugowanie" na końcu nazwy pliku. Teraz mogę wybrać na mojej stronie wersję, która ma być wyświetlana.

Answer 2

Oczywiście można dodać zdarzenie typu post-build, aby zmienić nazwę zespołu. To zadziała, jeśli twoje rozwiązanie ma tylko jeden zespół.

Ale jeśli twoje rozwiązanie składa się z kilku projektów, zwykle masz jeden projekt odwołujący się do zespołu generowanego przez inny problem. Wyobraź sobie, że twoje rozwiązanie ma dwa projekty: pierwszy tworzy plik Windows Forms exe (MyApp.EXE), który odwołuje się do zestawu utworzonego przez drugi projekt (MyData.DLL).

W tym przykładzie plik EXE debugowania zostanie nazwany MyAppDebug.EXE i musi odwoływać się do MyDataDebug.EXE. A to nie zadziała w przypadku zmiany nazwy w wydarzeniu następującym po instalacji.

Dlatego zdecydowanie nie należy zmieniać nazwy.

Answer 3

Jeśli absolutnie nie twoje serce ustawić na robienie tego, to można zrobić coś takiego w pliku AssemblyInfo.cs:

#if DEBUG 
[assembly: AssemblyTitle("MyAssemblyDebug")] 
#else 
[assembly: AssemblyTitle("MyAssembly")] 
#endif 

Jest to jednak dość dużo hack. Ponadto, dokumentacja MSDN jest całkiem jasna, że ​​nazwa pliku nie jest nawet brana pod uwagę przy ładowaniu złożenia, więc wykonanie prostej zmiany nazwy nie zmieni ogólnej tożsamości zespołu.

Jak wspomniano powyżej, generalnie będzie to zły pomysł, ponieważ wprowadzi tylko zamieszanie i problemy z konserwacją. Jeśli wszystko co robisz jest zmiana nazwy plików, wykonując operację po produkcji:

przemianować "$ (ProjectDir) bin \ Debug \ SomeAssembly.dll" SomeAssemblyDebug.dll

Wtedy haven” t naprawdę zmieniła tożsamość twojego zespołu tylko nazwę pliku. Można go nazwać Bob.dll i nadal będzie mieć tę samą tożsamość w odniesieniu do CLR. Ma to znaczenie tylko wtedy, gdy używasz silnie nazwanego zestawu, który zostanie wdrożony w GAC. W takim przypadku użytkownik nie może mieć innej nazwy pliku niż nazwa zespołu.

Jeśli naprawdę próbujesz zmienić nazwę zespołu, a nie tylko nazwę pliku, to masz inny problem na ręce, ponieważ jest on teraz zupełnie innym zestawem niż CLR.

Myślę, że lepiej jest żyć zgodnie ze standardami, które już istnieją. Jeśli okaże się, że musisz zrobić coś naprawdę dziwnego, może powinieneś zadać sobie pytanie, dlaczego to właśnie próbujesz to zrobić. Może być lepsze rozwiązanie.

Answer 4

Uczyniłem to, komunikując się z plikiem .csproj: albo przenieś atrybut do specyficznych dla konfiguracji grup właściwości, albo po prostu użyj warunku. Przykład:

<AssemblyName>MyApp</AssemblyName> 
<AssemblyName Condition=" '$(Configuration)' == 'Debug' ">MyAppDebug</AssemblyName> 

Visual Studio staje się nieco okaleczony podczas uruchamiania brudząc z .csproj jak ten - na przykład już nie mogę F5/F10, aby uruchomić projekt w trybie debugowania; mówi mi, że "MyApp.exe" nie został znaleziony (tj. debugger próbuje uruchomić zestaw z niewłaściwym AssemblyName).