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?
Related
I have a (mostly C#) solution that needs to build in x64 because I integrate with a C++ project, so I had to choose a platform.
I noticed that my code changes don't always show up at runtime and I found out that when Solution is Debug x64 it compiles the changed project but does not copy the dll to the bin of the startup project, so the debug session uses an older version of that dll.
I tried most variations of building, and the dll-copy never happens, except when I rebuild the startup project, or the solution, obviously...
When on AnyCpu, all works perfectly all the time. So, alternate solution: maybe I can use the C++ project and keep my C# projects on anycpu?
All projects are enabled in the solution config for both anycpu and x64.
Any suggestions I could look out for?
Because the problematic project was a dependency of a dependency of the startup assembly, I tried adding a direct reference to it from the startup project. The issue disappeared...
Of course, I prefer not having refs that aren't really necessary, so when I removed that new reference again, it kept working. So, now I cannot simulate the issue anymore.
Using git the only change I can see is that the ProjectReference is now a lowercase guid, and it was uppercase... This probably happened when I gave re-referenced the project a try earlier... odd stuff shrug
I have a Visual Studio 2010 C++ solution with two projects: an executable and a library. I am successfully able to delete project configurations from Configuration Manager for one of the projects (executable), but not the other (library).
Both projects were previously part of a vs2008 solution that have since been upgraded to vs2010.
When I try to delete a configuration from the library project, I get the error:
The operation could not be completed. Invalid pointer.
This happens for all configurations for that project.
Since this happens with only one of the projects, it leads me to believe that there is probably something wrong with the project and that's why VS2010 doesn't like it. Any ideas what may be wrong?
After some trial and error, I found that the problem was with some left-over project configuration in the library project file (library.vcxproj). The offending section was:
<ProjectExtensions>
<VisualStudio>
<UserProperties RESOURCE_FILE="library.rc" />
</VisualStudio>
</ProjectExtensions>
After deleting the section above from the project file and reloading the solution, I was able to delete project configurations.
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 seen a few threads about this Visual Studio (2010) warning before. But none of them seem to show the project's identity like I am getting. (I'm assuming this is the project identifier.) When I compile my project I get:
c:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.Targets(1422,5):
warning : The referenced project
'{5BED5853-86EB-BA4F-A6E2-25A211A18E33}' does not exist.
Further, I can't seem to find which project this is referring too. In my project's properties > Common Properties > Framework and References, none of the references have project identifiers that match what the warning is showing.
So my question is, how can I determine what project reference is causing this, and how should I go about fixing it?
This issue was caused by a Visual Studio 2008 to Visual Studio 2010 conversion error. In the original solution, there was a project that had a broken reference. This reference was a project that was long ago removed, but apparently no errors/warnings were given in MSVC 08. When converting the project to MSVC 10, this broken reference was converted as well. Since the reference was broken, the path to the reference project was set as the project identifier, hence why I was only seeing the project identifier in the warning message.
To fix this, I had to edit the .vcxproj project file and manually remove the broken reference. You can't fix this through Visual Studio because the converted project will never show the broken project as a reference.
Finding it in the .vcxproj file is easy, just search for the project identifier (in this case 5BED5853-86EB-BA4F-A6E2-25A211A18E33) and remove the entire <ProjectReference> tag referring to it.
Check the .csproj file and ensure the paths to other ProjectReferences are correct.
Make sure that there are no warnings or unresolved symbols under the project's 'Dependancies' node in the tree view.
If you still have problems, your build would appear to be stale.
This occurs because the ${project}/obj/project.assets.json contains
invalid information.
This file within the intermediate folder contains invalid paths.
The entire folder is autogenerated.
For SDK MSBuild project files, you can restore this by doing the following:
View => Other Windows => Package Manager Console
> cd <root project folder>
> rmdir obj # Confirm [A] Yes to All
> dotnet restore
Now do a rebuild on your project.
We have several external DLL files being referenced in our Web Application Project. We have a deployment project for installing on the hosting servers. When we were using .NET 3.5 and Visual Studio 2008 the DLL files were being copied to the bin folder. Since we have upgraded to .NET 4 and Visual Studio 2010 this no longer happens, and we are getting server errors since the references cannot be found.
CopyLocal is set to true, and I cannot find anything inside the web.config which suggests this is being set elsewhere.
There is a bug in Visual Studio 2010. By default the XML in the solution file looks like this:
<Reference Include="DevExpress.SpellChecker.v11.1.Core,
Version=11.1.5.0,
Culture=neutral,
PublicKeyToken=b88d1754d700e49a,
processorArchitecture=MSIL">
<HintPath>..\References\DevExpress.SpellChecker.v11.1.Core.dll</HintPath>
</Reference>
Whereas MSBuild is expecting this below, so that the DLL file will be included in the deployment:
<Reference Include="DevExpress.SpellChecker.v11.1.Core,
Version=11.1.5.0,
Culture=neutral,
PublicKeyToken=b88d1754d700e49a,
processorArchitecture=MSIL">
<HintPath>..\References\DevExpress.SpellChecker.v11.1.Core.dll</HintPath>
<Private>True</Private>
</Reference>
The trick is to set Copy Local to False, save the project and then reset it to True - save again. This includes the Private node correctly, which MSBuild respects.
It appears that the default for no included private node (Copy Local) in Visual Studio 2010 is True, while MSBuild reads that missing node as False.
I was getting the same problem and rather than add a "BeforeBuild" step I created a test that simply did this
[TestMethod]
public void ReferenceAssemblyThatDoesNotCopyToBuildFolder()
{
Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.LoggingExceptionHandler referenceThisButDoNotUseIt = null;
}
And that fixed the error The type 'Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.LoggingExceptionHandler...' cannot be resolved
Something weird had happened to my deployment project. When I saw it had no detected dependencies, I removed the primary output and re-added it.
The dependencies are now showing up and being placed in the bin folder when installed.
I was getting exactly the same issue. We have a Visual Studio 2008 project which references the EnterpriseLibrary. When we run our integrated build using TFS and our Web deployment project, all the DLL files are copied over. When we upgraded to Visual Studio 2010, TFS 2010 and WDP 2010, some of the DLL file's were missing. Strangely, this only occurs to some DLL files and not others.
For example, we get the Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.dll copied in both cases, but not the Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.dll.
As a workaround I copied the files accross using a "BeforeBuild" step.
It now seems to build OK.
I just had the same issue and wanted to share what I found as it might help someone:
The reason in my case was that the assembly was installed in the GAC during an installation of some third-party application.
If the DLL file is in the GAC, the compiler won't bother to copy it to the destination folder, unless you specifically mark it for "copy local" using the "Private" node in the project file as mentioned by Junto.
The thing is that if you don't add that node, and you develop on one machine and build on a different one, and the DLL file is only in the GAC of the build machine, the default behavior without the private node will cause the file to be copied correctly on the development machine, but not on the build machine.
The bigger problem is if the DLL file is not referenced directly, but the project references a second project that in turn references the DLL file. In that case, you cannot mark the DLL file to be "copy local" in the project, as it is not referenced by it. So if the DLL file exists in the GAC - it won't get copied to your output folder.
Possible solutions to this case are:
Uninstall the DLL file from the GAC
Add a direct reference to the DLL file in the end project(s)
Re-sign the DLL file with a new strong name, which will differentiate it from the DLL file in the GAC.
I am not sure how it was set up in Visual Studio 2008, but I am almost positive that you might have been using the Post-Build event command line. In there you can tell to copy the DLL files you need for deployment. An example is given below:
mkdir $(SolutionDir)\Deployment
copy "$(SolutionDir)Your_Library_Name\Your_Dll_ForDeployement.dll"
$(SolutionDir)\Deployment\
I didn't meet the same problem but similar. I had WPF main project and referenced project where the referenced did not copy. I found that in my case the main project was set for NET 4.0 Client Profile and the referenced for NET 3.5. When I set the main project to 3.5 the compiled dll of the referenced project started to copy.
(I don't know why because I solved it by practice)
I too ran into a similar issue where referenced dlls were not copied into the bin in published folder. I was using a TFS checked out copy that didn't include the bin folder into the application.
-> So just included the bin folder.
-> Built the referenced applications
-> Published the website project
Now I see all the referenced dlls in bin in the published folder
I had a similar issue with VS 2012 Express. I used Tesseract libraries in my project. Everything worked well until I used this project in a solution where were more than one project. Problem was that some DLLs (liblept168.dll, libtesseract302.dll) that are normally placed in folders bin/debug/x86 or bin/debug/x64 were copied only when I rebuilt whole solution.
Changing a single line and building it again caused that the DLLs were deleted and not copied back.
I solved this issue by adding a reference of the project that creates missing DLLs to the startup project.
rzen and others, thanks - your comments led to a solution for us.
We have a project that targets version 10 of the Microsoft.ReportViewer.Common.dll and Microsoft.ReportViewer.WebForms.dll assemblies (separate "libs" folder we created at the 'src' level). But when we did a build, the output included version 12, which was recently installed on the build server.
Using comments here, we ensured that 'Copy Local' was set to True and that the flag was set in the project file. However, it was still deploying version 12. So what we found that did the trick was ensuring that the 'Specific Version' property was also set on the two references. Voila, version 10 of each file is now being deployed!
There was much rejoicing.
JH
If your project does not directly load the library, it won't always be deployed, even if it is referenced explicitly! I got confused because I could see it in a local Bin directory but not when deployed. The dll in the Bin directory was an old file that wasn't removed during Clean which is why I was confused.
A full clean and rebuild and it wasn't in my local Bin folder either which showed me the problem (I only use it in web.config). I then referenced the dll file itself in the project and set it to copy to output to make sure it gets deployed.
We can use the <Private>False</Private> to not to copy the referenced DLL files to the bin directory. This is useful when we are building applications in a separate TFS build server where we need to build the application and not to copy the DLL files to the bin directory.
Check the framework of the project in which the DLL file has been referenced. The framework should be .NET 4.0. Please correct it if the framework is Client Profile.
Adding the parameter
/deployonbuild=false
to the msbuild command line fixed the issue.
Got a similar issue when upgrading old WebSites into WebApplications.
The "Clean Solution" command would wipe out all external DLL files I purposely left in my bin folders.
Besides, it was not possible to bring those DLL back automatically simply by referencing them all, since many of them have the same file name (it happens when you work with many language specific resources)
Like stevie_c did, I took advantage of the Pre-Build command, but made it simpler:
I just used a xcopy command in the Pre-Build operation of the WebApplication project's properties. This way I could bring over the necessary external DLL files just before the build would start.