This post started out as a question, then I resolved the build issue I was experiencing in a hacky way. I wanted to share my findings for those that may have the same problem and see if anyone has a better resolution. Also, most of the posts I found related to this issue were created when Maui was still in beta. Lastly,
this issue affected the Android build only! The iOS build worked the first time.
Following this Microsoft Maui tutorial, I experienced a build issue right out the gate. The error was APT2260: resource mipmap/appicon and mipmap/appicon_round not found.
In the resources folder there was no appicon_round.svg file, so I copied appicon.svg to appicon_round.svg and tried a rebuild and got the same error.
I deleted android:roundIcon="#mipmap/appicon_round" from AndroidManifest.xml, and deleted the appicon_round.svg file I created via a copy action, but the build still failed.
Even though appicon.svg did exist, I removed android:icon="#mipmap/appicon" from AndroidManifest.xml, and the rebuild was successful. 🤦🏻♂️
Finally, I used Inkscape to create appicon_round.svg, I added it to the projects Resources/AppIcon folder, and then added android:icon="#mipmap/appicon" android:roundIcon="#mipmap/appicon_round" back to the AndroidManifest.xml file. The following build was successful.
First thing to note is that, while Visual Studio 2022 for MacOS did create the appicon.svg file, it did not generate the appicon_round.svg when I created the Multi-Platform project.
The second "gotcha" for me was when I removed the round SVG reference from the Android manifest file, but the build still failed.
A summary of how I resolved this issue is in my answer below. ⬇️
To summarize how to resolved the issue, if you generate a multi-platform project in Visual Studio 2022 for MacOS and any AppIcon SVG files are missing ...
Remove both/all AppIcon references from the AndroidManifest.xml
Build the app.
Generate the missing AppIcon SVG file(s) and put them in the correct folder.
Add both/all AppIcon references back to the AndroidManifest.xml
Build the app.
Related
I'm receiving the message below when I attempt to start the Local Windows Debugger on this project in Visual Studio 2022 . I had some earlier challenges adding and linking the additional include libraries and files for MySql as well as some earlier notifications about missing .dll files. I thought these were resolved since I was able to successfully build. What do I need to check to start trying to fix this? Let me know if any additional information is needed.
I was able to resolve the issue by re-writing the project from scratch on my laptop, starting with an empty C++ project. In the course of doing that, I did run into some of the same messages regarding missing .dll files. This was resolved by copying and pasting these into the appropriate /debug folder for the project directory. As suggested, I did implement the scan for corrupt files, which fortunately did not turn up any issues. Once this was completed, I achieved a successful build and execution of the program.
In the last months I created a project with the Qt-Creator version 4.7.0, Qt version 5.11.1 (open source version).
Now I tried to deploy it following the Qt doc and building the project with MSVC2017-64bit compiler as well as running windeployqt.exe afterwards on the generated executable.
As I tried to run the executable after the programm finished copying the neccessary dlls into the folder, a warning appeared:
The entry point ?
eventFilter#QAbstractItemView##MEAA_NPEAVQObject##PEAVQEvent###Z wasn't found in DLL "my/project/path/releasefolder/project.exe".
It seems to me like something was wrong with the Qt-Objects I use in my project, but I couldn't find anything, as it still worked flawlessly in the Qt-Creator.
A thought it might be due to the compiler having issues, so I changed it to mingw32, which I also tried to deploy the same way. But somehow in this case the warning disappeared, but many dlls were still missing even though windeployqt.exe should've already done that. And I also couldn't find them anywhere on my hard drive. I also tried a third compiler, but the issues weren't going away.
I searched online and only found people having problems with an entry point missing in a Qt dll or missing the Qt-Dlls in general, but haven't found anything related to my case.
I also tried Dependency Walker on every executable, but it found even more missing dll, which led me to believe the executables were somehow currupted so I tried it again and again, but with no success unfortunately.
Has someone any idea, why that could happen, or any suggestion for me?
Maybe I should change something in my project, even though it works fine in the IDE. I just need a way to deploy my Qt project in any way.
EDIT: Build using the Desktop Kit in Qt Creator with MSVC2017 the described warning appeared.
Build with Mingw32 (Desktop Kit) and with MSVC2017 using the UWP Kit in Qt Creator the following Dll was missing, that I haven't found anywhere on my hard drive: MSVCP140_APP.dll
EDIT2: I ended up downloading the required dll, to somehow get it to work, but it still didn't work. One build, that required that dll now started but immediately closes itself again and the other build was suddenly warning me of a missing procedure entry point.
EDIT [SOLUTION]: I let the Qt Creator create a whole new fresh project and copied all files from my old project in the new one. After that I only copied all the dll files into the folder and it worked.
Instead of relying on windeploy, manually add the dll. I am assuming you have built the project using mingw. Assuming you are using Qt 5.11.1, go to
C:\Qt\Qt5.11.1\5.11.1\\bin\ and copy all the dll files and paste in your executable folder. Also copy all directories from plugins folder (in /plugins) and paste in your folder. Now run the application, don't close the application. Now delete all the files from your executable folder. The one's not being used are deleted and the rest are left. I assume you are doing this on target computer. This might help.
I have a solution with multiple C# projects included, and a single C++ project.
The C++ project is a .NET Framework bootstrapper that should produce a native executable file. I first built the project as a single project solution, however i'm now trying to migrate it into a master solution.
In order to migrate it, I added a new project called Setup to my existing solution called Master. I then added each header, source and resource by adding new files and copy-pasting the content.
I also changed the output directory to $(Configuration)\ so that it doesn't put the Debug and Release folders in the root folder of the solution.
Now, when I attempt to build the project, it says Rebuild All Succeeded, however when i try to debug it i get the following error
Unable to start the program ~ The system cannot find the file specified
Image of error shown when attempting to debug (F5)
If i navigate to the output directories, they are empty.
This is my first attempt at a C++ project, have i made a schoolboy error?
Does anyone know how I can get this working?
I found the answer. It was indeed a schoolboy error.
I was targeting AnyCPU, whereas i should have been targeting x86.
Now that i'm targeting the correct architecture, the project builds as expected.
I know about this question (and answers), but despite trying all the suggested options I am still stuck.
I have a solution with multiple projects, but for this particular case let's say I've got my ExampleProjectA and a corresponding unit test project ExampleProjectATest. The first one is added as a reference to the test project - not via Visual Studio's "Project References" but as a link to the DLL (something like "..\Path\$(Config)\ExampleProjectA.dll") - this is due to build server requirements in our company, but the problem also existed when we still had "Project References".
Building and then running a single unit test works fine
Changing just a single letter in a unit test and then letting the test run always results in a rebuild of ExampleProjectA, even though this shouldn't be necessary
Setting all (there were only a few) files in ExampleProjectA from "Copy always" to "Copy if newer" in their respective properties didn't help
Checking the checkbox under Tools => Options => Projects and Solutions => Build an Run (see below) also didn't change anything
To see if there was any more information available, I changed the build output settings to diagnostic. Each time a rebuild of ExampleProjectA is triggered, the first line in the output windows is
1>Project 'ExampleProjectATest' is not up to date. Input file 'c:\tfs\mysolution-dev\exampleprojectatest\myfolder\namegeneratortest.cs' is modified after output file 'C:\tfs\mysolution-dev\exampleprojectatest\bin\Release\exampleprojectatest.pdb'.
The class name written to the window (e.g. namegeneratortest.cs) changes according to which test file I change.
Not sure why this message comes up, but the next step was to disable the debugging information as shown below under Project properties => Build => Advanced => Output => Debug Info => None:
Still the same, nothing's changed.
Another thing I tried was to check the timestamps of the files contained in my solution folder (as there was a case where a user had a file with a future timestamp - see linked post) - to no avail.
Last thing I tried was to change the build settings in the Configuration Manager to a different target platform - some settings wouldn't let me build the solution successfully, some other settings did, but the problem described persisted, so no change.
The behaviour is similar (not the same though) with both the Visual Studio Test Runner and the one provided by ReSharper.
Visual Studio Test Runner
Project 'ExampleProject' is not up to date. Input file 'C:\tfs\mysolution-dev\exampleprojecta\Views\Shared\someview.cshtml' is modified after output file 'C:\tfs\mysolution-dev\exampleprojecta\bin\exampleprojecta.pdb'.
ReSharper Test Runner
Project 'ExampleProjectATest' is not up to date. Input file 'c:\tfs\mysolution-dev\exampleprojectatest\myfolder\namegeneratortest.cs' is modified after output file 'C:\tfs\mysolution-dev\exampleprojectatest\bin\Release\exampleprojectatest.pdb'.
I'm using Visual Studio 2013 Premium Edition with ReSharper 8.2 and the latest updates, the projects in our solution file are in C#.
Update
To clarify - the first line in the output window does show that the test project has to be rebuilt - this is fine. The following lines, however, indicate that also ExampleProjectA has to be rebuilt, which shouldn't be necessary. Subsequent messages to the output window also show that other projects (referenced from ExampleProjectA have to be rebuilt.
Update 2
Despite installing Update 4, nothing has changed.
For my case the solution was to change the build action of a config file from "Copy always" to "Copy if newer". It took a while to find as I had to change the build output details to get the details about which file was causing the error, e.g.
Project 'xyz' is not up to date. Project item 'c:\my\path\web.config.dev' has 'Copy to Output Directory' attribute set to 'Copy always'.
From my experience it can also happen that different file names are shown when building multiple times, so make sure you have the right one and / or build again if the problem persists.
Also have a look at this question and its answers to find some more information.
I have worked around this problem by deleting the .pdb file in the \obj folder. It seems that visual studio is checking file modification time to decide if it should build or not the project (in your case ExampleProjectA) and the .cshtml is newer than the pdb. But when launching the build, project changes in .cshtml files are not triggering the .pdb rebuild, so the problem remains.
By deleting the .pdb in \obj folder (not in \bin as the file there is copied from \obj and would keep the old modification time) the modification time for the .pdb is newer than the .cshtml and the VS doesn't need to build the project before running the tests. Of course this only works until the next time you modify a .cshtml file, that's why I qualify it as just a workaround.
Check what version of Visual Studio 2013 you are using. Update 1 has a pretty big issue where it rebuilds everything. See: https://connect.microsoft.com/VisualStudio/feedback/details/811112/unnecessary-solution-rebuild-on-each-test-run
Upgrading to Update 3 did the trick!
I'm not sure if Resharper could affect things as well. I suggest temporarily uninstalling it.
I included vld.h, vld.lib and vld_x86.dll on my Win32 project with visual studio 2010. It builds properly but when I execute, it crashes with this message:
"The application was unable to start correctly (0xc0150002). Click OK to close the application."
I run it with Dependency Walker but it shows side by side error as follows:
Error: The Side-by-Side configuration information for "D:\project\..\debug\VLD_X86.DLL" contains errors. The application has failed to start because its side-by-side configuration is incorrect.)
I have tried various ways including tinkering around with the manifest as suggested here:
https://vld.codeplex.com/discussions/360243
It only runs properly if I commented the following line on vld.h
// Force a symbolic reference to the global VisualLeakDetector class object from
// the DLL. This ensures that the DLL is loaded and linked with the program,
// even if no code otherwise imports any of the DLL's exports.
//#pragma comment(linker, "/include:__imp_?g_vld##3VVisualLeakDetector##A")
However, if I commented out that line, the vld doesn't output anything at all (just like no vld integration)
Anyone having this problem before? Any suggestions will be appreciated, thanks in advance!
I had this problem too, you need to add all these files to the same directory as your vld_x86.dll/vl_x64.dll:
Microsoft.DTfW.DHL.manifest
dbghelp.dll
Which came from the Win32/Win64 bin folder from Visual Leak Detector. Found this from: https://vld.codeplex.com/wikipage?title=Building%20Visual%20Leak%20Detector%20from%20Source
I had this problem (this error message), too. In my case the vld_x86.dll, most likely in another than the expected version, was preinstalled and registered by some other software. (everybody likes VLD, it seems) Thus, it was loaded instead of the vld_x86.dll in the path VLD was built to. Unregistering the foreign DLL solved the problem.
Hence, you might want to check the output for loading of DLLs from exotic paths.
Other might still get into the issue;
A potential fix is to install VLD version 2.5.1, can be downloaded from github: https://github.com/KindDragon/vld/releases/tag/v2.5.1
It brings the fix explained above, it includes dbghelp.dll
I got such error when I tried to run a project just after installing vld. A solution for me was re-login. Because vld installer adds new paths to PATH and VS doesn't see them without re-login. Otherwise you can use a solution with copying files dbghelp.dll and .manifest.
If you are using Visual Studio
The simplest fix if you have not been messing with your project properties in the include, linker sections is to make sure that you did not manually add VLD. Instead clear the includes you made in here and save your project.
Close it then install the latest VLD and it will automatically create the includes parent inheritance for your Visual Studio projects including environment paths as well.