MonoGame 3.8 prerelease packages are up on NuGet

Will the sound capabilities be upgraded with this release?

1 Like

Not sure what you’re referring to specifically, but there’s no API changes for Song or SoundEffect.

I have a small solution set up with MonoGame 3.7 where I have shared code and shared content in a shared project. Will it work the same with version 3.8?

It will.

1 Like

@harry-cpp seem to have come across a bug, I am still testing, but 3.7 on xbox worked fine, however 3.8 Nuget is causing issues with the window display, it will not go full screen no matter how much I replicate the code from my 3.7 setup, could this be a bug?

Will try to keep testing but my room is now a toasty 36*C…

EDIT

Yep, something is definitely broken…

Basically, the viewport is offset, but is still rendering a 1920x1080 output

I used the extensions template. but it appears to be an issue within 3.8 than anything else.

@harry-cpp

I found the issue, I should have taken a gander into App.xaml.cs really early and compared it to an older project instead of a 3.8 that somehow randomly worked and then shapeshifted…

Anyway, I found the issue and hope you can add the fixes to the NuGet packages?

I am still getting used to Git and NuGet [Though I think I have gotten used to NuGet now], I suppose that is my next challenge for today.

I hope I don’t sound like I’m nagging but I’m curious when we can see 3.8 go live to production?

1 Like

There are still some issues to close first I guess:

I think he was asking when those could be expected to be closed xd

You don’t need to close all of them, only critical/serious/important ones, the rest can be put in a .1+ patch

Following up on my reported issues, I now have XBOX UWP working 100% and full screen as denoted earlier.

I have also gone Pro GitHub too :slight_smile: Thanks to you two annoying ‘gits’, you know who you are lol :heart_decoration:

Work has already begun on my game engine :slight_smile:

Thank you all, and team and everyone. :sake: :pray:t2:

I gave vs 2019 and the nuget a shot yesterday.

One thing not mentioned in the documentation which is sort of important.

On this page below we have a incomplete… thus… incorrect set of instructions.
https://docs.monogame.net/articles/tools/pipeline.html

The above omits adding the version number to the line for registering the tool from the nuget develop.

–version xxxxxxx-develop

In my case i had to run.

dotnet tool install --global dotnet-mgcb-editor --version 3.8.0.1375-develop
Then
mgcb-editor --register

Unfortunately it still didn’t work and appears to be related to visual studio in that vs doesn’t open the content file when you double click it like vs 2017 would.

Conversely going to the folder directly and double clicking the mgcb file.
The OS itself did open it with the pipeline tool directly.

img7

Oh writing this out i just realized i registered it to windows not visual studio dunno if that matters.

C:\WINDOWS\system32>dotnet tool install --global dotnet-mgcb-editor --version 3.8.0.1375-develop
You can invoke the tool using the following command: mgcb-editor
Tool 'dotnet-mgcb-editor' (version '3.8.0.1375-develop') was successfully installed.

C:\WINDOWS\system32>mgcb-editor --register
Associating MGCB Editor with .mgcb extension in Windows...
Association complete!

Registered MGCB Editor!

I also attempted to set this thru the visual studio command line itself.

Apparently this command didn’t matter or something is wrong with the editor that vs doesn’t like.

As a alternate experiment.

Simply adding Notepad++ is as easy as just using the add program button on the spot.

Then setting it as the default will auto open the mgcb file with notepad ++ directly.

So theoretically i could make a monogame installed exe and register then open the mgcb file in the same manner to open and edit the monogame file with a monogame app that would be ironic.

I wonder if it has anything to do with the - characters in the tool name or something silly. I was considering copying and then renaming the tool and trying it but i have no idea were it is actually located at.

1 Like

There’s a PR out to fix the instructions.


Currently the new MGCB Editor only registers with Windows, not with Visual Studio. When working on the tool, the previous way of registering wasn’t working with VS 2019. It looked like the method of setting default apps within VS was changed years ago so I’m surprised it even worked with VS 2017. In any case, I think VS registration will be added to the --register command in the future.

I remember reading that this was a bug with VS and I think they fixed it to use the system default if you don’t override it in the latest versions.

That’s all from memory and I can’t find the source though.

humm i think the pipeline tool randomly got corrupted on me somehow.
when i installed the vs2019 nuget it overwrote the 3.7.1 pipeline tool i was using in vs2017 as well, with the mgcb 3.8 editor which wont open files and randomly crashes with the following.

never mind the pipeline tools copy to clipboard apparently doesn’t work either when it crashed.

unfortunately now i have a broken pipeline editor which replaced my working pipeline tool i don’t think its quite ready yet.

So uh anyone got a extra pipeline tool a older one that still works ?

copy pasted manually.

System.ComponentModel.Win32Exception (193): The specified executable is not a valid application for this OS platform.
   at System.Diagnostics.Process.StartWithCreateProcess(ProcessStartInfo startInfo)
   at System.Diagnostics.Process.Start()
   at System.Diagnostics.Process.Start(ProcessStartInfo startInfo)
   at System.Diagnostics.Process.Start(String fileName)
   at MonoGame.Tools.Pipeline.MainWindow.CmdOpenItem_Executed(Object sender, EventArgs e) in C:\BuildAgents\MonoGameWin1\work\f7381a85a626990\Tools\MonoGame.Content.Builder.Editor\MainWindow.cs:line 581
   at Eto.Forms.Command.OnExecuted(EventArgs e)
   at Eto.Forms.Command.Execute()
   at Eto.Forms.Command.System.Windows.Input.ICommand.Execute(Object parameter)
   at Eto.PropertyStore.CommandWrapper.Command_Execute(Object sender, EventArgs e)
   at Eto.Forms.MenuItem.OnClick(EventArgs e)
   at Eto.Forms.MenuItem.Callback.OnClick(MenuItem widget, EventArgs e)
   at Eto.Wpf.Forms.Menu.MenuItemHandler`3.OnClick()
   at Eto.Wpf.Forms.Menu.MenuItemHandler`3.<Initialize>b__2_0(Object sender, RoutedEventArgs e)
   at System.Windows.EventRoute.InvokeHandlersImpl(Object source, RoutedEventArgs args, Boolean reRaised)
   at System.Windows.UIElement.RaiseEventImpl(DependencyObject sender, RoutedEventArgs args)
   at System.Windows.UIElement.RaiseEvent(RoutedEventArgs e)
   at System.Windows.Controls.MenuItem.InvokeClickAfterRender(Object arg)
   at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
   at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
   at System.Windows.Threading.DispatcherOperation.InvokeImpl()
   at MS.Internal.CulturePreservingExecutionContext.CallbackWrapper(Object obj)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
--- End of stack trace from previous location where exception was thrown ---
   at MS.Internal.CulturePreservingExecutionContext.Run(CulturePreservingExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Windows.Threading.DispatcherOperation.Invoke()
   at System.Windows.Threading.Dispatcher.ProcessQueue()
   at System.Windows.Threading.Dispatcher.WndProcHook(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
   at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
   at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
   at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
   at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
   at System.Windows.Threading.Dispatcher.LegacyInvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Int32 numArgs)
   at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)
   at MS.Win32.UnsafeNativeMethods.DispatchMessage(MSG& msg)
   at System.Windows.Threading.Dispatcher.PushFrameImpl(DispatcherFrame frame)
   at System.Windows.Threading.Dispatcher.PushFrame(DispatcherFrame frame)
   at System.Windows.Threading.Dispatcher.Run()
   at System.Windows.Application.RunDispatcher(Object ignore)
   at System.Windows.Application.RunInternal(Window window)
   at System.Windows.Application.Run(Window window)
   at Eto.Wpf.Forms.ApplicationHandler.Run()
   at Eto.Forms.Application.Run(Form mainForm)
   at MonoGame.Tools.Pipeline.Program.CommandLineInterface.Run(InvocationContext context, String project) in C:\BuildAgents\MonoGameWin1\work\f7381a85a626990\Tools\MonoGame.Content.Builder.Editor\Program.cs:line 110

I’ve been using the 3.7.1 content pipeline tool with the Monogame 3.8 beta - mostly by accident in how I setup 3.8 initially - but decided to wait to see if there were any issues. For the most part everything has worked fine.

An important note about the 3.7.1 pipeline tool. If you install monogame 3.7.1 fresh out of the box, the tool doesn’t work because it’s missing a file or something. There’s a forum post about it, but I can’t find it at the moment. I ran in this problem when initially setting up my workspace. The solution was to install 3.7.0 and then install 3.7.1 on top of that.

As for where to download the tool by itself, that I’m not sure, but I suppose you could reinstall 3.7 since you’re getting the 3.8 libraries via nuget now? I’m sure there’s copies floating around, though.

If I wanted to look at the exact source code of the NuGet build (3.8.0.1375-develop), how would I do that? I’ve looked into the development branch of GitHub and I don’t see tags or anything that I could use as a reference.

Any chance on continuing to update NuGet pre-release packages in the future with developer builds even after 3.8 goes stable?

3.8 stable is the update to 3.8 pre-release, I don’t understand the meaning of your question.

This request was relevant for about an hour :slight_smile: lol
Congrats on the 3.8 launch btw!

When I ran into issues with the pre-release NuGet packages, I wanted to grab the source code from GitHub that matched exactly what is in the pre-release package to look into it. I was looking for a tag or branch or something to use as a reference point and couldn’t find one.

I have what feels like a stupid question… But how do I get the new build tool working with this release? It says all of my content was built with a previous release (obviously). When I run the tool, it’s still the 3.7 version.