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.
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 
Thanks to you two annoying āgitsā, you know who you are lol 
Work has already begun on my game engine
Thank you all, and team and everyone. 
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.
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 110Iā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 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.
If you already installed the develop build you should be able to simply register the tool as you already have it as per the instructions in documentation here.
https://docs.monogame.net/articles/tools/mgcb.html
If you donāt have it ā¦ verify that first in the program files folders for monogame.
Provided its not screwed up it should work.
If it doesnāt open the editor go to the content folder itself and then double click the mgcb file if the pipeline tool opens like that it means the editor is still bugged but its been registered with windows.
If not look to the documentations for the editior and look for the command lines to use for registering the tool manually. Though the above is prolly gonna work or not.
So youāve removed the ability for people to just download and install the tool like before? I admit that really sucks, as my mod community just needs the pipeline UI tool to compile their assets and then run my game. 
Most donāt have or use Visual Studio, so I will likely have to remain on 3.7 for now (I donāt want to, but Iām not going to make my modders set up an entire dev environment just to run a single executable pipeline tool).
If Iām still being an idiot and they can do that, Iām all ears lol.
And on top of that, I donāt use the tool inside my project either. Too many issues in the past with failed runtime compiles, so I just compile my assets outside the Visual Studio UI only when needed.
My engine is based around being dynamically configured at run time.