I have some projects I am converting from VS2008 to 2010.
But when converting them, I noticed that when doing batch builds of them, they fail to compile. The errors are
"unresolved external symbol: __SomeFunction".
__SomeFunction is from project A that compile perfectly, and the errors are happening in project B, that depends on project A.
The Build order and project dependencies are correctly set.
They compile well if I do one-by-one the configs and platforms, but this is very annoying when I have people saying to me that it is required they batch build correctly.
Side Note: I have configurations for the platforms Win32 and x64.
Help me please,
Sérgio
Sadly this is apparently a known bug in VS2010. I just got bit myself.
See: http://connect.microsoft.com/VisualStudio/feedback/details/556158/batch-build-links-to-wrong-referenced-projects
and
https://connect.microsoft.com/VisualStudio/feedback/details/554339/visual-studio-2010-bug-in-platformname-handling-in-batch-build
Related
I Have recently upgraded my old Visual Studio 2008 project to 2012.
I now have an error "Error 1 The project 'Add-in Projects' is unsupported 0 0".
The Add-ins Projects isn't a project it is just a folder in the solution that contains projects. All of the projects compile fine without any issues.
All of the solutions for unsupported projects don't seem to apply as it is simply a folder.
It doesn't actually effect any of the projects they all compile fine and seem to work fine, its just slightly annoying.
Has anyone encountered this before and could suggest how i might fix this error?
Cheers
I'm working on a project that has a fairly standard Visual Studio 2013 build chain. One of the projects within the solution is used solely for compiling .hlsl files into .cso files, which are then loaded at runtime. When building from within the Visual Studio IDE, incremental builds behave as expected; if I edit color_ps.hlsl only that shader is compiled into its corresponding .cso file.
In the interest of expediting developer workflow, we have a system which automatically recompiles and then reloads shaders at runtime. Essentially, if the application is running and a user edits color_ps.hlsl, I launch MSBuild from the application to rebuild the project containing our shaders, and then reload its corresponding .cso file. Incremental builds here work as expected.
This all works fantastically, the only problem being that it seems that there seem to be some incompatibilities across the IDE and MSBuild. The first time compiling with MSBuild at runtime, all .hlsl files within the project are rebuilt. Further re-builds use incremental building as expected.
Furthermore, after exiting the application, attempting to build the shader project from within the Visual Studio IDE also triggers a full rebuild. Following re-builds use incremental building as expected.
My suspicion as to why this occurs is that the IDE and MSBuild do not recognize that their outputs are already up-to-date. To clarify, the output assemblies produced by compiling from the IDE and MSBuild are identical, and as such should be recognized as being up-to-date regardless of from where the build is being invoked.
Would anyone know a way to prevent these needless full-rebuilds when switching between building from the IDE versus invoking MSBuild at runtime? Thanks!
I have a Visual Studio .Net Solution which has many projects/libraries.
When I work locally on my own PC there is no problem as I tend to recompile those libraries that I have just changed and everything is in sync.
The problem is sometimes other developers who once in a while require to work on or look at my code have an enormous problem recompiling everything.
In the configuration Manager, I do not have all projects checked else it would take too long to build everything whislt working.
Problem is when the solution is compiled on another application, some of the errors reported say a particular library has error and its taking too long to figure out all the dependencies compiling each one individually.
Even when checking everything in the config manager it still does not seem to compile correctly.
I thought when you add a reference to a library the dependencies are taken care of.
Is there a simple way to make sure the solution determines what are the correct dependencies and make sure everything is built in the correct order?
Thank you
After other developers got new source codes from you, they should close Visual Studio and reopen the solution.
Sometimes there are also troubles with dependencies in Visual Studio. First, try these menu commands:
Build > Clean Solution
Build > Rebuild Solution
This will show you which dependencies are cyclic or not correct.
Also, in Visual Studio project must not depend on another one which creates executable (at least for our pure C++ -written project this is true). I.e. "Utils" project which compiles into "Utils.dll" cannot depend on "MyApp" project, which exports some functions or symbols and compiles into both MyApp.exe and MyApp.lib (or some other kind of assembly). If you have such a dependency, you must correctly setup project build order and manually set MyApp.lib as in linker inputs.
You can package and distribute your assemblies using http://nuget.codeplex.com/. It's made to solve this problem.
Visual Studio sometimes decides to rebuild my entire huge project because of one small change. I turned build logging up to Diagnostic to see what was the problem, and here's what I'm seeing:
< Bunch of spam >
Outputs for C:\<snip>\PRECOMPILEDHEADERS.CPP:
C:\<snip>\PRECOMPILEDHEADERS.OBJ
All outputs are up-to-date.
Forcing rebuild of all source files due to a change in the command line
... and then it rebuilds my precompiled headers, then everything else.
This happens when I change a single .cpp or .h file inside the project. I'm not changing anything in the project settings. It also doesn't happen all the time for the same change; it's random.
Any ideas on what's going on here? Where can I get more information? I tried enabling debugging via the description in http://blogs.msdn.com/b/vsproject/archive/2009/07/21/enable-c-project-system-logging.aspx but it didn't give any more information. I can't figure out where this "Forcing rebuild of all source files due to a change in the command line" is coming from. It's not in any of the factory MSBuild files.
Some other info: it's a C++/CLI dll project that links a lot of other projects, including C#, native c++, and other C++/CLI dll's. I tried removing all the C# projects from the dependencies since those tend to cause problems, but that didn't change it. I've googled that specific string, but my situation doesn't match that of any of the other people reporting it. (One was using Intel C++, another was MSBuild from the command line and changing the case. I'm hitting build solution from within Visual Studio itself).
Edit to explain common fixes I've tried:
I've tried building only the project. Does the same thing.
I'm not including any .h files that don't exist.
I've deleted the bin/object folders and rebuilt from scratch. This usually makes it go away for a couple builds, but then it comes right back.
Edit #2:
Found something suspicious earlier in the log:
3>Using "ResolveNonMSBuildProjectOutput" task from assembly "Microsoft.Build.Tasks.v4.0, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
3>Task "ResolveNonMSBuildProjectOutput"
3> Resolving project reference "..\..\..\..\CommonCore\VS2010\Project1\Project1.vcxproj".
3> Project reference "..\..\..\..\CommonCore\VS2010\Project1\Project1.vcxproj" has not been resolved.
This is repeated for several of my projects... I'm gonna chase that down and see if maybe it's a problem with the project reference hint paths.
Ok, it's an old thread, but I encountered the same problem recently.
My solution was to disable the precompiled headers - now a simple change in one sourcefile won't lead into a "rebuild" any more.
I have had the same problem with Visual Studio 2012 recently. I'm on Windows 7 with Visual Studio 2012 Professional (2012.2) building C++ projects. It's worth noting that I recently migrated the solution from Visual Studio 2008 to Visual Studio 2012.
One of the C++ projects (an executable with a DLL project as a reference) was rebuilding every time one of its compilation units was changed, e.g. simply saving main.cpp would cause all compilation units (including the pre-compiled header) to rebuild. I spotted the the following message in the build logs:
Forcing rebuild of all source files due to a change in the command line since the last build.
I turned build log file verbosity to Diagnostic (Tools > Options > Projects and Solutions > Build and Run) and compared the log files from a clean build and a build after one compilation unit has been changed (which forced a full rebuild). I noticed that:
"Path" had changed from one build to the next (";C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\Extensions\Microsoft\VsGraphics" seems to have been tacked on the end)
there was a difference in TaskTracker.exe command lines to do with CancelEvents
there was a warning about OutputPath not being set
I pulled my hair out.
I eventually resorted to recreating the offending project from scratch rather than relying on the project that was automatically generated during the migration process from 2008 to 2012. It seems to be behaving as expected now.
I did three things, and the problem seems to have gone away. I'm trying to narrow it down a little but I figured I'd go ahead and post them:
Deleted and re-added all the references and project references
Fixed one of my projects that wasn't setting the .NET framework target to 3.5 to match the rest of my solution (I was getting away with it because the project didn't use .NET anyway)
Set "Copy Local Satellite Assemblies" to false for all references including System ones.
Beware that some or all of this stuff might be voodoo...
When building an F# project through Visual Studio 2010 (either Build or Rebuild, or Clean -> Build) where I've checked "XML Documentation file" and specified a location in the Build tab of the properties page, I frequently but sporadically run into build failures:
FSC: error FS0193: Access to the path 'xxx.XML' is denied.
I've experience this with several F# projects / solutions. Most of the time I then just turn it off, but I recently noticed then documentation isn't built into the compiled assemblies (I apparently falsely assumed that the XML doc was only for possible external processing and that the doc comments would always get built in).
Any help appreciated.
I know we fixed this bug in VS2010 for F#. I seem to recall that C# and VB had the bug as well (dunno if they fixed it, I can investigate). Do you have a C# or VB project referencing the F# project? (Are you building the solution, or a specific project?)