Visual Studio Code - Building and background console

1

Hello,

When building a simple Monogame DesktopGL project on VS code (.NET Core 2.2, C# and C# extensions) with :

dotnet build -r win-x64

I get an “.exe” that runs fine (blue monogame window) but I also got a
console running in the background.

  1. Why is that and how to get rid of this background console ? (OutputType is “WinExe”
    in “*.csproj”.)

  2. Are there some arguments to add to “tasks.json” in order to automate this build command ?

  3. When I build :

In VS Code (.NET CORE 2.2) : a Monogame Desktop GL project
In VS 2017 (.NET Framework 4.5) : a Monogame CrossPlatform Desktop project

I don’t understand the differences in the produced output folders. Both contains the game “.exe” and a “.pdb”, but apart from that, content is pretty different (see image). Why VS Code output does not contain the Monogame.Framework.dll ? Why VS 2017 output contains SDL2.dll and not VS Code one ? If proper runtimes are installed on the machine, could both these “.exe” be run ?

Thanks for your help !

2

  1. Add a nuget reference to NSubsys to hide the console. That’s no longer necessary in .NET Core 3.0.

  2. Not sure what you mean. You can just add a task that does exactly the same as what you do using the CLI, does that not cover it?

  3. That looks wrong. MonoGame.Framework.dll should be copied over and native libs too. What does your csproj look like?

3

Thanks for your answer :

  1. Thanks a lot, it works like a charm ! I’d love to understand the inner workings of this, been googling for hours…

  2. Yes exactly, but was wondering how to pass the “-r win-x64” argument to the dotnet build command in the task file. Documentation is not that obvious for beginners.

  3. Here is my csproj file.

4
  1. This SO post has some details on how it works. And if you are using NSubsys, I would recommend switching it back to Exe instead of WinExe.
  2. This isn’t specific to MonoGame, but these docs have some details on how to create custom tasks in VS Code. I believe you can just put your whole dotnet build command in a custom task.
  3. When you build a .NET Core app, it’s intended to be run in the context it was built: on your computer within that specific folder. If you switch to Exe then I believe it won’t even produce MyGame.exe but just MyGame.dll. If you want to run it, you can run dotnet MyGame.dll. The reason it will only run on your computer is because MyGame.deps.json points to the location of all of the dependencies, like MonoGame.Framework.dll. If you want to be able to run it on another computer, you should use dotnet publish, which should copy the dependencies. In particular, I recommend dotnet publish -r win-x64 --self-contained, which creates a “self-contained” deployment that also includes the .NET runtime so it can be run on a computer that doesn’t already have the runtime installed.
1 Like
5

Thanks for your answer :

2/ Indeed, a simple :

 { 
        "label": "build win",           
        "command": "dotnet build -r win-x64",
        "type": "shell",
        "problemMatcher": "$msCompile"        
},

in the tasks.json did the trick. Apparently build command only produces an “.exe” if -r ... is specified.

3/ I tried dotnet publish -r win-x64 --self-contained. The produced “.exe” runs fine, but 200+ dll (!) are included in the output folder (see picture), which is fine if runtime is not installed on target computer.

“.NET core” documentation specifies that framework dependant executable (so with far fewer dlls) can be built using dotnet publish -r win-x64 --self-contained false.

However, no “.exe” can be found in the produced output folder (there is maybe an ambiguity on the word “executable” in the .NET Core doc ?). Anyway, this is apparently solved with .NET Core 3.0.

6

CornFlowerBlue [shakes fist at screen] :fist:

I am assuming you are using a dev build to utilise .NetCore, if not, umm, how are you doing it with VS? :upside_down: