@Cory_Kroll Ok, I’ve googled some more and that’s what I’ve found: VS 2019 template search has been broken for months. VS team seem to have failed to fix it and introduced some tag system which may fix the search. I’ll try adding that right now and will upload a new in-dev build which hopefully will work.
Also yeah, the uninstaller is indeed not registered, I’ll try to fix that too.
@Cory_Kroll Ok, uploaded a new build. Now uninstaller shows up in the Remove Prgrams, and… well, searching is still broken. The best I could do is add the tags in project templates. Now you can switch Project Type filter to Monofoxe and all the templates will show up.
Also created a bugreport for VS team describing this issue.
@gn.fur
Ok good news - the templates are placed at the path you’ve indicated, which for me was:
C:\Users%username%\Documents\Visual Studio 2019\Templates\ProjectTemplates\Visual C#\Monofoxe v2-dev
I did find that Monofoxe is showing up under the Project Types filter.
However, just typing Monofoxe doesn’t bring up the results.
I’d have to either know what to look for in the filter or scroll to the bottom.
I’d be really interested in any articles you found about search indexing bring broken, etc. specifically around the name/description search.
I’m interested in writing templates myself as would certainly share what I found with it.
Also could you link to the issue you created for the VS team?
So I think proceeded to create a project from every template. Here are my specific finding, and then general notes at the end.
TL;DR All generated a template, none compiled directly to launching a hello world I’d expect (the cornflower blue screen).
Monofoxe Class Library (.NET Standard)
Blank Monofoxe Cross Platform Desktop Project
Blank Monofoxe Windows Project
Monofoxe Cross Platform Desktop Project
1 output, Stack1 ifstack, Boolean inResponseFile)1 output, Stack1 ifstack, Boolean inResponseFile)1 args) 1> at MGCB.MGBuildParser.Parse(IEnumerable1 args)Monofoxe Shared Project
1 output, Stack1 ifstack, Boolean inResponseFile)1 output, Stack1 ifstack, Boolean inResponseFile)1 args) 1> at MGCB.MGBuildParser.Parse(IEnumerable1 args)All
Where do you create new projects? What reference paths are in MGCB file? Exception seems like it’s something that has to do with your system not permitting to write into the file. I’ve seen something baguely similar with some security settings.
Blank projects aren’t supposed to compile by themselves, they need Shared project to be referenced in them.
…and yes, I’ve fucked up reference paths for blank projects. : - D
Will fix it right away.
Issue: Developer Community
Also, nuget will not work, since you need to set up some files to make Monofoxe work, which goes against “make it at simple as possible” rule of mine.
@Cory_Kroll
Ok, fixed warnings and template references. Still no idea what can cause Nopipeline to fail, tho. Generated MGCB config and paths you’re creating projects in may give some info.
For these projects generated directly from your template, I created them on my Desktop.
Not my typical location, but there shouldn’t be any permissions issues.
I downloaded the latest version and used the template Monofoxe Cross Platform Desktop Project.
I immediately attempted to build the template after creating it and got this out:
1>------ Build started: Project: Monofoxe Cross Platform Desktop Project, Configuration: Debug Any CPU ------
1> NoPipeline v1.1.0.0
1> Reading MGCB config C:/Users/Cory/Desktop/Monofoxe Cross Platform Desktop Project/Content/Content.mgcb
1>
1> Reading setting: /outputDir:bin/$(Platform)
1> Reading setting: /intermediateDir:obj/$(Platform)
1> Reading setting: /config:
1> Reading setting: /profile:Reach
1> Reading setting: /compress:False
1>
1> Reading reference: C:/Program Files (x86)/Monofoxe Engine/v2-dev/lib/Pipeline/Pipefoxe.dll
1>
1> Reading content:Content.mgcb
1> Reading content:Graphics/default.spritegroup
1> Reading content:Effects/AlphaBlend.fx
1> Reading content:Fonts/Arial.spritefont
1> Finished reading MGCB config! Got 4 items.
1>
1> -------------------------------------
1>
1> Reading NPL config.
1>
1> Reading reference: C:\Program Files (x86)/Monofoxe Engine/v2-dev/lib/Pipeline/Pipefoxe.dll
1>
1> Reading content for: Content.mgcb
1> Reading Content.mgcb
1> Reading content for: Audio/Music/*.ogg
1> Reading content for: Audio/Sounds/*.wav
1> Reading content for: Graphics/Default.spritegroup
1> Reading Graphics/default.spritegroup
1> Reading content for: Effects/*.fx
1> Reading Effects/AlphaBlend.fx
1> Reading content for: Maps/*.tmx
1> Reading content for: Fonts/*.spritefont
1> Reading Fonts/Arial.spritefont
1>
1> Finished reading NPL config!
1>
1> -------------------------------------
1>
1> Checking integrity of the final config. Hold on tight!
1>
1> Checking C:\Users\Cory\Desktop\Monofoxe Cross Platform Desktop Project\Content\Content.mgcb
1> Checking C:\Users\Cory\Desktop\Monofoxe Cross Platform Desktop Project\Content\Graphics/default.spritegroup
1> Checking watch for Default/*.png
1> Checking wildcars for: C:\Users\Cory\Desktop\Monofoxe Cross Platform Desktop Project\Content\Graphics\Default
1> Checking C:\Users\Cory\Desktop\Monofoxe Cross Platform Desktop Project\Content\Graphics\Default\monofoxe.png
1> Modifying: C:\Users\Cory\Desktop\Monofoxe Cross Platform Desktop Project\Content\Graphics\Default\monofoxe.png
1> Checking watch for Default/*.json
1> Checking wildcars for: C:\Users\Cory\Desktop\Monofoxe Cross Platform Desktop Project\Content\Graphics\Default
1> Checking C:\Users\Cory\Desktop\Monofoxe Cross Platform Desktop Project\Content\Graphics\Default\monofoxe.json
1> Modifying: C:\Users\Cory\Desktop\Monofoxe Cross Platform Desktop Project\Content\Graphics\Default\monofoxe.json
1> Checking C:\Users\Cory\Desktop\Monofoxe Cross Platform Desktop Project\Content\Effects/AlphaBlend.fx
1> Checking C:\Users\Cory\Desktop\Monofoxe Cross Platform Desktop Project\Content\Fonts/Arial.spritefont
1>
1> Checking reference: C:/Program Files (x86)/Monofoxe Engine/v2-dev/lib/Pipeline/Pipefoxe.dll
1>
1> -------------------------------------
1>
1> Saving new config as C:/Users/Cory/Desktop/Monofoxe Cross Platform Desktop Project/Content/Content.mgcb
1>
1> Done! \^u^/
1>
1> Unhandled Exception: System.NotSupportedException: The given path's format is not supported.
1> at System.Security.Permissions.FileIOPermission.EmulateFileIOPermissionChecks(String fullPath)
1> at System.Security.Permissions.FileIOPermission.QuickDemand(FileIOPermissionAccess access, String fullPath, Boolean checkForDuplicates, Boolean needFullPath)
1> at MGCB.MGBuildParser.ParsePreprocessArg(String arg, List`1 output, Stack`1 ifstack, Boolean inResponseFile)
1> at MGCB.MGBuildParser.ParsePreprocessArg(String arg, List`1 output, Stack`1 ifstack, Boolean inResponseFile)
1> at MGCB.MGBuildParser.Preprocess(IEnumerable`1 args)
1> at MGCB.MGBuildParser.Parse(IEnumerable`1 args)
1> at MGCB.Program.Main(String[] args)
1>C:\Program Files (x86)\MSBuild\MonoGame\v3.0\MonoGame.Content.Builder.targets(84,5): error MSB3073: The command ""C:\Program Files (x86)\MSBuild\MonoGame\v3.0\Tools\MGCB.exe" /quiet /platform:DesktopGL /@:"C:\Users\Cory\Desktop\Monofoxe Cross Platform Desktop Project\Content\Content.mgcb" /outputDir:"bin\DesktopGL\Content" /intermediateDir:"obj\DesktopGL\Content"" exited with code -532462766.
I then noticed that I couldn’t open the Content.mgcb at all in the MonoGame Pipeline Tool, getting the following error:
Content.mgcb: Failed to open the project due to an unknown error.
If I go into the .mcgb file and remove the following section, I can then open it in the editor:
#begin Content.mgcb
/importer:AssetInfoImporter
/processor:PassThroughProcessor
/build:Content.mgcb
I then noticed if I try to add in the .mcgb file, an Importer does show up in the drop down, called ‘Asset Info Importer - Monofoxe’. I set the ‘No Processing Required’ dropdown for the Processor for the .mgcb asset as well to match your template. However, then clicking the option to build in the MonoGame Pipeline Tool does nothing, and closing the trying to reopen the .mgcb file in the MonoGame Pipeline Tool causes it to start crashing again.
If I remove your .mgcb asset from the Content.mgcb, the content builds fine. However, then building the entire project still gives me the error in the Output, so something else is up.
I took a look at Content.npl and it has this path:
%PROGRAMFILES%/Monofoxe Engine/v2-dev/lib/Pipeline/Pipefoxe.dll
The problem is that %PROGRAMFILES% resolved to C:\Program Files
However, C:/Program Files/Monofoxe Engine/v2-dev/lib/Pipeline/Pipefoxe.dll doesn’t exist on my machine.
The program is installed under C:\Program Files (x86)\Monofoxe Engine\v2-dev\lib\Pipeline\Pipefoxe.dll
So pathing might be an issue as a result of the (x86).
I’m running a Windows 10 64-bit machine - but I think nowadays I’m probably what most users would be running.
Changing this didn’t resolve the project building issue, but maybe it is a hint to other path issues that might be in the toolchain?
In regards to NuGet, I think we are on the same page of making it as simple as possible.
For me, when I’m working with a git repository I’m looking to clone it, build it, and run it. Ideally this means not having to know what additional software I’d have to install for local dependencies. If any libraries can be replaced with a NuGet equivalent, this would be ideal. This is also a huge help when setting up a CI/CD pipeline, as generating a new build agent would ideally not require the installation of custom software in order to automate it in a cloud (like DevOps).
Ok, so:
Except you still need Monogame, which has to be installed. : - )
Making it run on nuget is a whole heap of problems. First of all, you can’t install templates via Nuget, which is very important. Dunno about you, but I don’t want to manually set up Game1, GameController, resource loading and resources themselves. Second, Pipeline Tool also requires a reference, which can’t be really wired up to nuget, since it’s not a project. Third, Nopipeline also required .targets entry in .csproj, and it has to run before Content Pipeline.
If you know how to solve those issues – cool, let me know, but as I see it, making it an installer is the simpliest way. Monofoxe isn’t just a library which you can optionally install – it’s a whole engine on top of which you build a game. Spending two seconds to install the thing isn’t that difficult, I don’t think you hop onto a new machine every day.
Tried to run it myself in a secured folder and it gave me a different exception.
Open mgcb config in text editor, find /reference: entry and replace all “/” for all “” in the path. Then rename .npl comfig to something other than Content, so it doesn’t run and mess up your mgcb. Just make sure to run it at least once, so that .npl actually generate references and stuff.
Also kinda forgot to mention #begin Content.mgcb. It should… work? It’s treated as a regular resource.
YOS
Pinned down the source of issues. I’ve been running it on the MG 3.7.1 and you – on dev build. I’ll try to investigate what the issue is, but can’t promise anything. I am not supporting dev build which breaks new stuff every day. : - D
…and nope, it’s not something that can be easily fixed. I have some ideas on how that could be fixed, but I just recommend downgrading to 3.7.1, sorry. If I’ll start chasing the dev build support, I’ll go insane. I will fix the (x86) paths in a couple of days, but yeah, that’s pretty much it. If the same issue will persist in stable 3.8 release, I’ll get on it.
For now created an issue for maintainy bois: https://github.com/MonoGame/MonoGame/issues/6918
By the way, you can always go ahead and fix it yourself, I can even explain, how to do it. ; - )
@gn.fur
Alright, I got some success with MonoGame 3.7.1!
Please check out the comments below about additional feedback and questions you had asked me earlier.
Sorry I wasn’t clear on this in my prior post but I actually did try this. It didn’t fix the issue when I was using a dev build.
I do projects off my Desktop as a starting point pretty regularly, so I didn’t think this is the problem. After installing MonoGame 3.7.1 SDK on my machine, I was able to build it with the project on my desktop. So the path wasn’t the issue (more on those results below). But hey, success with the build!
I have other projects with .mgcb files that opened just fine. I actually compared and contrasted .mgcb files that did work to look at differences to hone in on.
I tried uninstalling everything and then using your installer to install Monofoxe, MonoGame, Visual Studio 2019 Templates, and selected ‘Remove old versions.’
It doesn’t appear the MonoGame part of the install worked. I was expecting to see the same result as a MonoGame 3.7.1 install, but it doesn’t look like anything we added. What does checking this option do?
I noticed that when uninstalling Monofoxe, NoPipeline remained installed (the folder with all the files remained). I had to know to find it and run its uninstall.exe manually to clean it up.
In regards to building MonoGame without installing it and just using NuGet - I’ve been able to make that work.
I have MonoGame projects, building through a DevOps cloud, with cloud build agents that don’t have MonoGame SDK installed on them working. This was done by swapping out all referenced with Nuget references to MonoGame.
This also build locally even after I uninstall MonoGame SDK completely.
Here is a UWP csproj for this (NuGet Packages). Notice I even pull in MonoGame.Extended references here.
<ItemGroup>
<PackageReference Include="Microsoft.NETCore.UniversalWindowsPlatform">
<Version>6.2.9</Version>
</PackageReference>
<PackageReference Include="MonoGame.Content.Builder">
<Version>3.7.0.9</Version>
</PackageReference>
<PackageReference Include="MonoGame.Framework.WindowsUniversal">
<Version>3.7.1.189</Version>
</PackageReference>
<PackageReference Include="MonoGame.Extended">
<Version>1.0.617</Version>
</PackageReference>
<PackageReference Include="MonoGame.Extended.Content.Pipeline">
<Version>1.0.617</Version>
</PackageReference>
<PackageReference Include="MonoGame.Extended.Tiled">
<Version>1.0.617</Version>
</PackageReference>
<PackageReference Include="Newtonsoft.Json">
<Version>12.0.2</Version>
</PackageReference>
</ItemGroup>
The only other thing I needed to do was remove the .target references in the csproj and it builds just fine.
Might be something worth considering for your templates.
So all that said, installing 3.7.1 locally with the SDK, then using your installer, then using the template and building it worked. Onward! 
Yep, this is already fixed in dev releases. In 1.0.1.1 Nopipeline was a separate thing with a separate installer. Now it’s embedded into Monofoxe installtion.
It just runs default Monogame installer. If you were expecting to see Monogame templates installed in VS2019 – MG doesn’t support it yet. I mean, I could repack the MG installer with fixes for that, but I don’t see much reason for it.
Except then resource building will not work. : - )
@gn.fur
Ok, with the very latest dev build I can confirm NoPipeline cleans up after itself, and the MonoGame installer does kick off and install properly and allows for seperate uninstallation. All good there.
Except then resource building will not work. : - )
Are you sure? Check out this NuGet package:
You’ll notice it contains a MonoGame.Content.Builder.targets
It also contains MGCB.exe under the build\MGCB\build along with all the files that typically get installed with the local installer.
I have cloud builds going on, right now, that use this. I don’t check in any xnb files to my source control because I don’t need to - the cloud build kicks off MGCB.exe and builds everything.
@craftworkgames provided a good tutorial that, with dotnet new, you can generate a template, build, and run it. You can absolutely take this initial template, add a .png and reference it in the .mgcb file and it will absolutely build it and it will be loadable in the program. I just did this again, without MonoGame installed locally, to verify the whole thing.
The only issue you have is that you don’t have the nice MonoGame Pipeline UI Tool installed, but my point is you don’t need to run the local installer to build the assets and use them.
Here is the tutorial link: http://www.monogameextended.net/posts/getting-started-with-monogame-extended
I’m looking forward to digging into the Monofoxe solutions and appreciate the back and forth on all of this. Forces me to look much deeper into MSBuild and the flow around these tools!
Hmm, maybe it would even work…
…but I don’t really want to completely rewrite all of my installation system. : - )
Not now, at least.
Sounds like an upside. Pipeline Tool UI is complete garbage and should not exist – I even wrote Nopipeline just to not use it.
At one point we didn’t have a pipeline tool at all, so to say i like it well enough. I just think the whole content processor importer reader writer is confusing even having written a couple for practice i still feel very murky when i think about it.
The one thing i think i am really missing is a way to just reference a folder or folders that has all my content with sub folders with the xnbs that are all only pulled into a project in place at publishing time when you flip a switch, Such that all projects can be set to reference the same place and sub folders for all tests and content then separated at will into a project only when the user deems that it is time.
To say it another way if i link to a content item, i do not know of a way to later copy that linked item without removing and re-adding it. This is tedious and i tend to not link.
This has caused me to have a lot of duplicate items across many many projects as i feel other options also have drawbacks.
Wowie, new in-dev build is out! :0
Monofoxe v2.0.0.0-dev+007
Monofoxe 2.0 is here! :000