I'm trying to build an existing CMake project with VS 2019 Professional, and when I open the folder through VS, after a few seconds it says in the Output window that the CMake generation finished. However, when I switch to CMake Targets view in the Solution Explorer, it says that the CMakeLists.txt is still parsing..., and in the Project menu Generate Cache is greyed out but Cancel CMake Cache Generation can be selected (which doesn't seem to do anything" and also Delete Cache is greyed out. This makes me think that either VS doesn't think the CMake generation is done, or it's actually stuck somewhere.
Because of that I can't Build (no option under Build) and I can't Select a Startup Item/Target. I've searched and seen this issue a couple of times but there wasn't any answers/solutions.
Thanks!
Well, seems like updating my VS2019 solved that issue.
Related
I'm using Windows 10 Pro, Visual Studio 2022 and cmake version 3.26.0-rc3. In my Visual Studio solution I have a static library project, let's call it MyLib, which uses features from libxml2 i.e. it needs to link against libxml2.lib. Also in my solution there is an executable project, let's call it MyExe, which links against MyLib and also has libxml2.lib listed as a dependency in its project settings.
The problem is that in the CMakeLists.txt file of MyLib, target_link_directories and target_link_libraries do not seem to have any impact on the MyLib project settings, particularly Additional Library Directories and Additional Dependencies, respectively. For MyExe, those commands work as expected. If I fix the linker options for MyLib project settings manually in Visual Studio IDE, everything builds fine, but I don't think I should need to manually alter project settings initially created by CMake. So is there something I'm missing here - like that dependencies for a static library project need to be set in a different way in CMake - or is this a bug in CMake or Visual Studio? Are there any alternative ways to achieve the desired behavior and get the build to work?
In trying to find solutions for this I came across this very old post, but if I understood correctly it suggested adding an extra library project which sounds like a huge overkill for a simple thing like this which could be worked around by setting the project settings manually in Visual Studio IDE, so it's not an acceptable solution for me.
I faced the problem: whenever I open my working solution Visual Studio automatically starts build. I cannot find configurations to turn off this.
It looks like that problem is in solution, because I opened another solution and build did not start automatically.
This strange behavior is not expected one for VS2019. Please try:
1.Tools=>Import and Export Settings=>Reset all settings=>No, just reset settings to reset current VS settings to default.
2.Use vs installer to repair your VS if there's something broken with IDE.
3.Extensions=>Manage Extensions=>Installed=>Tools you can disable(don't need to uninstall) some third-party extensions and restart VS to check if this issue persists. To check if this issue is about VS itself or extensions.
4.Exit VS and delete the .vs, bin, obj folders of the projects in the solution, and then clear the cache, for VS2019, the corresponding folder is 16.0 instead of 14.0. After that, restart VS.
For me, this was a Resharper setting. When I turned this off it stopped happening. I think there is also a setting for Visual Studio to do this as well, but it is off by default.
I installed recently the Xamarin platform and i created a default Xamarin.Forms Shared project using VS2015 and under the Droid project References i get a yellowish icon on System.ObjectModel library as you can see...
The weird thing is that in the beginning everything compiles but when i add a Cross-Platform -> Forms Xaml Page the compiler throws error on the InitializeComponent() method call.
I tried to manually reference System.ObjectModel.dll from the path C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\MonoAndroid\v1.0\Facades without any luck. When i right-click on the properties i get this
but in the file system properties everything seems to be correct.
All the above are with the default options.
Does this happen to you or it's just me? (i tested it in two computers)
If you have any questions i will update the post after this message...
Welcome to Xamarin! It's like tap dancing your way through a field of land mines. But XAML is awesome. Here is what worked for me: update your nuget of xamarin forms, do clean build, see the error/warning, restart visual studio, do a clean, restart visual studio again, do a build, spin your chair around 3 times counter-clockwise, and voila, the error is gone. It's like magic! No need to manually much around with dlls, it will just work.
Try to delete the contain of bin folder in PCL project and android project. and clean the solution try it again.
reference: http://xamarin103.rssing.com/browser.php?indx=50717177&item=8379
user: PubuduGayan, The second option that He suggested.
I hade same problem. Adding reference from C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5.2\Facades... didn't work me.
What worked for me was to change (Tools/Options/Project and Solutions->Build and Run) Verbosity from normal to minimal, even if system.objectmodel reference-warning is still there.
Maybe this will work for developers too who are facing same problem
I faced the same problem. Deleting the reference helped in resolving the warning since System.ObjectModel was not used at all.
When running a project in Test or Debug configuration in VB.NET using Visual Studio 2012, sometimes it gives the following error as the reason for "Build Failed"
Error 1 Could not copy the file "obj\Debug\MyProgram.exe" because it was not found. MyProgram
There are no issues with the code as it was just compiled seconds before this (sometimes I start the program again just to see how everything gets laid out visually and then go back to the code to make Location adjustments)
What I found is this. If I wait , when I go to test compile again -- it just magically starts working again -- Only to fail again later.
Sometimes, I can get 10-15 good compiles before it wigs out.
About my system configuration:
I do not have any other version of Visual Studio or standalone .NET language installed
The paths are set correctly (else it would never compile in the first place.. not just occassionaly fail)
The program can be a simple program with absolutely no code added (aka... New > WinForms Project > Compile)
The project, language (and all requirements), and project output path are on a local drive that is connected directly to the PC internally (using C:\code* for projects and the standard install location for Visual Studio 2012)
I checked the smart data and scanned my hard drive for any errors ... none ever encountered. The temperature of my system (CPU), and the drive is around 25-30 degrees C.
I am really baffled as to why this happens and at random. I have also tried completely clearing out the bin/ folder, and even Moving the project or repointing where the compiled output path is.
Deleting the .suo file helps sometimes, but not all the time.
I believe this is something that may be able to be tweaked in the UI somehow, however I do not know anything about manually linking and compiling programs.
Lastly -- it does not matter whether I run VS in "Administrator" mode (elevated privileges) or as a user.
Some methods that may help you
Have you tried to reinstall Visual Studio. If that does not work you may need to install some of Windows Updates, the compiler may be missing some essential libraries/references to compile your application.
Check your .Net Target Framework, setting your application to a new framework that you don't have installed can stop the application from compiling yet even stop it from being debugged, having a compiler that is to low, this may come with errors for the compiler but not for the IDE/Visual Studio to notice.
Try cleaning your project solution's output folder by right clicking your solution then try to rebuild your project/solution.
Check your compilation references in your project's properties, check if a reference added is not on your computer
Reinstall/Update .Net Framework, same here some requirements may be missing from your installation
Try installing a newer version of Visual Studio, try Vs2013 - this contains various improvements and fixes, Visual Studio 2015 is fast approaching, a recommendation install VS2015 when the full version gets released it will contain a lot of useful features for future .net programming.
Create an new Administrator account and Run VS with Administrator rights and try compiling then, this fixes some of problems in vs and other microsoft products, it might work here.
Install all of the .Net Frameworks from the lowest to current 4.5, this may help when some of the used references/libraries are not on your local hard drive.
if none of these methods work, i would not know of the problem one last thing you could try is installing Windows to another hard drive and try using that installation of windows and see what happens... Hope this helps.
Best regards!
I faced this kind of problem because of my virus guard
blocked my application(but it is not have any harmful code :) )
exclude your project folder from virus guard
or
simply disable it(not recommended)
A similar question was asked and answered about a year ago, but was either a different issue (everything was in beta) or misdiagnosed. It's located here: MSbuild task fails because "Any CPU" solution is built out of order.
My issue is that I have a wix installer project, and after upgrading to Tfs2010 on monday, the build fails on linking because it can't find the build product of the Wpf application in the project. After some digging, it's because it hasn't been built yet. Building in Vs2010 works as normal. The wix project is set to depend on the Wpf project, and when viewing Project Build Order in the IDE, everything looks as normal.
The problem was originally encountered with only two platform definitions in the solution; x86 and x64. There are also two flavors, Debug and Release, and TFSBuild.proj is set to build all four combinations. There was no occurence of AnyCPU anywhere. Per the referenced question above, I tried changing the Wpf project to use AnyCPU so that it would be built first. At this point, the wix project used the exact configuration and the Wpf project used the flavor with AnyCPU. However, doing so didn't seem to change anything.
I'm using the Tfs2010 RTM, Vs2010 RTM, and the most recent version of Wix, which at the time of this writing is 3.5.1602.0, from 2010-04-02. Anyone else running into this?
2010-04-27: After a fair amount of digging, and reproducing on a cloned VM build machine, I believe I know what's going on and also what's failing, but I don't quite know how to fix it.
The situation is that this bug seems to exhibit symptoms based on pure luck-of-the-draw project ordering in the solution file. It appears as if the solution file will just blindly build the projects in the order they appear, relying on its ability to detect unbuilt references and build them on demand when needed.
In my particular solution file, my Wix project was ordered before my Wpf application project. This resulted in the Wix project being built first, and while the dependency on the Wpf project was detected correctly, the actual MSBuild task was skipped because of the undefined $(BuildProjectReferences) variable I mention a couple of comments down from the main post in this thread. With MSBuild verbosity still on diagnostic, BuildProjectReferences can be seen as undefined building the Wix project, and it can be seen defined as true upon building the Wpf project within the task to build the Wix project. Yet, when tested, it evaluates undefined again, the task is skipped, and the Wix build fails because it can't find the build output of the unbuilt Wpf project.
So bottom line: project dependency is skipped because of bad $(BuildProjectReferences) variable. Interestingly, this variable is present only in the Wix2010.targets file, and not in wix.targets; I guess that's why this is just showing up after I installed Tfs2010 and Vs2010.
The solution: How do I make sure that BuildProjectReferences is passed along correctly to the subsequent MSBuild tasks? Is there something special with variable scoping going on?
2010-09-14: A bug was opened for this issue in the WiX toolset: http://sourceforge.net/tracker/?func=detail&atid=642714&aid=2990231&group_id=105970 and fixed a while ago. Hopefully, this is no longer an issue. If so, please do open a new bug.
To address your comment directly, nothing in my solution has an AnyCPU configuration in their build files. I created the AnyCPU configurations only to test the solution suggested by the thread I linked to in my original post. After it didn't work, I removed the AnyCPU configurations again.
Furthermore, the projects are in the same solution file, however in separate solution folders (interface folder, installer folder) if that matters.
Interestingly enough, I was going to make a small sandbox example so that I could illustrate the problem I was having, however after creating my tiny sample solution, I couldn't get the error to reproduce. This makes me think that perhaps this is a result of using a team project that was upgraded from a Tfs2008 team project rather than one that was created fresh in Tfs2010. I may try branching my project into a new one to test this theory if I can't figure out why the test solution works.
p.s. also, I'm new to stackoverflow--why on earth are comments limited in length if the "answer your own question" workflow is intended only to provide concrete answers?
So I threw the build verbosity up to diagnostic and read through it today, and one line in particular stood out to me:
Task "MSBuild" skipped, due to false condition; ('#(_ProjectReferenceWithConfiguration)'!='' and '$(BuildingInsideVisualStudio)' != 'true' and '$(BuildProjectReferences)' == 'true' and '#(_MSBuildProjectReferenceExistent)' != '') was evaluated as ('..\WpfApp\WpfApp.csproj'!='' and '' != 'true' and '' == 'true' and '..\WpfApp\WpfApp.csproj' != '').
This was seen as my installer project was attempting to build my wpf project since the wpf project is referenced. In particular, for some reason $(BuildProjectReferences) is evaluating to '' when I'm fairly sure it should be 'true'.
However earlier in the log, at the beginning of the MSBuild task for the WpfApp project, I saw this:
Task "MSBuild" (TaskId:15)
...
Initial Properties:
...
BuildProjectReferences = true
So the property was indeed correct up until the beginning of the task, but then was apparently overwritten? I'm sort of unclear as to how these properties get set.
Its a bug, a bug, a bug. I don't know, who is responsible, but here's a working dirty filthy hack:
Open your .sln file in notepad.
Find your wix projects in the list of projects.
Cut them out, and paste them back after all other projects are listed.
Cry in the shower as you try to scrub the dirty off, only to emerge hours later, rubbed raw and still with the stench of filth clinging to you like corpse's skin.
Following Rob Mensching's edit of my original post, it seems that this has indeed been fixed in WiX 3.6.0917.0 at the latest.
I was seeing this problem (wix 3.7 not finding the dependent project output) in my local and TFS builds (for both VS2010 and VS2012).
I finally got around it by setting the msbuild property /m:1 to only use a single build process. I set /m to allow msbuild to figure out how many processes it could use to simultaneously build with.
I faced with a same problem today and find a solution like this:
Open your solution file on notepad the find your setup project and change postProject setting. This will tell msbuild this project should wait another project to build. I don't know why but it is not added by default.
Project("{GUID}") = "MyInstaller", "MyInstallerPath", "{Installer Project GUID}"
ProjectSection(ProjectDependencies) = postProject
{Prebuild Project GUID} = {Prebuild Project GUID}
EndProjectSection
EndProject
'Prebuild Project GUID' is the number on the right of the project that you want to install.
TFS uses a set of properties to control the names of the solutions and configurations to build ( iterate through ). For each combination of solution and configuration it then uses the project dependencies / build order to control the order of the projects getting built. It's possible that your EXE/DLL's are AnyCPU and that your WiX is x86 and that although the WiX has a dependency on the EXE/DLL the x86 is built before your AnyCPU. Or maybe they are even in different solutions so it's kind of hard to tell without looking at your source but that's basically how it works.
What we did is to first report the bug to wix and then we found your question.
We solved the problem on our side by saying that, by default, the wix project will build the references. We updated the file C:\Program Files\MSBuild\Microsoft\WiX\v3.5\wix2010.targets by setting <BuildProjectReferences>True</BuildProjectReferences> in the project which set the path. So, yes, we have done this manually ; we have reported the bug as well as our fix.