Any idea why I’m seeing this problem? I have a minimal test project that works, but a slightly more complex project is failing to build.
C:\Users\[redacted]\.nuget\packages\monogame.content.builder.task\3.8.0.1375-develop\build\MonoGame.Content.Builder.Task.targets(269,5): error MSB3075: The command "dotnet tool run mgcb /quiet /@:"[redacted]\Content\Content.mgcb" /platform:WindowsStoreApp /outputDir:"[redacted]/Content/bin/WindowsStoreApp/Content" /intermediateDir:"[redacted]/Content/obj/WindowsStoreApp/Content" /workingDir:"[redacted]/Content/"" exited with code 5. Please verify that you have sufficient rights to run this command.
I’m also getting errors like this:
error : Importer 'FbxImporter' had unexpected failure!
If I run mgcb-editor after installing it via dotnet, I can build the .mgcb file from UI editor.
When I run the failing mgcb command from above in a command line in the project directory, it fails on all of the models with this error:
error: Importer 'FbxImporter' had unexpected failure!
Assimp.AssimpException: Error loading unmanaged library from path: Assimp64.dll, see inner exception for details.
The specified module could not be found. (0x8007007E)
---> System.IO.FileNotFoundException: The specified module could not be found. (0x8007007E)
--- End of inner exception stack trace ---
at Assimp.Unmanaged.AssimpLibraryWindowsImplementation.NativeLoadLibrary(String path)
at Assimp.Unmanaged.AssimpLibraryImplementation.LoadAssimpLibrary(String path)
at Assimp.Unmanaged.AssimpLibrary.LoadLibrary()
at Assimp.Unmanaged.AssimpLibrary.LoadIfNotLoaded()
at Assimp.Unmanaged.AssimpLibrary.CreatePropertyStore()
at Assimp.AssimpContext.CreateConfigs()
at Assimp.AssimpContext.PrepareImport()
at Assimp.AssimpContext.ImportFile(String file, PostProcessSteps postProcessFlags)
at Microsoft.Xna.Framework.Content.Pipeline.OpenAssetImporter.Import(String filename, ContentImporterContext context) in C:\BuildAgents\MonoGameWin1\work\f7381a85a626990\MonoGame.Framework.Content.Pipeline\OpenAssetImporter.cs:line 291
at Microsoft.Xna.Framework.Content.Pipeline.FbxImporter.Import(String filename, ContentImporterContext context) in C:\BuildAgents\MonoGameWin1\work\f7381a85a626990\MonoGame.Framework.Content.Pipeline\FbxImporter.cs:line 24
at Microsoft.Xna.Framework.Content.Pipeline.ContentImporter`1.Microsoft.Xna.Framework.Content.Pipeline.IContentImporter.Import(String filename, ContentImporterContext context) in C:\BuildAgents\MonoGameWin1\work\f7381a85a626990\MonoGame.Framework.Content.Pipeline\ContentImporter.cs:line 45
at MonoGame.Framework.Content.Pipeline.Builder.PipelineManager.ProcessContent(PipelineBuildEvent pipelineEvent) in C:\BuildAgents\MonoGameWin1\work\f7381a85a626990\MonoGame.Framework.Content.Pipeline\Builder\PipelineManager.cs:line 669
The proper tool appears to be installed in the project:
dotnet tool list --local
Package Id Version Commands Manifest
--------------------------------------------------------------------------------------------------------------------------
dotnet-mgcb 3.8.0.1375-develop mgcb [redacted]\.config\dotnet-tools.json
Maybe start a new thread for this so we can dive into it more.
Does your minimal test project have models that would use the FbxImporter?
When you build in the Editor, are you still building as for WindowsStoreApp?
It seems like it’s loading Assimp64.dll from the wrong path, but in my nuget cache I see the DLL right there alongside the app.
I added a simple .fbx file to my minimal project and now it also fails in VS2019. I can build the .mgcb file with the dotnet MGCB Editor version 3.8.0.1375-develop.
In the editor, I can build for Windows, WindowsStoreApp and Android. Haven’t checked the others.
I wonder if it’s a bug with the working directory. When you build in VS, I think MGCB uses the project folder as the working directory. MGCB Editor probably uses the bin as the working directory when running MGCB. If Assimp only tries to load native dlls from the working directory instead of the assembly’s directory, that could cause this issue. I’ll have to check the code in a bit, but I I have an idea of how you can test this theory.
Ok, so find that targets file in your nuget cache and make a few temporary edits to test this out: C:\Users\[redacted]\.nuget\packages\monogame.content.builder.task\3.8.0.1375-develop\build\MonoGame.Content.Builder.Task.targets
Line 272 sets the working directory to be the project’s directory because that’s where dotnet expects to find your manifest. Try changing it to the mgcb bin. Something like: C:\Users\[redacted]\.nuget\packages\dotnet-mgcb\3.8.0.1375-develop\tools\netcoreapp3.1\any
The problem is that your working directory won’t be able to find the manifest anymore. The easiest solution would be to copy the .config folder from your project folder to the new working directory in your nuget cache. Alternatively you can also change the $(MGCBCommand) used on the previous line to call a globally installed mgcb.
Then try building via VS again and it might be able to load Assimp64.
Hey, that worked, at least partially. I updated the /workingDir parameter (hardcoded) and copied my .config file and now it builds.
But I’m not seeing the compiled xnb files for the models in my apps build output. The shader and sprite font compiled xnb files show up.
When I run my modified command line, I see a different exception.
Unhandled exception. System.IO.DirectoryNotFoundException: Could not find a part of the path 'C:\[redacted]\Content\obj\WindowsStoreApp\Content\.mgcontent'. at System.IO.FileStream.ValidateFileHandle(SafeFileHandle fileHandle) at System.IO.FileStream.CreateFileOpenHandle(FileMode mode, FileShare share, FileOptions options) at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options) at System.IO.StreamWriter.ValidateArgsAndOpenPath(String path, Boolean append, Encoding encoding, Int32 bufferSize) at System.IO.StreamWriter..ctor(String path, Boolean append, Encoding encoding) at MonoGame.Content.Builder.SourceFileCollection.Write(String filePath) in C:\BuildAgents\MonoGameWin1\work\f7381a85a626990\Tools\MonoGame.Content.Builder\SourceFileCollection.cs:line 53 at MonoGame.Content.Builder.BuildContent.Build(Int32& successCount, Int32& errorCount) in C:\BuildAgents\MonoGameWin1\work\f7381a85a626990\Tools\MonoGame.Content.Builder\BuildContent.cs:line 429 at MonoGame.Content.Builder.Program.Main(String[] args) in C:\BuildAgents\MonoGameWin1\work\f7381a85a626990\Tools\MonoGame.Content.Builder\Program.cs:line 59
On a side note, all of the obj and bin files are being dumped into the same folder(s) as the source files now.
Those are some interesting new issues. I wonder if they’re related to messing with the working directory. Another thing you can try is reverting the change to the targets file, and copying Assimp64.dll from your nuget cache into your project directory so that it can be found with the default working directory.
Then hopefully the original Assimp issue will still be gone, and we’ll see if these new issues are fixed from going back to the old working directory.
That worked. I copied the Assimp64.dll to the expected working directory and reverted my other changes.
All seems well after that for UWP. Hope this can be fixed properly on the tool side.
Now, Android is having some issues. The tool compiles all the assets, but dumps output into both the obj/bin folders and the source folders. And not all appears to work on the device, such as the font not loading. I’ll try and gather some more details.
Hi! I think I have a similar problem but in Linux. When trying to import an fbx, I get the following error:
Assimp.AssimpException: Error loading unmanaged library from path: Assimp64.so, error detail:
Assimp64.so: cannot open shared object file: No such file or directory
at Assimp.Unmanaged.AssimpLibraryLinuxImplementation.NativeLoadLibrary(String path)
at Assimp.Unmanaged.AssimpLibraryImplementation.LoadAssimpLibrary(String path)
at Assimp.Unmanaged.AssimpLibrary.LoadLibrary()
at Assimp.Unmanaged.AssimpLibrary.LoadIfNotLoaded()
at Assimp.Unmanaged.AssimpLibrary.CreatePropertyStore()
at Assimp.AssimpContext.CreateConfigs()
at Assimp.AssimpContext.PrepareImport()
at Assimp.AssimpContext.ImportFile(String file, PostProcessSteps postProcessFlags)
at Microsoft.Xna.Framework.Content.Pipeline.OpenAssetImporter.Import(String filename, ContentImporterContext context) in C:\BuildAgents\MonoGameWin1\work\f7381a85a626990\MonoGame.Framework.Content.Pipeline\OpenAssetImporter.cs:line 291
at Microsoft.Xna.Framework.Content.Pipeline.FbxImporter.Import(String filename, ContentImporterContext context) in C:\BuildAgents\MonoGameWin1\work\f7381a85a626990\MonoGame.Framework.Content.Pipeline\FbxImporter.cs:line 24
at Microsoft.Xna.Framework.Content.Pipeline.ContentImporter`1.Microsoft.Xna.Framework.Content.Pipeline.IContentImporter.Import(String filename, ContentImporterContext context) in C:\BuildAgents\MonoGameWin1\work\f7381a85a626990\MonoGame.Framework.Content.Pipeline\ContentImporter.cs:line 45
at MonoGame.Framework.Content.Pipeline.Builder.PipelineManager.ProcessContent(PipelineBuildEvent pipelineEvent) in C:\BuildAgents\MonoGameWin1\work\f7381a85a626990\MonoGame.Framework.Content.Pipeline\Builder\PipelineManager.cs:line 669
I tried to copy the library to the content target but it did not work as it did in windows .
Any ideas? Also I checked to have libstdc ++ 6 installed, and it was.
Is there a workaround for Linux yet? I’ll admit that I’ve never fully wrapped my head around Nuget packages… I try to stick with logic coding… anything related to importing code over the internet via an xml document is all foreign concepts to me still. I get the exact same errors as posted by Rejurime and also Keith’s initial post.
.