In Visual Studio 2008 I've added a project's primary output to a setup project but the project's dependencies are not being found.
If I look at the properties of the primary output the Dependencies property shows as (None). If I look a little deeper then I can find that the Dependencies property under the KeyOutput property has the projects dependencies listed and some of those have yellow warning triangles next to them.
This has only started happening since I put the startup project into source safe.
Because of this problem the setup project will not build and I get this error:
------ Starting pre-build validation for project 'PROJECT' ------
ERROR: An error occurred while validating. HRESULT = '80004005'
I ran into this problem when branching and combining various versions of my libraries into projects without making sure that the libraries all referenced the correct versions of each other. Deleting and re-adding my inter-library references fixed the problem.
Are the dependencies by chance in the GAC? We ran into a similar issue on our build server when someone's post-build script GAC'd a few assemblies. Our installers would no longer package those items in the install, so the app would fail to run when later installed in test.
Related
In a solution with Fsharp projects (Visual Studio 2013), intellisense can start complaining that references to other Fsharp projects cannot be found. It then tries to locate the referenced dll file in the bin/Debug folder while in every project and solution wide in the configuration manager everything is configured to build a release. Also, when looking at the project reference properties the path is correct (i.e. the bin/Release folder) and the requested dll actually exists and is in the right folder. The problem disappears by just removing and adding the project reference again or by building the project (while it was build and working in the first place).
The problem can reoccur at any time, however, I cannot give a triggering event or problem case.
Is this a bug in VS2013?
I am trying to clean and rebuild a solution file with multiple projects from the command line using MSBUILD. For some reason my build fails (about 10% of the built projects fail) and I get multiple errors which all look like:
error CS0234: The type or namespace name 'foo' does not exist in the namespace 'bar' (are you missing an assembly reference?)
Now if I clean and rebuild the same solution file from Visual Studio 2010 with the exact same configurations it will build successfully with no errors.
Is there a difference in the setup or configuration of MSBuild from Visual Studio that needs to be changed that I am not aware of?
I just had to deal with this issue and it turns out that msbuild likes to move built binaries into the binaries\release directory and reference those instead of the projects themselves when it builds things. After building it copies the files to this directory. This explains why it works in visual studio and not msbuild (I'm currently using TFS 1010).
In my case I had an old binary version of a dll being referenced by a project that was being built after the one that should have generated the correct file. The old one (binary) was overwriting the new one (built from source) as the solution referencing the binary one was being built later in the build.
I assume there's a difference in how the project is built, because Visual Studio does not run MSBuild, as it rather hosts the build engine itself.
This was answered here.
However, I've had similar problem.
In my case the project referenced an external library, which was placed in the project's child directory, unluckily named "packages".
After running MSBuild the folder's content was deleted, supposedly to be downloaded again by Nuget.
The obvious solution was to rename the folder and it worked.
Summary: Set Debug/Release mode in Visual Studio to the same settings as MSBuild to check for compilation errors.
I encountered the same problem:
Tried deleting all "bin" and "obj" folders.
Made sure all related projects are indeed being referenced and not just liked to compiled dlls. ex. Project B references A. Remove A from solution. Then add again. B would then reference A but via compiled dll only. Remove reference and re-add the project.
Finally switched to "Release" in Visual Studio. Turns out I had conditional compilation in some code (eg. #if DEBUG). So what was running in MSBuild and Visual Studio were actually different hence the error "The type or namespace name 'foo' does not exist in the namespace 'bar' (are you missing an assembly reference?)"
Try checking the paths to the references that MSBuild can't find in the non-building library's project file. Sometimes when you use VS or ReSharper to automatically add a reference for you the path ends up being to the \obj directory. VS seems able to cope with this, but MSBuild not so much.
For me the problem was that the some projects in the solution were not included in the build configuration for the solution. Those projects were dependencies for the projects in the build configuration, so all the projects in the solution failed.
After marking the dependcies projects with build in the solution configuration the msbuild ran successfully.
My issue was found in the solution file.
Remove all lines which reference 'ANY' for CPU and leave the 64 bit ones in.
In my case I had one PCL referencing another PCL with different targets. Visual Studio showed me a warning in the references list of the first library, but compiled the solution, whereas MSBUILD refused to compile. I fixed the problem by retargeting the PCL. Hope this helps somebody.
See my answer here.
Basically - Try running msbuild in a new cmd window everytime as a temporary workaround.
I was facing a similar issue. But after spending a lot of time, I finally came up with a solution (that performs similar to VS)
Use the following command to build your solution
"msbuild.exe project.sln /restore /t:Build /p:Configuration="Release";RunCodeAnalysis=False;RestorePackagesConfig=true”
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.
I've just encountered a compile error I've not seen before. In a solution that contains Windows Workflow Foundation 3 projects, Visual Studio reports that it failed to compile the projects because it couldn't find an application-specific configuration file. The configuration file is NOT added to any of the projects. It is looked for only at runtime by the workflows. Other solutions using the same runtime config file compile without error. If I put the config file in the expected location then the workflow solution compiles without error.
The behavior suggests that when VS2010 is compiling WF3 projects that it is actually running the activities contained in the project at some point during the compile. Does VS actually run activities in WF projects during compile? Does it create activities? If it doesn't, why would the compile error be thrown for a file that isn't part of the project?
Actually I believe it suggests you have a compile time dependency on the config file in question on this one solution that you do not have in the others you mentioned.
Check if the error provides any details as to WHERE it has this compile time dependency and remove it if it is not needed. If there is nothing informing you or hinting where this may be, start digging into the various project properties in question and see if you have a build dependency on the config file.
My application contains a piece of code that executes inside of Component Services, so we need to register our business rules layer (and its dependencies) in the GAC. One of those dependencies is FooCore.dll, which contains classes and services visible to the entire app.
Everything was working fine, until I added a new method to a class in FooCore. Now, when I run my unit tests, any test that calls this new method throws a MissingMethodException, even if I update the GAC with the latest version of the assembly. The only fix is to remove FooCore from the GAC before running the tests.
I've tried the following things:
Rebuilt entire solution, refreshed stuff in GAC, then ran tests = failure
Removed and re-added FooCore assembly reference in test project = failure
Ensured that FooCore is set as "Copy Local" in properties = failure
What can I do to ensure that VSTS loads referenced assemblies from their explicitly defined location, rather than from the GAC?
Further research turned up this forum thread on this issue, in which someone suggests this might be caused by VS2008's Performance Analysis feature holding onto a stale version of the assembly.
I was able to solve my problem by:
Rebuilding my solution, then
Refreshing everything in the GAC, then
Removing and re-adding the assembly references in my test project, then
Closing and re-opening Visual Studio 2008
I'm not sure which of these steps were explicitly necessary, but this "kitchen sink" approach resolved the issue for me.
Update: This Microsoft article states that when a solution is compiled, assemblies found in the GAC are never copied to the output bin\ folder, even if "Copy Local" is set to true.
In my case I had two the same (almost) assemblies with different locations.
The tested project was referenced to the first assembly and the UnitTest project was referenced to the second one (they were absolutely the same).
So check carefully all of the project references.