Zastrzeżenie: Jest to obejście , nie rozwiązanie twojej odpowiedzi, ale bardzo realna możliwość.
Jeśli chcesz mieć absolutną pewność, że nie ma żadnych zależności od samego VS - ale ma to swoje wady - w ustawieniach generowania kodu możesz wybrać opcję Multi Threaded (MT) / Multi Threaded Debug (MD) (dla kompilacji debugowania ) zamiast MT DLL (MTd) / MT Debug DLL (MDd).
Jakie są wady?
- Zwiększa rozmiar pliku wykonywalnego i plik binarny (chociaż przy tworzeniu gry jest to prawdopodobnie nieistotne)
- skompilowane w ten sposób nie skorzystają z aktualizacji bibliotek DLL środowiska uruchomieniowego. (np. jeśli Microsoft wyda VC ++ 2015 SP2, SP3, SP4 itp.) Ale to zależy od Ciebie.
- Większe użycie pamięci RAM (również nieistotne), ponieważ nie używasz ponownie istniejącego / załadowanego kodu (DLL)
- Musisz upewnić się, że wszystkie biblioteki, które łączysz, są skompilowane z tym samym środowiskiem wykonawczym, w przeciwnym razie połączenie może się nie powieść lub mogą wystąpić interesujące błędy w czasie wykonywania (prawdopodobnie nie, ale zdarzało mi się to raz w życiu w starszym projekcie, który został zaktualizowany do najnowszy VS)
A jakie są zalety?
- twój plik wykonywalny nie będzie miał „zewnętrznych” zależności od samego VS (bez wymagania msvc * .dll).
- niektóre osoby postrzegają to jako wzrost wydajności, ponieważ eliminuje się narzut wywołania DLL, podczas gdy jest to teoretycznie prawda, ulepszenia są znikome w praktyce
Sprawdź ten link, aby uzyskać bardziej szczegółowe wyjaśnienie oraz pułapki i problemy, które możesz napotkać przy użyciu statycznego środowiska uruchomieniowego.
Innym obejściem byłoby umieszczenie wszystkich wymaganych bibliotek DLL tam, gdzie jest twój plik binarny. Twoja aplikacja nie skorzysta z aktualizacji (bibliotek wykonawczych), ale to wszystko.
Prawdziwym rozwiązaniem jest dystrybucja aplikacji w trybie dll wydania / braku debugowania (MTd) i dostarczenie poprawnego redystrybucyjnego instalatora VC ++ (oraz wszelkich innych instalatorów bibliotek, których możesz użyć, np. OpenAL, DirectX9, PhysX) i umożliwienie użytkownikowi uruchomienia tego przed uruchomieniem aplikacji (jak wskazały inne odpowiedzi).
Upewnij się również, że użytkownik wie, że może zaktualizować sterowniki GPU (ponieważ zawierają one wiele środowisk wykonawczych dla wielu aplikacji, np. OpenGL, Vulcan).