Noticed, if I put my game on a fresh Windows 10 installation - the game doesn’t execute(quits immediately). I believed that with publish/release build, it should have all the dependencies it needs - or is that not quite right?
Maybe it worked on the other Win10 drive because it already had certain things installed?
[btw - I have it listed as compatible with Win7,…10,…so that’s why it’s still MG 3.7]
Maybe I should try a Windows Universal build and publish? Or will there always be certain external dependencies that need to be installed (like dot net stuff or something?)
Just wondering if anyone has any ideas about this?
Depending on how you build it, it might be missing the necessary .NET runtime.
Things like Steam and the Itch.io launcher will automatically install the right runtime your game needs, but if you’re downloading it, you’ll need to install the .NET runtime yourself from Microsoft’s website.
If you want to not have that requirement, you can switch the “deployment mode” from “framework-dependent” to “self-contained” in the publish menu of visual studio. That will include the .NET runtime into the build, but it does explode the size of it by quite a bit.
1 Like
Thanks - I checked into it a little more (it has been a while since I built it).
( I was mistaken about it being MG3.7 - it was actually made in Visual Studio 2019 using Monogame 3.8.0 )
I used the publish option & looked through all the DLL’s and it looks like all dependencies seem to be there. [ I suspect OpenGL needs are covered by SDL2.dll & soft_oal.dll ].
ie:
dotnet publish -c Release -r win-x64 /p:PublishReadyToRun=false /p:TieredCompilation=false --self-contained
Odd thing is, if I use my old Windows 10 drive (which has not been updated), the game/folder will run fine. If I install the exact same thing on updated windows 10 - it doesn’t even start (no error shows nor logged). I tried reinstalling Windows 10 on that drive again - updated it - updated drivers - tried another game(worked)… but my game still doesn’t start. Something seems to be different about updated Win10 from my old one that’s causing it to not work.
Anyway, it’s actually causing me to lose customers on Steam(rise in refunds recently). I thought I might be forced to make a VS2022 updated Win10 DirectX version, however that won’t work on Windows 7 as far as I know - and I still have a lot of users who use Win7 and old Win10(some I know personally). As far as I know, Steam only has 3 options for build depots: Linux, Mac, Windows… but there aren’t separate Windows version depot/slots.
So… this is a tricky problem to solve unless I could remake it with VS 2019 and monogame 3.8 for DirectX 11 and see if that one works on all Windows platforms? Seems I can no longer get that combo to install properly.
I’ll keep looking into the matter.
Update:
Got the DirectX version working on the updated Win10. (Since I was using the older 3.8 build, I had to make a workaround for a couple minor bugs in DX version (like soundInstance Stop() Play() issue [which is fixed now], shader differences, window-size-constructor & initialize fix, etc)).
Still not sure why updated-windows-10 won’t allow the other one to run (OpenGL version)… but all other windows versions work. 
Aw well - DX version will work for Win depot - good enough for me! 
For what it’s worth i ran into an issue recently where it looked like something has changed with windows and opengl and it had to do with PCs with an integrated graphics card and a high performance gpu (mostly laptops?).
What was happening was that the integrated gpu was being automatically chosen to run the game but sdl would fail to create the window, as if the integrated graphics card was not compatible with that version of opengl, which afaik is just false.
The answer/workaround seemed to be to force the system to select the high performance gpu instead which did not have this problem. I dont have the line of code to hand but if you search “problem with beginner tutorial for opengl” on the forum you should find it.
Good to know. Looks like MS updated or fixed something, because today I tried the SDL2 one again before checking into what you mentioned and suddenly it works.
A bit of a mystery 