Firmy nie aktualizują VS nie chcąc. Używamy 2010SP1 na przykład w projekcie, który nie planuje wysyłki przez kilka lat. Używanie nowszej wersji oznaczałoby kupowanie nowych licencji na IDE, możliwość kupowania nowych licencji na używane przez nas wtyczki i oczywiście ryzykowanie niektórych niepokojących błędów. Zapłaciliśmy już za 2010 r. I wiemy, że 2010 r. Spełni nasze potrzeby.
Przyznaję, że czasem mnie to denerwuje; Naprawdę chciałbym najnowszą obsługę C ++ 11/14, obsługę AMP i ulepszone optymalizacje, ale tego rodzaju „aktualizacja do nowej błyszczącej” mentalności nie pasuje do większych, poważniejszych projektów.
Większość podmiotów korporacyjnych jest bardzo, bardzo konserwatywna w zakresie aktualizowania dowolnego oprogramowania, czy to Visual Studio, Office, Windows, Perforce, cokolwiek. Podczas gdy użycie Visual Studio 2005 jest obecnie dość rzadkie w grach, 2008 jest nadal dość powszechny. Bardzo niewielu korzysta z 2012 roku. Jest całkiem możliwe, że wprowadzenie 2012 roku nigdy nie nastąpi masowo i że następną popularną wersją Visual Studio będzie 2013 lub 2014.
Zobacz na przykład, jak szybko popularne zorientowane na entuzjastów wersje Linuksa aktualizują wersje w porównaniu z kadencją wydawniczą Redhat Enterprise lub Ubuntu LTS. Użytkownicy domowi i hobbyści mogą łatwiej usprawiedliwić aktualizacje, a entuzjaści często się o nie domagają, ale firmy zazwyczaj chcą jak najmniejszych zmian.
Kolejnym czynnikiem jest dziś kompatybilność z XBox 360. Głupio jest kupować i instalować dwie wersje kompilatora IDE / kompilatora, jeśli potrzebujesz konkretnej do kompatybilności z XBox. To, która następna wersja VS stanie się popularna dla gier, będzie zależeć w dużej mierze od tego, który kompilator XBox One zaleca do wydania wersji swoich zestawów deweloperskich (2012 jest używany dla zestawów beta używanych do uruchamiania gier, ale 2013 może być zalecany później uruchom tytuły).
Pod względem środowisk uruchomieniowych używanych przez kompilatory muszą one być dokładnie zgodne z używanym kompilatorem. Częściowo dzieje się tak z powodu działania C i C ++. Interfejsy są definiowane przez pliki nagłówkowe, które są naprawdę fantazyjnym sposobem na cięcie i wklejanie. Rozważ załącznik A:
void foo(char* name, int length);
A teraz rozważ wystawę B:
void foo(int length, char* name);
Gdyby te funkcje C były zawarte w dwóch różnych wersjach środowiska wykonawczego, oba byłyby symbolami, _fooale kod skompilowany do użycia jednej z nich wyraźnie nie działałby dla drugiej. Podczas gdy problemy ze zgodnością są na ogół nieco bardziej zaangażowane i subtelne, wynik końcowy jest nadal taki sam: kod skompilowany z VS2005 będzie miał nagłówek z VS2005, który opisuje tylko sposób działania środowiska wykonawczego VS2005. VS2012 jest dostarczany z całkowicie różnymi nagłówkami ukierunkowanymi na zupełnie inne środowisko wykonawcze.
Microsoft nie obsługuje celowania w starsze wersje, ponieważ tak naprawdę byłby to tylko problem. Będą musieli wysyłać, a następnie nadal utrzymywać stare nagłówki oprócz czasu wykonywania. Jest to stosunkowo niewielki powód, ponieważ dobre praktyki korzystania z bibliotek DLL w systemie Windows pozwalają programistom mieszać biblioteki przy użyciu różnych środowisk wykonawczych. Jeśli masz VS2012, możesz nadal łączyć się z bibliotekami utworzonymi za pomocą VS2005, o ile ty i biblioteka przestrzegacie kilku prostych zasad.
Platformy takie jak GNU / Linux dokładają starań, aby uniknąć tych problemów, ale przeszły przez nie, czasem na znacznie głębszym poziomie. Nadal pamiętam przejście z libc5 na glibc lub częste przerwy czasu w libstdc ++ (jest to jeden z powodów, dla których programiści Linuksa / UNIX-a przez lata pozostawali stosunkowo obojętni na temat C ++).
System Windows jest dostarczany z wywoływanym „ogólnym” środowiskiem wykonawczym C niskiego poziomu MSVCR.DLL, chociaż każda wersja kompilatora zawiera własną wersję, np MSVCRR110.DLL. Możesz podjąć wysiłek, aby użyć tylko wersji ogólnej, ale brakuje w niej dużej ilości funkcji, w tym większości procedur obsługi C ++, które zmieniają się z każdą wersją Visual Studio (i ciągle rozwijaną obsługą C ++). Zasadniczo nie jest to warte wysiłku i utraty funkcjonalności, chyba że naprawdę próbujesz stworzyć aplikację o zerowej zależności (narzędzia do odzyskiwania, narzędzia systemu operacyjnego, narzędzia bezpieczeństwa itp. Czasami należą do tej klasy).
Krótko mówiąc, każde Visual Studio ma swoją własną bibliotekę wykonawczą, a aplikacja skompilowana z tą wersją musi korzystać. Gry będą zazwyczaj pisane przy użyciu mniejszej niż najnowocześniejszy kompilator, a zatem będą wymagały starszego środowiska uruchomieniowego.